[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: libc6-dev and "-pedantic -O" warnings



Manoj Srivastava <srivasta@debian.org> writes:

> >>"Chris" == Chris Waters <xtifr@dsp.net> writes:
>  Chris> The libraries (and in particular, the headers) use non-ANSI-C
>  Chris> features that are supported by gcc,

>         In other words, we have a non conforming system, then? 

No, it's more complex than that.  The library/header code isn't
strictly conforming, but because it's part of the system, it doesn't
have to be, as long as the compiler and linker *accept* strictly
conforming code.  The contents of the standard headers are considered
to be an implementation detail, and aren't required to be strictly
conforming even in a strictly conforming compiler.  Results are all
that matter, technically.  Unfortunately, if you use the -pedantic
flag to check for strict conformance, you may well get spurious
warnings about the stuff in the library headers.

>  Chris> if possible, but if you then use -pedantic, you'll get
>  Chris> warnings about these features from the compiler.  The

>         I would hope so. Why would one wish to promote non-standard
>  code? 

Well......the reason given by the FSF is that gcc is so portable that
it doesn't really matter.  I don't know if I buy that argument (though
it's also used by others, like MS), but technically, the headers,
which are the source of the existing warnings, don't count.
Unfortunately, there's no way to turn off the warnings for the
headers, and still check your own code.

The glibc headers should, IMO, have a #pragma or something that would
disable these warnings in cases where it can be proved that it doesn't
matter.

>  Chris> The moral of the story is, -pedantic is probably not the switch you
>  Chris> wanted.

>         Au contraire. You really have not tried to code portably, have
>  you?

Au contraire, I am generally a portability fanatic.  Which is why I
study the standards so carefully, rather than leaving it up to the
compiler to diagnose portability issues.

An example of highly non-portable code that -pedantic won't blink at:

  f = fopen("/dev/null", "w");

If the -pedantic switch really did what it was supposed to, I would
always use it.  I often do use it during testing, I just don't
consider it robust enough to use for production.

Using the switches you list may well turn off some library features
that make the code more efficient when compiled with gcc.  I'd rather
treat those as internal compiler details, and not force the libraries
to *pretend* that they're written as strictly conforming code, as long
as the *result* is that they *act* in a strictly conforming way, which
they do, even when they generate the warnings.

Not to mention the fact that portability involves more than sticking
to a minimal common base.  Sometimes it involves knowing how to get
the best out of each platform.  (Note that, e.g., read(), and open()
are not part of the ISO C standard, yet I don't see people protesting
their use, even though they only work on POSIX or POSIX-like
platforms.:)

cheers
-- 
Chris Waters   xtifr@dsp.net | I have a truly elegant proof of the
      or    xtifr@debian.org | above, but it is too long to fit into
http://www.dsp.net/xtifr     | this .signature file.


Reply to: