[PATCH] Remove __SIZE_TYPE__ usage (BZ 33969)

[lemon]

On March 11, 2026 12:34:57 p.m. UTC, Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> 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.
>
>But I have not fully check whether this would potentially cause a break,
>at least bmg with --full-gcc does not trigger any regression.
>
>I might remove this change from the patch, but it seems to be inconsistent
>to still require __SIZE_TYPE__ for some conditional support.  Should we
>close BZ 33969 as notabug?
>

For context, I encountered this problem with fcntl-linux.h when compiling software with my own C compiler (<https://codeberg.org/lsof/antcc>) that doesn't support most GNU extensions and provides its own definition for size_t in its builtin stddef.h, but still processes most glibc headers thanks to their effort to support non GNU compilers with various preprocessor safe guards. Codebases that were compiling before stopped working after glibc 2.43 due to that change in fcntl-linux.h. I reported only that use of __SIZE_TYPE__ because it's the one I tripped with.