Re: strlen

[Jonny Grant <jg@jguk.org>]

On 07/07/2021 13:31, Alejandro Colomar (man-pages) wrote:
> On 7/7/21 2:22 PM, Alejandro Colomar (man-pages) wrote:
>> I disagree with this.  It is likely that the behavior is that, given the current implementation of Linux/GCC/glibc.  But it is undefined behavior, and anything can happen.  You should just try harder to avoid it, and not rely on any possible outcome of it.  GCC people may decide tomorrow to change the behavior to do some more agresive optimizations, and the documentation shouldn't preclude such a thing, as long as it's legal according to the relevant standards, and sane.
> 
> The standard (and implementations) define a set of thing you can do in C.  Those are an equilibrium between usability and room for optimizations.  Some things must remain undefined for the language to be more efficient and simple.
> 
> If the language, or an implementation of it, attempted to provide a defined behavior for absolutely everything, some optimizations could not be done, and also, it would be much harder to actually implement it (and also document it).  So for good reasons, UB (undefined behavior) remains undefined.
> 
> 
> Cheers,
> 
> Alex
> 
> 

Hi Alex, Florian

Do you think this would get optimized out by GCC too?

size_t safestrlen(const char * s)
{
    if (NULL == s) return 0;
    else return strlen(s);
}



Maybe the man page could just state:


NOTES

The calling strlen with a NULL pointer is undefined behavior.

Cheers, Jonny