Hacker News Reader

Comment by pksadiq | Hacker News Reader

There are a few problems with the questionnaire. "I don't know" is pretty generic choice to be given/choosen.

Say for example, in question 5, the statement "return i++ + ++i;" is undefined, because the value of i is read and modified twice in a single sequence point (and of course, the order of addition is unspecified), which is not allowed in C. So the answer is "Undefined." (The explanation given in the page not accurate enough in terms of C)

And for question 1, the code is valid, but the result is not strictly defined. It depends on the implementation. So the answer is "Implementation defined."

The usage of "main()" hurts me, the strictly conforming way is to write it as "int main(void)" (or similar)

I feel like the questionnaire piss off people who really knows C.

View on HN

To me "I don't know" is a very apt choice. It makes the point clear that indeed reading the code does not allow you to know the result, which is quite a pitfall.

In your comment you are jumping from "I don't know", which is the first step, to wanting to explain why.

But the point is that I do know what that will print on my computer(s), with my compiler(s), on my architecture(s). "I don't know" is too generic a statement.

Even on a given CPU with a given compiler you usually do not know until you've tried.

This is an article about the C language and the starting point with all the examples is that you do not know for a fact what the result will be.

I understand your claim. But I've gotta say this claim is maybe a little too aggressive. I know for a fact that on a Sun-3 (68020 SunOS Desktop Pizza Box) using either gcc or the bundled cc, all of them would have been the same answer, and the answer would have been known to the coder, before running that code (unless you unleashed one of the gcc command line dogs). Except maybe #5, because who does this?

On your computer yes, but the question specifically doesn't tell you what computer and compiler are used. So thus you can't know what the number is.

There were multiple questions where I would have answered "It's undefined" or "It's implementation defined", but those weren't options. It's not that I don't know the answer; I know the answer ("it's implementation defined according to the spec, but on essentially every relevant platform, the result will be X"), but the "it's implementation defined" part of my answer isn't an option, so the only possible answer becomes "on essentially every relevant platform, the answer is X".

Using "I don't know" as a substitute for "I know that the standard clearly covers this, and it says that the result depends on the implementation" does seem to be designed to piss off people who know C. If they really wanted to get the point across that you don't know what is and isn't implementation defined or undefined, they shouldn't be using vague questions to mislead people; they should just plainly ask questions which people don't know the answer to.

I hate this kind of questioning where you 100% know the subject matter the quiz is asking about, but the question and possible choices is so vague you have to try to interpret what you suspect the person who wrote the quiz wants the answer to be. I once had an exam which was full of that kind of multiple choice question, and guessed the exam author's intentions wrong on most of them.

the quiz asks what each one would evaluate to. “Undefined” or “implementation dependent” are not answers to that question. “I don’t know [because it is undefined]” or “I don’t know [based on the given information]” are logically consistent answers to the question that was asked

Ok, say I made a quiz where I ask you about what `((((16 <= 16) << 16) >> 16) <= 16)` evaluates to. I could give you the options 0, 1, 16, or "I don't know". If I as a quiz author wanted to test your knowledge about shift operators and esoteric uses of equality operators and your ability to reason through an expression, I would mark "1" as correct, and "0", "16", and "I don't know" as incorrect (I would include the "I don't know" option just because that's a common thing to do in quizzes, to not force people to guess one of the options if they don't actually know the answer).

My point isn't that there's no logically consistent answer. My point is that there are _two_ logically consistent answers, and which one is correct depends on the unknowable state of mind of the quiz author. On the other hand, if the options included "It's implementation defined" or "it's undefined", the author would have made their expectations clear, and the quiz would actually test people's knowledge of C rather than people's ability to try to reason about what sort of answer the author expects.

> So the answer is "Undefined."

The code is undefined, but "I don't know." is still the correct answer for what happens to the variable.

> The code is undefined, but "I don't know." is still the correct answer for what happens to the variable.

Well, then a better choice would be "I can't know."

Compile it, look at the assembly. You can know. The answer will vary from place to place, but it isn't non-existent.

With what compiler? Targeting what architecture? The question is underspecified. "I can't know" is correct.

Q: What is a leaky partial abstraction of the C standard?

Ans: A compiler.

And then you update your compiler and something completely different happens.

Or your standards conforming but mischievous compiler does something nondeterministic ;)

1) This made me curious. Are any of the compilers in real use nondeterministic?

2) Probably that's not needed? A normal optimizing compiler just inlines the function somewhere new — and boom? Then again, can that really happen with practical contemporary compilers and this exact statement?

Most compilers are nondeterministic in small ways. For example, it's common to use hash tables that are keyed by pointer address and then iterate over the entries in storage order, so the order in which certain things are emitted will change from run to run. This is why "deterministic builds" are such a big deal, and not just an obvious thing that you get for free.

I don't know what the chances are that such a thing could ever translate into good assembly being emitted in one run and bad assembly being emitted in the next.

Register allocation can be quite tricky, and sometimes it can only explore a small part of the problem space, so if you don't start the algorithm with exactly the same seed you might end up with significantly different code in certain functions.

> Compile it, look at the assembly. You can know. The answer will vary from place to place, but it isn't non-existent.

This pretty much is the definition of "undefined behaviour" in the context of a standardized language specification.

Whoa there! You mean “unspecified behavior”. int i = [unspecified] means that i has some value, but the spec doesn’t determine the value. Undefined behavior means that all your secrets might be sold to the highest bidder, your centrifuges might explode, and your computer is now full of ransomware.

> Whoa there! You mean “unspecified behavior”. int i = [unspecified] means that i has some value, but the spec doesn’t determine the value. Undefined behavior means that all your secrets might be sold to the highest bidder, your centrifuges might explode, and your computer is now full of ransomware.

That's only when using Boehm GC[0] in kernel device drivers that self-modify. Or any MSVC binary.

:-D

0 - https://www.hboehm.info/gc/

Whilst my other comment was intended to be jovial, it is hard to say if that was accurately conveyed. So this one will be serious.

The original problem definition, as specified by @pksadiq, read thusly:

> Say for example, in question 5, the statement "return i++ + ++i;" is undefined ...

This inspired a response by @Filligree of:

> Compile it, look at the assembly. You can know. The answer will vary from place to place, but it isn't non-existent.

Given the original constraint of an undefined statement result, and the suggested activity to address same, I posited that the recommended action is an exemplar of observing the product of undefined behaviour.

You then contributed:

> You mean “unspecified behavior”.

As per c-faq.com[0], there are three categories identified relating to this topic:

1 - implementation-defined: The implementation must pick some behavior; it may not fail to compile the program.

2 - unspecified: Like implementation-defined, except that the choice need not be documented.

3 - undefined: Anything at all can happen; the Standard imposes no requirements.

Whereas you imply a standards-conformant implementation of "return i++ + ++i;" is unspecified (category #2), it is, in fact, undefined (category #3). The support for this assertion is as follows.

As per the same site, Question 3.8[1] includes:

> Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be accessed only to determine the value to be stored.

And further states:

> ... if an object is written to within a full expression, any and all accesses to it within the same expression must be directly involved in the computation of the value to be written. This rule effectively constrains legal expressions to those in which the accesses demonstrably precede the modification.

And concludes with an example stating:

> ... the Standard declares that it is undefined, and that portable programs simply must not use such constructs.

Therefore, the original expression presented by @pksadiq is in fact an exemplar of an undefined expression as defined by category #3 shown above. Since both it and the message to which I originally responded satisfy same, I stand by my response given to @Filligree as having had informally defined the standard C concept of "undefined behaviour."

0 - http://c-faq.com/ansi/undef.html

1 - http://c-faq.com/expr/seqpoints.html

> Whereas you imply a standards-conformant implementation of "return i++ + ++i;" is unspecified (category #2), it is, in fact, undefined (category #3).

You're misreading things. amluto's assertion is that "The answer will vary from place to place, but it isn't non-existent." is a description of category #2. That assertion is basically correct, depending on how exactly you define "place to place".

An informal definition of category #3 is "The answer can vary from place to place, or not exist at all." ideally followed by "It might crash or run unrelated code or even prevent the preceding code from running." It's flat-out wrong to say a value "isn't non-existent" when it comes to source code exhibiting undefined behavior.

UB includes the code not compiling, although it rarely happens in practice.

"I cant know" is a subset of "I dont know"

"I dont know" was absolutely the correct answer.

Except from the perspective of a pragmatics linguistic analysis, "I don't know" has a social context of "There's an answer, and I don't know it."

In this case, a non-C programmer should answer "I don't know" to all of them. A person with a passing familiarity should answer similarly. A seasoned pro would be forced to answer the same. Making it a rather useless tool for distinguishing people who think they know C but are honest when faced with their limitations or those who truly know it and know the answer is undetermined, which is supposed to be the point of the exercise.

>which is supposed to be the point of the exercise.

I don't think that assumption is justified. Someone could say the point of the exercise is to illustrate that C is confusing.

You don't think the claim is justified because some might say otherwise. Some is irrelevant. Some might say lots of mutually exclusive interpretations. It's the author's intent that matters, and the context of the Author's post indicates the some interpretation isn't the author's intent. His post begins with the question "So you think you know C?". He then goes on to present a test that is, by his own words, intended identify to test takers whether or not they really understand the intricacies of C, and to think critically about that source of their knowledge "I had to learn to rely on the standard instead of folklore; to trust measurements and not presumptions; to take “things that simply work” skeptically"

Never once does the author mention that C is confusing, use the word confusing, or otherwise indicate that general idea. If you're getting that impression, it's your own reading into it. I'm not even saying you'd be incorrect, but that's not the author's intent, which was the basis of my comment.

Showing how people misunderstand the intricacies of C is much closer to "C is confusing" than "distinguishing who is honest about their limitations".

And yet its not confusing. Given the confines of any particular implementation and compiler the behavior can be known without confusion. The author never directly mentions or implies that their intent is to convey that C in confusing. Quite the contrary, they indicate their intent is to demonstrate that certain segments of people who believe they know C don't in fact understand its intricacies.

> Given the confines of any particular implementation and compiler the behavior can be known without confusion.

Only through extreme levels of compiler code inspection, as it can vary based on optimization heuristics.

> Quite the contrary, they indicate their intent is to demonstrate that certain segments of people who believe they know C don't in fact understand its intricacies.

Demonstrating that people don't know C is subtly different from an intent of testing whether people know C. The point being made is about C itself.

If what "some" might say about what the author intends is irrelevant, then what you say about what the author intends is also irrelevant, because you are just some person (unless you're the author). My point was why should I trust your interpretation of what the author intends more than anyone else's.

>"So you think you know C?"

That goes along with the interpretation that the point is to illustrate C is confusing. It would go along with something like "You think you know it, you think it's simple, well actually you don't know it, it's confusing."

>intended identify to test takers whether or not they really understand the intricacies of C, and to think critically about that source of their knowledge

Yes, its intent is to indicate to test takers that a lot of them don't really understand the intricacies of C, which demonstrates that C is more confusing than they originally thought.

>Never once does the author mention that C is confusing, use the word confusing, or otherwise indicate that general idea.

Here are some quotes that indicate the idea that C is confusing:

>C is not that simple.

>It’s only reasonable that the type of short int and an expression with the largest integer being short int would be the same. But the reasonable doesn’t mean right for C.

>Actually, it’s much more complicated than that. Take a peek at the standard, you’ll enjoy it.

>The third one is all about dark corners.

>The test is clearly provocative and may even be a little offensive.

Then the author says that he did C for 15 years and thought he knew it, but then realized he didn't. That indicates to me either that the author is saying that he's not smart, or that C is confusing. The second appears to be the point the author is actually making.

My interpretation is based directly on what the author states. Your "some" is based on a vague aggregate group whose interpretations, in aggregate, would be diverse and often contradictory and mutually exclusive. Personally, I trust the explicit an implied interpretation of the author's direct statements than you mere speculation as to what others might interpret.

If you don't like "some" then replace it with me. I interpret it as the author saying C is confusing.

My interpretation is also based on what the author states, fairly explicitly. And I don't think there's anything that explicitly contradicts my interpretation.

You say it's confusing because the author says it's not simple. The same might be said of any language. Or of any learning specialty at all. It's not synonymous with confusing. You're severely stretching the meaning of the author's words when you say the author's point was to say that C is confusing. It's what you infer because you were confused, which points to this being personal to you, not the general intent of the author.

> "I cant know" is a subset of "I dont know"

There is a world of difference between "don't know" and "can't know", as the first implies a shortcoming on the side of the developer while second one states that the question is patently meaningless to someone who does master the language.

No, it isn't. The correct answer to #2 is "According to the standard, the result is implementation defined, but on my target platform, 0". "I don't know" is the wrong answer.

The C specification does not say that undefined behaviour must give a deterministic result on a given platform. All you can say is "this one time I compiled and then ran this code, it gave 0". There is no requirement that the code compiles at all, nor that the same compiler on the same platform produces the same binary on every run, nor that the resulting binary produces the same result on every run, nor that the binary produces any result, nor that it doesn't sometimes produce a result and sometimes not, nor that the compiler doesn't sometimes produces a binary and sometimes not ... undefined behaviour is exactly that: undefined behaviour.

I'm well aware of what undefined behavior is. I still know it's undefined behavior and can read my compiler manual to answer the question of how the code behaves. "I don't know" is simply wrong.

> and can read my compiler manual to answer the question of how the code behaves.

Which is both not true (because the compiler manual usually won't define undefined behaviour) and irrelevant (because the questions were about C, not about a compiler).

In the example I choose (#2) most compilers totally specify the behavior. And the question was (right from the article) "what the return value would be?" In order for a function to return, it must be run. In order for a function to be run, it must be compiled. In order for a function to be compiled, there must be a compiler (or interpreter, I suppose).

You're being pedantic about something silly, but you're also wrong in your pedantry.

> The code is undefined, but "I don't know." is still the correct answer for what happens to the variable.

Actually, as undefined behavior should not be used at all then the correct answer should be "nevermimd these examples, they are all bug-ridden".

Somewhat related, my introductory classes involved a lot of games around pre- and post- increments and short circuiting. While I get that understanding these operations is fundamentally important, is understanding ridiculous combinations of them important? I mean, these were the basis of large portions of some quizzes and midterms. I get playing with them from a theoretical perspective, as this can literally be done in many languages, but why force freshmen to play this deep mental gymnastics? Maybe a play at making the classes weeder classes and no other reason.

I don't know how convoluted the questions on your midterms were but one good reason that kind of irritating thing pops up in tests is that it's quite common in real world C code. Think of the old K&R string copy example.

The questions are testing whether you really understand the basic rules of the language. Often times, the best way to test whether you really get the rules is to raise them in some odd context, so that you can’t just pattern match to figure out the result.

Have you ever worked with a pre-ANSI (K&R) C compiler? Omitting the return type for main is legal in those old compilers. Newer ones give you a warning.

Omitting the return type is perfectly conforming C89.

> I feel like the questionnaire piss off people who really knows C.

I hated this test. I’ve spent 12 years working on C targeting various flavors of arm and x86.

Just because the behavior is undefined when compiled without warnings and run on a Soviet water integrator doesn’t mean the language is undefined for the 99.995% of the industry uses.

Behavior of c89 or later with -Wall -Werror on modern clang, gcc, icc, visual studio, is well understood on arm, x86, mips, risc, ppc, Cortex-m and just about every other hardware architecture.

But, C is a pia, and I’ve been using rust instead :)

It’s not just that stuff. What pissed me off was asking about the return code of a comparator. That’s just bad form. You’re only supposed to check for zero or nonzero. I have never used the value beyond that, and if you are, that’s a problem.

You’re incorrect. The result of a comparison is guaranteed to be zero or one in C. Similarly for the exclamation-point “not” operator, and || and &&.

This isn’t a recent standardization; it’s been an explicitly specified feature of C pretty much since the very beginning of the language. See page 7 of the prehistoric https://www.bell-labs.com/usr/dmr/www/cman.pdf

Reply on news.ycombinator.com