151–160 of 344 posts
Earlier quoted context omitted.
But you _don't_ know what it returns, because the behavior is either undefined or implementation defined, and you don't know the implementation.
But you do know that it's undefined or implementation defined. It's a "known unknown".
It is an unsavory set of questions that has no bearing on practical work, also implementation dependent. The answer is: No, I do not know C or any other language for that matter. I know some implementations of various languages just enough to write sound and readable code. And as I forced to use a bit more languages than I like I rely on local/Internet search to keep my brains concentrated on accomplishing the actual…
The questions are a bit cute, but they’re not testing obscure corner cases of the language. It’s not like asking if you have the trigraphs memorized. It’s testing fundamental rules about how C works: overflow, integer promotion, order of operations, memory layout, etc.
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…
Undefined behavior means the standard says demons can fly out of your nose. Those demons might behave nondeterministically.
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" (…
> This is in contrast to where I live most of the time which is "GCC as an assembler macro language" And then people like you whine and cry when the gcc compiler suddenly enforces that something is actually undefined and blows away a big chunk of your code in optimization.
Indeed, testing your assumptions, because even a defined standard may result in a differing implementation of it. Especially in critical applications, testing the expectations gives some sense of a defined behavior.
This quizz is amusing as a mental exercise and a parable, but in reality all of these cases had to be fleshed out on a real platform, with real compiler and ... specified expectations of the behavior.
None of the cases in fact communicate a clear intent, except maybe #1 to figure out the padded size, still it's somewhat open-ended. Perhaps returning a specific condition (return sizeof(struct ...)==5; ) would show a clear intent. Not that it would change the right answer, just such a case may indeed be true on a specific platform, compile flags erc.
Earlier quoted context omitted.
I think this objection boils down to your perspective on what we mean by "C". It's reasonable for some folks (especially working programmers who need to "get stuff done") to think that "what a reasonable compiler in their problem domain" would do is what "C" means. It's equally reasonable for other folks (especially compiler writers, verification experts, researchers, etc.) to think the ISO standard is what "C" means…
C compilers predate the C standard by many years, so “C is what my compiler does” is certainly a valid perspective. Also, the vast majority of programming languages don’t have standards at all, and people still use them productively.
Java, JavaScript, Modula-2, Pascal, C++, Fortran, C#, F#, VB.NET, Eiffel, D, Ada, Common Lisp, Scheme, Python, Scala, Haskell.
Earlier quoted context omitted.
I think this objection boils down to your perspective on what we mean by "C". It's reasonable for some folks (especially working programmers who need to "get stuff done") to think that "what a reasonable compiler in their problem domain" would do is what "C" means. It's equally reasonable for other folks (especially compiler writers, verification experts, researchers, etc.) to think the ISO standard is what "C" means…
> It would be great for the standard to be more "reasonable" and have less undefined behavior. GCC and Clang are mostly compatible, and as far as the low-hanging fruit is concerned. If you consider them the authority, it generally resolves most interesting questions about what ISO decline to specify. I do not think that there is any great burning need for ISO to go and define things more rigorously.
But knowing every engineering detail is not the same thing as knowing how to program in C effectively. It's like being the engineer who designs a Grand Prix car. It does not mean you can drive it faster around the track than anyone else. Not even close.
For example, the C preprocessor is surprisingly complicated. I had to scrap it and rewrite it completely 3 times. If you try to make use of all those oddities, my advice is don't waste your time. Over time I removed all the C preprocessor tricks from my own code and just wrote ordinary C in its place. Much better.