Re: strlen

["Alejandro Colomar (man-pages)" <alx.manpages@gmail.com>]

On 7/7/21 3:31 PM, Jonny Grant wrote:
> 
> 
> 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);
> }

This would be optimized if the compiler can determine that s == NULL or 
s != NULL, which tipically would be that you ask the compiler to 
optimize, AND the compiler can deduce at compile time its relationship 
with NULL; OR you ask the compiler to optimize at link time (-flto) AND 
the relationship of s and NULL can be deduced at link time.

However, I don't see why that would be a problem.  Either you can 
guarantee that s is not NULL, and you don't need to call this 
safestrlen() wrapper, or you cannot guarantee it and then you are forced 
to call this wrapper.  The optimization, if it happens, will be good.

What I recommend you to do from time to time, to make sure you don't 
miss any warnings, is compile the whole project first with '-O3' and 
then with '-O0'.  If you are a bit paranoic, sporadically you can try 
all of them : '-Og', '-O0', '-O1', '-Os', '-O2', '-O3', '-Ofast' but I 
don't think that is necessary.  Of course, always use '-fanalyzer' (GCC 
10 and above).

> 
> 
> 
> Maybe the man page could just state:
> 
> 
> NOTES
> 
> The calling strlen with a NULL pointer is undefined behavior.

Okay.  I agree that should probably be documented.
I'm surprised it's not documented already.  Not even in the glibc manual 
(or I couldn't find it).

There are a lot of functions that should get this addition, though.  I'd 
like to patch them all at once.  I'll try to find a list of functions 
documented in the man pages and that have nonnull in the 
oimplementation.  If I don't come back soon with a list, please ping me.

Thanks,

Alex


-- 
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/