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