is this prog stdc?

[Heinrich Pumpernickel]

is this prog stdc?


no compiler warnings w/ gcc and lcc-win32 and prints "unix" here ,
but how does it wrk???


#include <stdio.h>
int main(void)
{
return printf(&__STDC__["\n%six\n"],(__STDC__)["have"]+"fun"-0x60),
0;
}

 

[Charlie Gordon]

is this prog stdc?


no compiler warnings w/ gcc and lcc-win32 and prints "unix" here ,
but how does it wrk???


#include <stdio.h>
int main(void)
{
return printf(&__STDC__["\n%six\n"],(__STDC__)["have"]+"fun"-0x60),
0;
}

Well on those vulgar architectures, it should print unix and an end of line.
But It is not strictly portable: when run on a DS9000 in EBCDIC mode, it
causes it to grow hair and hop around the room purring, can you spot why?
Indeed switching this wonderful piece of machinery back to ASCII doesn't
seem to fix the problem: it just stopped the purring. Should I take it to
the vet or is there a genuine flaw in this program?

 

[Army1987]

is this prog stdc?


no compiler warnings w/ gcc and lcc-win32 and prints "unix" here ,
but how does it wrk???


#include <stdio.h>
int main(void)
{
return printf(&__STDC__["\n%six\n"],(__STDC__)["have"]+"fun"-0x60),
0;
}

__STDC__ is 1.
a is defined as *(a + i).
Arrays, including string literals, evaluate to the address of
their first member.
In ASCII, which gcc and lcc-win32 use, 'a' is 97, in hexadecimal
that's 0x61.

 

[Richard Bos]

Why are you cross-posting _all_ your replies to comp.std.c? Even when
they don't belong here?

Richard

 

[Charlie Gordon]

Why are you cross-posting _all_ your replies to comp.std.c? Even when
they don't belong here?

3 cross posts does not make for _all_ replies.

I did post this code sniplet to comp.std.c because it raises a question that
belongs here more than in comp.lang.c: the obfuscated expression contains
pointer arithmetic that computes an address beyond the end of a character
string constant. most optimizing compilers will turn (0x61 + "fun" - 0x60)
into ("fun" + 1), but is it strictly correct or is UB invoked ?

I apologize if this has already been discussed here before, but I think it
is very much on topic.

 

[André Gillibert]

pointer arithmetic that computes an address beyond the end of a character
string constant. most optimizing compilers will turn (0x61 + "fun" -
0x60)
into ("fun" + 1), but is it strictly correct or is UB invoked ?

I apologize if this has already been discussed here before, but I think
it
is very much on topic.

No, it's not. If you asked something like "is it intentional that the
current wording of the standard forbids that?", then, it would be on topic.
But you ask: "With the current wording of the standard, is it UB?".

It's off-topic.I set followup to comp.lang.c.

The answer is yes, it's UB, because it does arithmetic outside of array
boundaries, which is UB by 6.5.6p8. The fact that optimizing compilers
*might* make the program behave correctly is irrelevant.

comp.lang.c is about standard C.
comp.std.c is about the C standard.

 

[Harald van =?UTF-8?B?RMSzaw==?=]

In ASCII, which gcc and lcc-win32 use,

This is a bit misleading, and not necessary to the rest of your message. gcc
will default to the character encoding of the host operating system, and
allows for this default to be overridden using command-line options.

 

[Douglas A. Gwyn]

... most optimizing compilers will turn (0x61 + "fun" - 0x60)
into ("fun" + 1), but is it strictly correct or is UB invoked ?

It violates a semantic requirement of the C standard.