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

[Alejandro Colomar <alx.manpages@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 5823 bytes --]

Hi Wilco,

On 1/4/23 20:41, Wilco Dijkstra wrote:
> 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).

Okay; will mark it as deprecated.

> 
>> 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...

It's not about the keypresses.  It's more about how easy it is to insert a bug 
accidentally using memset(3), while it is very hard with bzero(3).

> 
>> 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.

Not at all.  mempcpy(3) is _very_ used, at least in projects where I work. 
Also, you could efficiently implement all string-copying functions with just 3 
functions: strlen(3), memchr(3), and mempcpy(3).

In NGINX it is used very extensively.  There it is used for copying strings 
where we know the length (since we store strings in structures where we store 
the length).  See:

alx@asus5775:~/src/nginx/nginx$ grep -rn ngx_memcpy | wc -l
256
alx@asus5775:~/src/nginx/nginx$ grep -rn ngx_cpymem | wc -l
259

ngx_memcpy() is NGINX's name for memcpy(3), and ngx_cpymem() is NGINX's name for 
mempcpy(3).

In NGINX Unit, which you can think of as NGINX 2.0 (that was the original 
intention, but it was repurposed to have more features and drop some others), 
the use of mempcpy(3) is even more pronounced compared to memcpy(3):

alx@asus5775:~/src/nginx/unit/master$ grep -rn nxt_memcpy | wc -l
97
alx@asus5775:~/src/nginx/unit/master$ grep -rn nxt_cpymem | wc -l
145

So use of mempcpy(3) compared to memcpy(3) is increasing in these high 
performance programs.

> 
>> 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?

C99 inline is a hybrid where the compiler can see the code, but it's not forced 
to inline, and still the symbol is only in the library.  So you can implement it 
in the same way as you'd implement it in extern functions, but switching the 
implementation to the .h file, and the prototype to the .c file.

You could even implement the actual symbol in assembly, but provide inline 
definitions that don't produce any new symbol.

> 
> 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.

I use C99 inline, which avoids the cost of static inline.  It provides a single 
symbol per function.

> 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!

I guess.  Although in some cases it feels like some things would be better if 
C89/GNU89 were unsupported.

<https://www.greenend.org.uk/rjk/tech/inline.html>

Cheers,

Alex

> 
> Cheers,
> Wilco

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]