One of the links Mark posted earlier addresses the "The compiler should issue
warnings" issue. The short answer is because of macro expansion and other
code-rearranging optimizations (inlining functions, loop unrolling, pulling
expressions out of a loop, etc.), undefined code appears and is removed more
often than you'd expect. Issuing a warning *every time* this happens would
generate many confusing warnings that users wouldn't like.
Also, the deeper you get into the optimized code, the harder it is to issue
meaningful source-level warnings. E.g. when the compiler optimizes:
> static int decimate(x) { return x/10; }
> int foo() {
> int a=INT_MAX;
> int b;
> for(i=0; i<100; ++i) { b=max(i, decimate(a*10));}
> return b;
> }
into
> int foo() { return INT_MAX; }
What warnings should appear for which lines?
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html (third
page).
--- Wade
> On Nov 27, 2013, at 12:19, Octavio Alvarez <[email protected]> wrote:
>
>> On 26/11/13 11:37, Mark Haase wrote:
>> Compiler developers, for better or worse, reserve the right to do
>> whatever they want with undefined behavior, and it's up to the person
>> writing the C code to not include undefined behavior in their own program.
>
> That's a fallacy. The fact that a compiler does not violate the standard does
> not imply it is behaving sane. Thus, not violating the standard does not
> imply not having a bug.
>
> Considering a programmer would not ever *ever* want to fall into undefined
> behavior, the compiler should just issue warnings before making any kind of
> assumptions based after undefined behavior. Those warnings could be silenced
> with flags. This is a way of "yes, I'm sure of what I'm doing".
>
>> Therefore, a Linux distribution has 2 choices: (1) wait for upstream
>> patches for bugs/vulnerabilities as they are found, or (2) recompile all
>> packages with optimizations disabled. I don't think proposal #2 would
>> get very far...
>
> What about adding cppcheck warnings and gcc -Wall -pedantic be added to
> Lintian?
>
> Or what about changing debhelper to pass some -f flags by default?
>
>
> --
> To UNSUBSCRIBE, email to [email protected]
> with a subject of "unsubscribe". Trouble? Contact [email protected]
> Archive: http://lists.debian.org/[email protected]
>
