Re: libc6-dev and "-pedantic -O" warnings
On 09-Jun-99, 18:52 (CDT), Shawn Yarbrough <shawn@rivalsoftware.com> wrote:
>
> 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?
Ok, the reality is that my point about using <windows.h> means you've
left the boundaries of ISO C is not likely to have the effect you
describe -- a compiler that started evaluating boolean expressions
backwards would have a commercial lifespan of about 37 seconds, no
matter what headers you choose to include. Even the Microsoft guys
aren't going to do something like that. Basically, including extra
headers/libraries will *extend* the implementation. It will use more of
the namespace(s) (not in the C++ sense). Extra macros, functions, and
typedefs will be defined.
> 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. :)
It's not a matter of being OS internal gods. It's a matter of wanting to
do useful programming. Here's a few of the things you can't do in ISO C:
- Change current directory (directory is not a concept in ISO C).
- Interact with user except in line-oriented input/output.
- do any form of networking.
That doesn't mean you shouldn't work to minimize the non-ISO C code, or
to isolate the system specific stuff, and use whatever other standards
are available (POSIX, etc). But saying "I'm only going to use the
facilities available in ISO C" is not a practical position for many of
us. (For the last several years I designed/wrote/maintained/whatever a
specialized application development system that was feature-complete on
NT, a variety of Unixes, and OpenVMS. You bet your ass I stuck to ISO
C whenever possible. But it wasn't possible to actually do useful work
without venturing into OS dependencies. You learn to write layers around
them, and normalize the interfaces.)
> 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.
You're absolutely correct about ctype.h: It's a standard header, and
should compile without warnings on the strictest compiler settings.
OS specific and vendor specific extensions like windows.h may not be so
compliant, and there is *no real reason they should be*. It may not be
possible to implement/use the header without using non-ISO C extensions.
As a quality of implementation issue, it would be nice if the vendor
made sure that compiler didn't whine about such things.
Steve
Reply to: