[PATCH] Remove __SIZE_TYPE__ usage (BZ 33969)
Adhemerval Zanella Netto
adhemerval.zanella@linaro.org
Thu Mar 12 18:09:55 GMT 2026
On 11/03/26 18:53, Joseph Myers wrote:
> On Wed, 11 Mar 2026, Adhemerval Zanella Netto wrote:
>
>> On 10/03/26 20:07, Joseph Myers wrote:
>>> On Tue, 10 Mar 2026, Adhemerval Zanella wrote:
>>>
>>>> The ‘fcntl-linux.h’ and ‘cdefs.h’ changes are straightforward
>>>> because size_t is already defined. The glob.h change uses
>>>> stddef.h as other installed headers.
>>>
>>> Could you give more details of your analysis for <sys/cdefs.h>, for what
>>> headers under what feature test macros use any of the relevant macros from
>>> <sys/cdefs.h>? (Since certainly <sys/cdefs.h> is used in lots of
>>> installed headers that don't and can't define size_t in standard C modes,
>>> so the question is when the particular macros therein that would use
>>> size_t themselves get used.)
>>>
>>
>> The __SIZE_TYPE__ is used solely for fortify support, which itself adds
>> additional constrains of what compiler needs to provide (__GNUC_,
>> __USE_EXTERN_INLINES, __fortify_function). Also, some of the fortify
>> wrappers themselves add an implicit requirement of size_t.
>
> The question is: which installed headers use this fortify support, and do
> all such headers define size_t unconditionally (or, failing that, for all
> conditions under which the fortify support is used)? For example,
> <string.h> defines size_t, so there is certainly no problem for any use of
> these fortify macros from <string.h>.
>
Right, my assumption is since fortify is a GNU extension we could define
that size_t would be defined (as I did for poll2.h). But it seems that
_FORTIFY_SOURCE is not really tied to _GNU_SOURCE, so I think I will need
to fallback and not change any fortify header. I will send a new version
just for fcntl-linux.h.
More information about the Libc-alpha
mailing list