Re: [manual]: rawmemchr(3) and UB

[Wilco Dijkstra <Wilco.Dijkstra@arm.com>]

Hi Alex,

> I'm fine deprecating rawmemchr(3) in the manual page if you suggest it.  I don't 
> see any use cases for it.  If you confirm, I'll do it.

Yes, I don't see the point, the main use-case appears to be for s + strlen (s) but
is often slower since targets may implement it like memchr (which is more
complex than searching just for zero).

> bzero(3) is much more useful than memset(3).  I've only used memset(3) for 
> something non-zero once in my life, IIRC.  Writing bzero(p, n) is easier to get 
> right, and simpler.

It may save a few keypresses but it's dead so all you're doing is confuse people
who have never heard of it...

> mempcpy(3) is also much more useful than memcpy(3) (and in fact, It would be 
> great if glibc optimized mempcpy(3) and then implemented memcpy(3) in terms of it).

It makes no sense at all to support memcpy in terms of mempcpy since the latter is
rarely used. Even if is supported in a libc, it's often not optimized... So a redesigned
memcpy would obviously return 'void' as very few calls use a return value.

> bcopy(3) is already deprecated in the manual page.  That function is dead.

Good. Progress!

> My opinion is that moving the responsibility of providing inline versions of 
> functions to the compiler, is just a consequence of the mess that libc is.

Compilers aren't just inlining, they are *optimizing*. GLIBC string.h used to
thousands of lines of complex macros and inline functions trying to handoptimize
every special case in many string functions. I ripped it all out and the generated
code is now better since the compiler optimizes it.

> For example, a libc-mem microlibrary could implement:

I don't get what the supposed benefit would be of having both 'p' and
non-'p' variants of most of these. Yes, for some str* variants it is better to return
the end rather than the start since that can avoid an extra strlen call. However
I can't see any benefit for the mem* ones that don't return a value. It's simply
extra overhead to return a value, which in almost all cases won't be used...

> Having the function definitions inline allows the compiler to see the entire 
> dependency until the primitive definitions, and optimize as much as is possible.

That's fine for simple syntactic sugar, but it doesn't work in complex cases.

> In some benchmark I wrote recently for a string-copying function that I proposed 
> for glibc (stpecpy(3)), this library of mine outperforms any other definition of 
> it by a very large margin, just by making it inline.  Of course, I expect that 
> if enough code is added to GCC, using the normal definition would be as fast, 
> but the point is that this doesn't require optimizing code in the compiler to 
> get really fast code.

Again this works fine for syntactic sugar where the compiler will always inline and
optimize the underlying primitives. If you define new functionality or something
more complex (say memrchr before it existed) then how are you going to
implement it efficiently in an inline function?

Also you still need to add the symbol to a library as well or pay the cost of having
multiple outline copies of the same static inline function when the compiler isn't
able to inline for whatever reason. So yeah we've been there done that with GLIBC
headers, and it was a total mess. There are still exported symbols for internal inline
functions that we have to keep supporting for backwards compatibility...

So there are good reasons we do stuff the way we do - it works!

Cheers,
Wilco