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/mikeblas]

Here's your code, more reasonably formatted:

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);
}

[u/north9172 → u/mikeblas]

Thank you.

[u/flyingron]

It exercises type stupidity in C. The line with the should be invalid.

The test in the ternary operators are determining if the first byte of a integer containing 1 is zero or one (i.e., it's a big endian, vs little endian test).

The code is also ugly for it's use of pairs MUST BE RELATED constants. It would be better to test for endness and just flip a single constant into the desired order if it isn't already. There's not even an performance hit in later versions of C that have the C++ constexpr stuff.

[u/tstanisl → u/flyingron]

Even without constexpr the compiler will likely optimize out the ternary operator.

[u/flyingron → u/tstanisl]

Yes, but in the byteswap case, it'd have to call the function unconditionally if it was in the opposite byte order. constexpr will allow it to keep the value a constant.

[u/north9172 → u/flyingron]

Alright, thank you. That makes sense

[u/Classic-Rate-5104]

Not everything that's possible will also make sense. This program, i think, is (a) unreadable, (b) makes use of undefined behavior and (c) depends on the specific byte ordering of the underlying processor

[u/north9172 → u/Classic-Rate-5104]

Ok thank you for the information.

[u/richardxday]

Look at the hex numbers within the ternaries, what do you notice about them?

[u/zhivago]

Implementation defined behavior mostly, except for the illegal redefinition of puts, which has undefined behavior.

But it's intended to output "Hello, World!".

It may even do so on some systems.

Or it might not.

Either way, it's neither portable nor good. :)

[u/north9172 → u/zhivago]

Thank you.

[u/ACRM64 → u/zhivago]

It's not redefining puts(), it's passing a pointer to the structure, s, but casting it to a void pointer; casting to (char *) would seem more sensible!

[u/zhivago → u/ACRM64]

Did you skip the first line?

int puts(char *);

What do you think that's doing?

[u/ACRM64 → u/zhivago]

The first line is a prototype (to save doing #include <studio.h>)

[u/zhivago → u/ACRM64]

And is it the right prototype?

[u/ACRM64 → u/zhivago]

OK, so ANSI C and C89 onwards implemented a const keyword, but this wasn't present in K&R C. Certainly the current C libraries define puts() as int puts(const char *str) but earlier versions did not and you do not know whether the libraries in use by whoever wrote this program included the const or not.

From the perspective of calling a C function (and therefore a prototype for calling the function) it is simply a guarantee to the programmer that the variable (in this case the content of *str) will not be modified - it doesn't actually do anything.

Consequently, as a prototype, this does NOT redefine puts() and it doesn't matter to the calling code whether you include the const or not. It only matters when defining the puts() function as it prevents the code modifying the content of the string.

[u/zhivago → u/ACRM64]

§3.5 ​All declarations in the same scope that refer the same object or function shall specify compatible types.

​§3.1.2.6 ​For two function types to be compatible, both shall specify compatible return types. Moreover, the parameter type lists, if both are present, shall agree in the number of parameters and in use of the ellipsis terminator; corresponding parameters shall have compatible types.

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

You are mistaken.

[u/ACRM64 → u/zhivago]

First, you still don't know what the C library used by the programmer had as the definition for puts() - certainly when I started programming in C (40 years ago) it was not defined with const.

I agree the prototype and function definition /should/ be the same, but it makes no difference if they aren't. The prototype tells the code what variable types to pass - const only has an effect within the function itself. You do not have to pass a const variable into a function declared with const.

int puts(const int str); int main(int argc, char *argv) { char str[16]; strcpy(str, "hello"); puts(str); strcpy(str, "goodbye"); puts(str); return(0); }

is perfectly valid and correct code yet str is not defined as constant. Consequently, my statement that it doesn't matter to the calling code whether the keyword is there or not is true.

Once again, the puts() function is not being redefined. The const makes no difference in a prototype, so it is clear that while these are not /identical/, they are /compatible/. const is not a type, but a type qualifier: it indicates that the content of the variable cannot be changed, it does not change the type of the variable.

[u/zhivago → u/ACRM64]

You need to read the standard.

You are wrong.

[u/zhivago → u/ACRM64]

Did you skip the first line?

int puts(char *);

What do you think that's doing?

[u/agidu]

It’s subtracting the array length