[PATCH 0/6] Support use of -fstrict-flex-arrays in user code

[Alejandro Colomar]

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
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/ad2b62db/attachment.sig>