Re: libc6-dev and "-pedantic -O" warnings
On 09-Jun-99, 12:04 (CDT), Shawn Yarbrough <shawn@rivalsoftware.com> wrote:
> It sounds like you are saying that an ANSI program (an ISO program???)
> can not include headers unless those headers are explicitly defined, by
> name, in the ANSI standard. This seems incorrect... it's quite
> reasonable to invent new header files which comply with ANSI.
(ISO vs. ANSI: ISO is the international standard org, of which ANSI is
a part. For all practical purposes, the ANSI standard == ISO standard, except
that the section numbering is offset by 3.)
It is quite possible to create new header files which comply with ISO
C, and I incorrectly implied otherwise. What I meant to imply was that
as soon as you start adding libraries/facilities that are outside the
standard, you are into the area of vendor specific extensions, and
your program is no longer strictly conforming with the standard. Of
course, most useful programs are not conforming, and the ObPedantic in
my original reply meant that I was being annoyingly useless in my first
paragraph.
The key point I was trying to make is that the standard library is as
much a part of the standard as the syntax and semantics of "a=1+2;".
If you use facilities (such as windowing) that are not provided by the
standard, then you have stepped outside of it, and are no longer writing
ISO Standard C. This includes using POSIX or X-Windows stuff just as
much as MS Windows stuff.
> For example, the <windows.h> file is the standard file that nearly all
> programs are expected to include if they are written for MS Windows (for
> win32). It is an MS-defined file. I don't see why MS can't either
> clean up their headers (so that they don't use non-ANSI compiler
> features) or at least provide seperate, ANSI-compatible substitutes.
It would be nice if they did, but on the other hand, why should they? If
you are using windows.h, you are *by definition* writing non-portable,
non-standard compliant code. There's nothing wrong with that; I did it
in my previous job, and I'll probably do it in my next one.
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.
Since this a debian-devel and not comp.std.c or
microsoft.compilers.are.crap, let's take this offline if you want to
discuss further.
Steve
Reply to: