> 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."
Ans: A compiler.
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?
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.
This pretty much is the definition of "undefined behaviour" in the context of a standardized language specification.
That's only when using Boehm GC[0] in kernel device drivers that self-modify. Or any MSVC binary.
:-D
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."
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.
"I dont know" was absolutely the correct answer.
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.
I don't think that assumption is justified. Someone could say the point of the exercise is to illustrate that C is confusing.
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.
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.
>"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 also based on what the author states, fairly explicitly. And I don't think there's anything that explicitly contradicts my interpretation.
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.
Actually, as undefined behavior should not be used at all then the correct answer should be "nevermimd these examples, they are all bug-ridden".
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).
You're being pedantic about something silly, but you're also wrong in your pedantry.