[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