I Do Not Know C: Short quiz on undefined behavior (2015)

Post by vyodaiken » Tue, Feb 14, 2017, 1:40 PM UTC

msbarnett wrote: post #94

yorwba wrote: post #93

Earlier quoted context omitted.

Something like assert(x); int y = *x; is probably closer to the intended meaning. Checking if(!x) afterwards is still dead code, but at least the program is guaranteed to fail in a defined manner. Of course, if implemented this way, every dereference would have to be paired with an assert call, bringing the performance down to the level of Java. (While bringing the memory safety up to the level of Java.)

That's the opposite of what he wants. He wants a compiler that produces a translation which derefrences the null and follows the true branch. He wants null to equal a valid addressable address, which is completely nonstandard and not portable to everywhere C is used, to be standard that portable compilers emit code for. He wants to imagine that null and zero are the same thing.

Post by vyodaiken » Tue, Feb 14, 2017, 1:45 PM UTC

msbarnett wrote: post #75

mjevans wrote: post #17

Earlier quoted context omitted.

I don't think #2 has been fully beaten to death yet. Assuming a platform where you don't segfault (say that 'page 0' variables are valid) and thus runtime does proceed; I still can't think of any /valid/ reason to eliminate the if that follows (focus line 2 in the comments). Under what set of logic does being able to de-reference a pointer confer that it's value is not 0 (which is what the test equates to)? In my opi…

> Under what set of logic does being able to de-reference a pointer confer that it's value is not 0 (which is what the test equates to)? You're conflating null and zero (which C encourages you to do for various terrible reasons). The test does not test that x is not zero; it tests that x is not null (null, like zero, is falsey, but again, null is not to be mistaken for zero), which in C is sometimes represented by th…

Post by vyodaiken » Tue, Feb 14, 2017, 1:54 PM UTC

adrianN wrote: post #116

vyodaiken wrote: post #55

Earlier quoted context omitted.

It's easy to see the problem in the null pointer case. The compiler deduction is that the null test is redundant, but it's not actually redundant. Therefore the compiler "proves" a false theorem. That the standards rules permit the compiler to deduce false things would be, in normal engineering analysis, considered to show a failure in the rules, but the bureaucratic mindset holds that the rules are always, by defini…

If you don't like the "ridiculous" standard, maybe you shouldn't be writing the language that it defines. There are plenty of discussions online what parts of the standard should be changed to get a "friendly C" [1], unfortunately there is no consensus that could be implemented. [1] http://blog.regehr.org/archives/1287

Post by mauricioc » Tue, Feb 14, 2017, 2:09 PM UTC

Kenji wrote: post #131

I'm sorry, but the answer this website gives to 1. is wrong. See for yourself: int i; int i = 10; int main(int argc, char* argv[]){ return 0; } Try to compile it. It doesn't work (gcc.exe (GCC) 5.3.0), the error is: a.cc:2:5: error: redefinition of 'int i' int i = 10; ^ a.cc:1:5: note: 'int i' previously declared here int i; ^ Either I misunderstood the author and this example, or I do know C.

   Change: C++ does not have “tentative definitions” as in C E.g., at
   file scope,

   int i;
   int i;

   is valid in C, invalid in C++. This makes it impossible to define
   mutually referential file-local static objects, if initializers are
   restricted to the syntactic forms of C. For example,

   struct X { int i; struct X *next; };
   static struct X a;
   static struct X b = { 0, &a };
   static struct X a = { 1, &b };

   Rationale: This avoids having different initialization rules for
   fundamental types and user-defined types.
   
   Effect on original feature: Deletion of semantically well-defined
   feature.

   Difficulty of converting: Semantic transformation.

   Rationale: In C++, the initializer for one of a set of
   mutually-referential file-local static objects must invoke a
   function call to achieve the initialization.

   How widely used: Seldom.

Post by [deleted] » Tue, Feb 14, 2017, 2:16 PM UTC

vyodaiken wrote: post #68

msbarnett wrote: post #64

Earlier quoted context omitted.

> C programmers should be able to expect that "optimizations" will not transform program meaning. If x is null, the program in #2 has no meaning. The only way to preserve its meaning is to assume x is not null. > Optimization should always be secondary to correctness. If x is null, the program in #2 has no correctness. The only way to salvage its correctness is to assume x is not null.

Exactly. You are assuming that a poorly written standard is correct and engineering practice of working programs is incorrect.