Re: [RFC] _FORTIFY_SOURCE strictness

[Paul Eggert <eggert@cs.ucla.edu>]

On 4/6/22 23:26, Siddhesh Poyarekar wrote:

> Thoughts?  Maybe an Option 3 that's less worse than the above two options?

Perhaps we could use Option 1 (do nothing) for functions like snprintf, 
and Option 2 (abort only on actual overflows) for functions like strncpy.

For snprintf Option 1 is arguably allowed by the C standard, which says 
"If a function argument is described as being an array, the pointer 
actually passed to the function shall have a value such that all address 
computations and accesses to objects (that would be valid if the pointer 
did point to the first element of such an array) are in fact valid." In 
other words, if you call snprintf (a, n, ...) the implementation is 
allowed compute &a[0] through &a[n] even if it doesn't store into every 
byte in 'a' - and this means Option 1 is allowed.

For strncpy the situation is murkier and arguably something like Option 
2 would be needed, due to the funky way that the standard words the 
strncpy spec. However, this is not that important, since strncpy is (or 
at least should be) rarely used nowadays, so it's not that 
performance-relevant.

If we're lucky, most of the affected functions are more like snprintf 
than like strcpy, which means we can use Option 1 (do nothing) for most 
of the affected functions.