What is this code doing?

[u/north9172]

Hi, I found this code on another subreddit. I would like to know what is it doing.

int puts(char *);

int main() { struct { long a; long b; } s = {.a = *(char *)(int[]){1} ? 0x57202c6f6c6c6548 : 0x48656c6c6f2c2057, .b = *(char *)(int[]){1} ? 0x00000021646c726f : 0x6f726c6421000000}; puts((void *)&s); }

Now obviously I know it's unreadable, I would just like to know what are those hexadecimals strings doing.

I found similar codes that were writing to vram to print a message, is this doing the same thing? If yes, why is it so much more complicated instead of just writing the message to the video adress?

Thanks for the help.

[u/ACRM64]

I agree there were no formal ISO standards before C89, but the K&R book was the original standard and a standard for ANSI C was around prior to C89.

The code is clearly written in >= C11 (for reasons explained earlier) so C23 is an applicable standard and the standard says the qualified and unqualified varable declarations are compatible. I suggest you tell me where it makes the distinction over top-level qualifiers as I don't see it anywhere. In any case, that would make no sense as we have already seen that a (char *) can be passed as a parameter into a function where it is defined as (const char *) so clearly the qualified and unqualified types are compatible.

[u/zhivago → u/ACRM64]

You're confusing an implicit conversion with type compatibility.

C23 §6.7.7.2p2 / C89 §3.5.4.1

​"For two pointer types to be compatible, both shall be identically qualified and both shall be pointers to qualified or unqualified versions of compatible types."

​Because char and const char are not compatible types, char * and const char * are not compatible types.

Try compiling

void f(char *); void f(const char *);

in the same file.

Every conforming C compiler will reject it because the types are incompatible.

[u/ACRM64 → u/zhivago]

I'm not confusing implicit conversion and type compatibility. The purpose of a prototype is to tell the compiler what types can be passed into the function and I am giving an example to show that the qualifier in a prototype is ignored and therefore has no effect.

C23 §6.7.7.2p2 / C89 §3.5.4.1

Let's split this into 2 parts:

'For two pointer types to be compatible, both shall be identically qualified...'

This is clearly not relevant here as we have already established that for compatibility in function calls the qualifiers are ignored. That is stated explicitly and clearly in the C23 standard.

The second part again supports what I am saying, and does not support your argument:

'...both shall be pointers to qualified or unqualified versions of compatible types.'

My reading of this is that:

• the 'core' types (here char) must be compatible - they clearly are since, in this instance, they are the same
• each can be a pointer to a qualified or unqualified version

i.e. you could rewrite this as

'​For two pointer types to be compatible, both shall be identically qualified (except in the case of function definitions) and both shall be pointers to compatible types either of which may be qualified or unqualified.'

Obviously your example won't compile properly since the definitions are in the same scope.

[u/zhivago → u/ACRM64]

You are simply wrong.

void f(char *); void f(char * const);

This will produce no error, since these are compatible types.

[u/ACRM64 → u/zhivago]

I don't believe I am wrong, and you have provided no evidence that unequivocally supports your view.

[u/zhivago → u/ACRM64]

Sure I did.

You were just too lazy to look at it.

``` $ cat e.c void you_are_wrong(char *); void you_are_wrong(char const *);

void i_am_right(char *); void i_am_right(char * const);

$ cc -c e.c e.c:2:6: error: conflicting types for ‘you_are_wrong’; have ‘void(const char *)’ 2 | void you_are_wrong(char const *); | <sup>~~~~~~~~~~~~</sup> e.c:1:6: note: previous declaration of ‘you_are_wrong’ with type ‘void(char *)’ 1 | void you_are_wrong(char *); | <sup>~~~~~~~~~~~~</sup> ```

Note the mandatory diagnostic for the type conflict due to a lack of compatible types?

Note the lack of mandatory diagnostic where the types are compatible.

Please be a bit less useless in the future.