[PATCH] debug: State buffer overflow message more precisely

[Adhemerval Zanella Netto]

On 31/07/24 19:58, Richard wrote:
>>
>> No, I am saying that once your code rely in UB there is no much compiler/libc
>> can help the caller.  I have described the usage the triggered this issue [1]
>> and clearly what caller passed to strlcpy is a buffer of 1-byte size and then
>> libc correctly reported this a buffer-overrun due the source argument.
> 
> I've thought a bit about this and I honestly don't think what you call UB here is undefined behaviour.
> 
> I've read the C standard a few years ago and as far as I remember the language does not have a concept of tracking buffer sizes. C has pointers, but there is no knowing/tracking of buffer sizes at the language level. So saying "calling strlcpy() with a 1 byte buffer (and all the other context of the original problem) is undefined behaviour" is no well-defined statement. Because UB is a C standard term but you are talking about compiler extensions/features here. Those are not in the standard.
> 
> Of course I might be wrong and I've read the C99 standard back then. If there is something in C17 or C23 I've missed, could you point me to the page in the standard that introduces the concept you're referencing when you say UB?
> 

What I meant by UB is the expectation from the original program to call strlcpy
over a 1-byte buffer and expects that strlcpy buffer-overrun the output with
the input. 

The fortify implementation was created *exactly* to trigger on such usages,
since they are a constant source of API misuse.  The strlcpy in that case
could be replaced by a better call, like memcpy. 

So I still think the libc implementation is correct to trigger a buffer 
overflow error at time of the callsize since it is all the information the 
API and compiler has provided indicates the call was done a buffer smaller 
that the required size.