Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

So you think you know C? (2016)

wordsandbuttons.online

Post reply on HN
Print view View original

51–60 of 344 posts

Re: So you think you know C? (2016)

#51

Post by seba_dos1 »

ioquatix wrote: post #49

On a typical modern arch, there are consistent and reasonable answers: 1. 8 ( https://godbolt.org/z/Udcuj0 ) 2. 0 ( https://godbolt.org/z/kZz1YQ ) 3. -96 ( https://godbolt.org/z/1Xq_Oo ) 4. 1 ( https://godbolt.org/z/MIo0s_ ) 5. 2 ( https://godbolt.org/z/J0dsVW ) I agree, you can argue that it's unspecified, undefined, or whatever. It might not be well defined by the C specification, but none of these programs produce…

Switch the compiler to ARM, which is as "typical modern arch" as it gets, and see for yourself.

Re: So you think you know C? (2016)

#53

Post by dmcdm »

I found it an amusing excrcise, if not terribly relevant, even as someone who spends 90% of his dev time in C.

What rubs me about these sorts of articles is they make some presumption about the importance and nessecisity of writing truely portable C, as if the "C Standard" were in and of itself a terribly useful tool. This is in contrast to where I live most of the time which is "GCC as an assembler macro language" (for a popular exposition on this subject see https://raphlinus.github.io/programming/rust/2018/08/17/unde...). And yeah, reading through the problem set I was critiquing it in context of my shop's standards, where we might be packing and padding, using cacheline alignment, static assertions about sizeof things, specific integer types, etc. So these sorts of articles just come off as a little pendantic to folks like me. I don't doubt they're useful for some folks, and I guess it's interesting to come up from the depths of non-standard GNU extensions and march= flags to see what I take for granted.

Re: So you think you know C? (2016)

#55

Post by ioquatix »

seba_dos1 wrote: post #51
ioquatix wrote: post #49

On a typical modern arch, there are consistent and reasonable answers: 1. 8 ( https://godbolt.org/z/Udcuj0 ) 2. 0 ( https://godbolt.org/z/kZz1YQ ) 3. -96 ( https://godbolt.org/z/1Xq_Oo ) 4. 1 ( https://godbolt.org/z/MIo0s_ ) 5. 2 ( https://godbolt.org/z/J0dsVW ) I agree, you can argue that it's unspecified, undefined, or whatever. It might not be well defined by the C specification, but none of these programs produce…

Switch the compiler to ARM, which is as "typical modern arch" as it gets, and see for yourself.

I don't think it's surprising when you switch machine architecture and/or word sizes that you get different results. In fact for me, that's completely normal and to be expected.

Re: So you think you know C? (2016)

#56

Post by microcolonel »

In practice, things in C are not as undefined as the ISO working group specifies them. It is virtually inconceivable that a mainstream compiler stack would do anything other than what you'd expect with example four. As for struct alignment, that's something that most C programmers should know is implementation-defined (which is one of the reasons we even have sizeof to begin with, apart from the mere convenience of it).

Sure, you've made your point, but you've made it in a ham-fisted way which doesn't really help people understand why a given undefined or implementation-defined behaviour is the way it is, and what things they should verify about the implementation in order to predict where their code will not work.

Re: So you think you know C? (2016)

#57

Post by FartyMcFarter »

seba_dos1 wrote: post #48
kristopolous wrote: post #37

This is a perfect example of what I hate about some tests. Didn't quite know the purpose of the test, there's a difference between code for any machine and any compiler and gcc running on some vanilla x86, which is pretty common, and could have been the content (ex: you say it's undefined, that's obvious, everyone knows that already, but it's still deterministic... Here's a breakdown of what happens in practice, blah…

You can easily get bitten by at least one of those examples just by compiling your application written on x86 to ARM to get it running on Android, so not sure if it's as esoteric as you think.

Or on different compilers, or the same compiler with different options, etc.

Re: So you think you know C? (2016)

#58

Post by chadcmulligan »

Isn't there a more fundamental flaw in these questions? main() always returns an int, whether that's 4 or 8 bytes, 0 or 1 means success or failure depends on the implementation. here's a bit of a discussion https://stackoverflow.com/questions/204476/what-should-main-...

Reminds me of the dumb exams some teachers would set to trick you when in school to make themselves feel superior.

Re: So you think you know C? (2016)

#59

Post by [deleted] »

dmcdm wrote: post #53

I found it an amusing excrcise, if not terribly relevant, even as someone who spends 90% of his dev time in C. What rubs me about these sorts of articles is they make some presumption about the importance and nessecisity of writing truely portable C, as if the "C Standard" were in and of itself a terribly useful tool. This is in contrast to where I live most of the time which is "GCC as an assembler macro language" (…

[deleted]

Re: So you think you know C? (2016)

#60

Post by [deleted] »

seba_dos1 wrote: post #48
kristopolous wrote: post #37

This is a perfect example of what I hate about some tests. Didn't quite know the purpose of the test, there's a difference between code for any machine and any compiler and gcc running on some vanilla x86, which is pretty common, and could have been the content (ex: you say it's undefined, that's obvious, everyone knows that already, but it's still deterministic... Here's a breakdown of what happens in practice, blah…

You can easily get bitten by at least one of those examples just by compiling your application written on x86 to ARM to get it running on Android, so not sure if it's as esoteric as you think.

[deleted]
Post reply on HN