[PATCH 0/6] Support use of -fstrict-flex-arrays in user code
Alejandro Colomar
alx@kernel.org
Sat Aug 12 13:29:00 GMT 2023
On 2023-08-12 13:07, Alejandro Colomar wrote:
> Hi Paul, Cristian,
>
> On 2023-08-12 00:10, Paul Eggert wrote:
>> On 2023-07-19 07:57, Cristian Rodríguez via Libc-alpha wrote:
>>>> Can't we use the already define __flexarr/__glibc_c99_flexarr_available
>>>> macro
>>>> instead?
>>>
>>> If I did only that, sizeof public structures may change causing an abi
>>> break.
>>
>> Why would it cause an ABI break?
>>
>> For example, no program's machine code should depend on sizeof (FTSENT).
>
> +1
>
>
>> fts.h's FTSENT is supposed to be an incomplete data type, like FILE: the
>> system allocates FTSENT objects, not user code. So I don't see the harm
>> in replacing [1] with [] in the definition of FTSENT's fts_name member,
>> if the compiler supports flex arrays.
>>
>
> I'll raise the bid, and claim that no valid program can depend on
> sizeof() of any struct with a flexible array member, of any kind (old
> `[1]`, zero-length `[0]`, nor standard `[]`).
>
> It is conceptually wrong to calculate sizeof() it, and the right thing to
> do is to call offseof(s, fam).
>
> In the best case, sizeof() will return the same as offsetof(3), and the
> program will happen to work. But in some cases, it will return a value
> slightly bigger (ISO C guarantees that it will not be smaller, for no
> reason I think), and in those cases, the program must have a bug. That
> bug can either be benign, and the program will just be wasting a few
> bytes, or it can be bad, and read memory a few bytes off from where it
> was written (still within the allocation bounds, so it won't crash; at
> least not directly due to that, but maybe by a secondary bug).
>
> See this GCC thread where I propose adding a warning when
Oops, I forgot to paste the link.
<https://inbox.sourceware.org/gcc/dac8afb7-5026-c702-85d2-c3ad977d9a48@kernel.org/T/>
> sizeof(flexi_struct) is used in arithmetics. There's an example program
> showing why sizeof() is (almost) always a bad thing with these structures.
> In the only use case where sizeof() is valid, reducing it wouldn't
> change program behavior (it's within a malloc(MAX(sizeof(s), ...));).
>
> Cheers,
> Alex
>
--
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20230812/a2280ae9/attachment.sig>
More information about the Libc-alpha
mailing list