Re: -std=c90 -pedantic-errors and <stdint.h>

[Vincent Lefevre <vincent+gcc at vinc17 dot org>]

On 2017-06-01 14:22:19 +0200, David Brown wrote:
> The compiler cannot blacklist <stdint.h> in pedantic C90 mode without
> breaking C90 compatibility.  The C90 standards say nothing about
> <stdint.h> - it is therefore just as legitimate a header name as <foo.h>
> would be.  The compiler cannot retroactively reserve file names from
> future standards in the way you suggest.

I agree without -pedantic, but with -pedantic, this is different.

> > If you want an example:
> > 
> >   -Woverlength-strings
> >       Warn about string constants that are longer than the "minimum
> >       maximum" length specified in the C standard.  Modern compilers
> >       generally allow string constants that are much longer than the
> >       standard's minimum limit, but very portable programs should avoid
> >       using longer strings.
> > 
> >       The limit applies after string constant concatenation, and does not
> >       count the trailing NUL.  In C90, the limit was 509 characters; in
> >       C99, it was raised to 4095.  C++98 does not specify a normative
> >       minimum maximum, so we do not diagnose overlength strings in C++.
> > 
> >       This option is implied by -Wpedantic, and can be disabled with
> >       -Wno-overlength-strings.
> > 
> 
> That is totally different - that is an option specifically applying a
> limit that is not required by any standard, but which can be helpful in
> checking code for portability.

I don't see any difference. Including <stdint.h> unconditionally
is also a portability issue.

> Even if the compiler were to have a "-Wblacklist-stdint" option, that
> might help you detect it - but it would break C90 standards
> compatibility, because C90 /allows/ you to have a <stdint.h>.

Similarly, C90 allows one to have strings longer than the C90 limit.
Really, -Wblacklist-stdint would be very similar to -Woverlength-strings
in that sense.

> The C90 standards document does not explicitly discuss extended integer
> types (which are mentioned in C11, and I think C99 but I haven't
> checked).  But there is nothing in the standard to stop an
> implementation having them - it just has to use reserved identifiers for
> them.

But I recall that here, the context is portability detection
with -pedantic (see above).

> I still have trouble understanding why this is an issue.  If you are
> writing code that needs to be C90 compatible, don't include <stdint.h>
> and don't use intmax_t.  Problem solved.

So, you are saying: If you are writing code that needs to be C90
compatible, just write code that it C90 compatible. Problem solved.
And there is no need for -pedantic. So, why is -pedantic there???

> To quote from the gcc reference for -Wpedantic:
> 
> > -Wpedantic does not cause warning messages for use of the alternate 
> > keywords whose names begin and end with ‘__’. Pedantic warnings are
> > also disabled in the expression that follows __extension__. However,
> > only system header files should use these escape routes; application
> > programs should avoid them. See Alternate Keywords. 
> >
> > Some users try to use -Wpedantic to check programs for strict ISO C
> > conformance. They soon find that it does not do quite what they want:
> > it finds some non-ISO practices, but not all—only those for which ISO
> > C requires a diagnostic, and some others for which diagnostics have
> > been added.
> > 
> > A feature to report any failure to conform to ISO C might be useful
> > in some instances, but would require considerable additional work and
> > would be quite different from -Wpedantic. We don’t have plans to
> > support such a feature in the near future.
> 
> What you appear to be asking for is not supported by gcc, and not going
> to be supported.

Here I'm not asking a feature to detect any portability issue
(indeed, this may be too complex), but a feature to detect a
*particular* portability issue. I don't think that adding an
option to blacklist <stdint.h> (implied by -Wpedantic in C90
mode) would be too complex.

> I thought autoconf tests were run using specific test code, not the
> actual source code you are distributing.  Surely you can avoid
> accidentally including <stdint.h> in the autoconf tests?

The autoconf test is there to detect whether <stdint.h> is available.
This is not by accident.

> And surely a quick "grep" will ensure that it is not used in the
> real source code?

"grep" does not allow one to detect conditional use.

> > The goal of -pedantic-errors is to *detect* that the developer writes
> > something like the above instead of just:
> > 
> > #include <stdint.h>
> > 
> 
> Since #include <stdint.h> does not break C90 conformity, then no.

So, why is -Woverlength-strings implied by -pedantic, though it does
not break C90 conformity?

> You /could/ ask for a warning flag -Wno-oversized-integers that would
> warn on the use of anything larger than "long" in C90 and anything
> larger than "long long" in C99 - much the same as -Woverlength-strings.

Yes, I was thinking of such a warning flag. But I was also thinking
that it would be implied by -pedantic, for consistency with
-Woverlength-strings.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)