Re: libc6-dev and "-pedantic -O" warnings
Steve Greenland wrote:
>
> Yes, it would be nice if you could get MSVC to produce useful warnings
> about non-standard language constructs in your code without being
> triggered by the crap in windows.h, and you can, with sufficient
> judicious use of the #pragma to enable/disable warnings at appropriate
> points. It's a pain in the ass to do, though, which is why I suggesting
> just using gcc -Wall, which I personally find to produce far more useful
> diagnostics than MSVC ever has.
>
I think I'm understanding you now, thanks for the clarification, but I
still believe that this thread applies to debian-devel.
For me, and I expect for many programmers, compiling in strict ANSI
compatibility mode is not optional. In fact I normally compile in
wall/strict/ANSI/warnings-as-errors mode to force me to write the
cleanest, most portable code possible, with emphasis on "cleanest" over
"portable".
I learned ANSI C as my first, and only, dialect of C; to me the phrase
"ANSI C compiler available" indicates that "this is a platform that I
know how to sit down and program for". Many people rely on their C code
to follow well-known ANSI C syntax and logic rules. Telling those
people "sorry no ANSI C on this computer" is like saying "sorry you
can't program on this computer".
Seriously, I normally won't program for MS Windows because there is no
practical way to avoid including windows.h, and including windows.h
means that my case statements might start acting funny, or that the
order of evaluation of my boolean if() expressions might be backwards,
or who knows what else. This is unacceptable to me, so I won't do it.
Sure, MSVC might be almost-ANSI-compatible even with ANSI compatibility
turned off, so in reality it might not be a big problem, but I'll take
guarantees over guesses?
In my opinion, major non-ANSI C headers are unacceptable in any modern
operating system, and that's why I am pushing this point on this list.
Coding for ANSI C is the Right Way to code C for all of us who are
anything less than OS internals gods. :)
Sure, I can understand why ctype.h in Debian might be designed to
contain some code optimized especially for gcc. Debian is based on
gcc. But my programs are not based on gcc. My programs are based on
ANSI C, even though I occasionally need to include major Debian headers
like ctype.h. So those headers need to work (with NO warnings of ANY
kind) even when someone like me comes along and compiles in strict ANSI
C mode.
This is not to say that ctype.h can not contain silent gcc
optimizations... I don't care how ctype.h is implemented as long as it
works in my ANSI programs without spewing warnings.
"That's my opinion, I could be wrong" -- Dennis Miller
--
-----------------------------------------------------------------
| Shawn Yarbrough | Skepticism is healthy; anyone |
| shawn@rivalsoftware.com | claiming otherwise is either a |
| http://www.rivalsoftware.com | con artist or a Christian. |
-----------------------------------------------------------------
Reply to: