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

[Jonathan Wakely]

On 1 June 2017 at 12:52, Vincent Lefevre wrote:
> On 2017-06-01 13:14:50 +0200, David Brown wrote:
>> If you want to stick to C90, and you want to have a uintmax_t that
>> matches "long", then I suggest you don't include headers that are not
>                                  ^^^^^^^^^^^^^^^^^^^^^^^^^
>> relevant for C90, and define the types yourself.
>
> But that's the goal of -pedantic-errors!!! By using this option, I
> want to be able to detect the unconditional inclusion of <stdint.h>
> (actually I want it to be rejected by the autoconf test, which is
> the same thing in practice).
>
>>  Perhaps start with:
>>
>> #ifdef __STRICT_ANSI__
>> typedef long int intmax_t;
>> typedef unsigned long int uintmax_t;
>> #else
>> #include <stdint.h>
>> #endif
>
> The goal of -pedantic-errors is to *detect* that the developer writes
> something like the above instead of just:
>
> #include <stdint.h>

No, the goal of -pedantic-errors is not to be a portability checker or
conformance tester.

It's to disable standard-conflicting GNU extensions so that you get an
error when the standard requires a diagnostic.

C does not say you get a diagnostic if you write #include <stdint.h>
and there is a header called <stdint.h> in the search paths (because
as David says, the user could have placed one there and want it
included).

The manual is quite explicit about this:

"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."