what does this code do? (are you sure?)

Sometimes C code does EXACTLY what it says it does. Sometimes... it doesnt?!

🏫 COURSES 🏫

🔥🔥🔥 SOCIALS 🔥🔥🔥

[Isaac-zydo]

Actually, it depends on the size of char, which is almost always 1 byte, but not guaranteed. The C spec allows it to be any size *larger* than a byte, so in theory option a could be valid sometimes

[ONEGOALONEJOURNEY]

well what happened here is that the compiler convert the value of 1345226309 into binary cause the char can only store the value of 8 bit or -128 to 127, which is turns it returns the value but is take only the last 8 bit character which is 01000101 which when converted to interger comes out to be 69 .
i hope it helps :).

[palphil]

On my screen the “6” in the answer is cut off so it looks like it’s saying the answer is “9”.

[Xiterlide]

Actually 🤓
Apart from the mentioned char size problem in the comments, it also depends on what happens to be on your stack (in memory). You're passing a char to printf, but telling it to expect an int by specifying "%d". So it appends 3 more bytes after x, having where Xs are memory garbage. For you, it happens to be 0s on a little endian system, actually printing the 69 (nice).
But this comment also might not be true, depending on your implementation of va_list. 🙃
Gotta love C

[ramakrishna]

First point
Is
Whether it's storing in little or big endian
So it's totally depends on architecture.
Then we can tell the actuall answer what value stored in one byte

[Starchaser]

Well, I did realize, that this thing is probably too big to fit in char, but I wasn't sure what will compiler do in such case 😅

[DIYDaveOK]

I will say I caught the char/%d trick pretty quickly, but I also have to admit that I can only assert the result is compiler-dependent. You *might* get a compiler warning for the too-large char value; if it runs, what gets printed *may* depend on the "endian"-ness of the underlying architecture and thus affecting how the value is pushed to the stack. That, in turn, could cause either the first byte or the last byte to be the target of the printf. Probably why I *think* this result is undefined in the spec? Fun question!

[litmus]

(The following is incorrect, the char is promoted to int) It’s also technically undefined behaviour to print a char using %d.

[tannerbobanner]

I'm VERY new to C, and I honestly assumed this would be 1345226309 modulo 256, as if the variable would just overflow a bunch of times. Only selecting the last 8 bits actually makes more sense

[phillipchen]

For those who's new to coding. My understanding is that since the size of 1 char is 1 byte(8 bits), the range of number this char can hold is basically -128 to +127 that will make a total of 256. Anything that is beyond 256 will be mod and the char stores the remaining. 1234226309 % 256 will give you 69 and that's how we get the output.

[Phil_DeFontaine]

"You think you know the answer" Me looking at this code: I do not, man.

[ArjanvanVught]

With current compilers it won't compile at all. Unless you ignore warnings.

[lolcat]

Max Char value 0xff ( or 127 for signed and 256 for unsigned ), then it will just stores the bits it has space for (8 bits) and that is what is printed

[PacketWrangler]

I'm a long time network engineer starting to cross train - these have been fun snippets. Thank you. You're also a very brave man. The number of "WELL ACTUALLY" comments people get doing this kind of content must be off the chart.

[matthew]

I just started yesterday and I knew this instantly! Gives me hope 😊 Thank you

[arthur]

Aaaand that's why you should always compile with warnings enabled ! 🤣

[billigerfusel]

Fuck didn't see the char and thought it was an int and kept wondering wtf your problem was

[jakykong]

I assessed the cause accurately but couldn't be bothered to figure out the remainder, so distinguishing between 9 and 69 was a crapshot. Offering 69 and 420 would have avoided the need to guess (420 is larger than one byte), and add another ”nice”.

[thomquiri]

and here I was so sure that it would crash because a number close to int32 limit isn't a character O_o. This is actually interesting, the worst bugs are those we don't see right away

[frk]

I like to enable warnings for such things in gcc. However, if you introduce it late into the project, you will have to fix many many places where you do implicit casts to shorter bitwidths.