Re: Add <stdint.h> integer width macros

[Ovidiu M <mrovi9000 at gmail dot com>]

Thank you for the informative answer.

Indeed there was a _GNU_SOURCE defined in addition to the C99 option.
I have decided to replace it with _DEFAULT_SOURCE, as there were only
a couple of GNU specific features in use that had to be replaced.

It is not very clear to me what is the right way to prevent such
issues, but I am inclined to think bumping the C standard version is
the best option to introduce changes (although it may take more time).
Second best, versioning _GNU_SOURCE (or adding a new versioned
variable). This would allow people to write software that still
compiles years from now, without having to avoid GNU-specific
functions, as some of them are very useful.

On Sun, Mar 5, 2017 at 1:05 PM, Florian Weimer <fweimer@redhat.com> wrote:
> On 03/05/2017 10:50 AM, Ovidiu M wrote:
>>
>> Hi Joseph,
>>
>> The new macro SIZE_WIDTH conflicts with a definition in one of my
>> projects, breaking compilation (
>> https://gitlab.com/o9000/tint2/issues/625 ) with gcc 7 (which IIUC is
>> a pre-release version).
>
>
> Removing _GNU_SOURCE is a workaround which will address many such issues.
>
>> Could you please tell me if there is anything I can do about it, other
>> than renaming that variable?
>
>
> You can participate in glibc development.  Current consensus here is that
> _GNU_SOURCE should be adjusted in every release to reflect a superset of all
> standards supported by glibc (where those standards do not conflict).  This
> does have its problems, and particularly reckless ISO revisions might force
> the community to adopt.
>
> Another option is to participate in the ISO standardization process and
> explain to these people that new identifiers added to existing header files
> should use some construct (such as a suitable prefix) to reduce the risk of
> collisions.  Or perhaps non-core standards should stop patching existing
> header files altogether and add new ones, which would also resolve the
> backwards compatibility issue.
>
> At some point in the future, it is likely that switching to C++ will also
> reduce such issues because C++ relies less heavily on macros, and
> identifiers can be nested in namespaces.  At present, this is not really an
> option because the GNU C++ implementation (via libstdc++) relies on
> _GNU_SOURCE.
>
> Thanks,
> Florian