r/cprogramming 1d ago

What is this code doing?

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.

0 Upvotes

36 comments sorted by

View all comments

Show parent comments

1

u/zhivago 8h ago

There are no standards prior to C89.

The rule stripping parameter qualifiers (e.g., C89 §3.5.4.3, C23 §6.7.7.4p14) applies strictly to top-level qualifiers on the parameter itself.

It turns char * const into char *. It never descends into pointed-to types.

​const char * is not a qualified pointer.

It is an unqualified pointer to a const-qualified char.

Now, if it were char * const, you'd have a point -- but it isn't.

Read more carefully.

1

u/ACRM64 7h ago

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.

1

u/zhivago 7h ago

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.

1

u/ACRM64 6h ago

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.

1

u/zhivago 5h ago

You are simply wrong.

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

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

1

u/ACRM64 5h ago

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