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

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

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

Hi Wilco,

On 12/30/22 14:13, Wilco Dijkstra via Libc-alpha wrote:
> Hi Alex,
> 
>> It seems I misunderstood your email.  I've seen that glibc implements
>> rawmemchr(3) in terms of strlen(3) and memchr(3).  So it seems better to just
>> not implement this function in my library, and optimize strlen(3) directly.  The
>> non-'\0' case seems useless, so probably not worth this function unless I see a
>> use for it.
> 
> The idea is that compilers should treat it like mempcpy, bcopy etc and replace
> all uses with standard strlen/memchr. GCC/LLVM don't do this yet for rawmemchr.
> 
> Since it is not in any standard and there is no benefit of having it, we should
> obsolete this function along with all the other GNU extensions.

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.

However,

I wouldn't obsolete many functions indiscriminately, since most can be very 
useful for users:

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.

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

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


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.  Not 
glibc, but every libc.  It's a consequence of the turbulent design of the C 
library, with huge headers that provide monolithic libraries, which have many 
problems.

The solution would be to completely redesign the C library, without any regards 
to backwards compatibility in mind (but continue reading, it gets better).  If 
we had let's say several dozens of micro libraries that each provide just a few 
headers and functions, making most of the functions inline, the compiler 
wouldn't need to know what substitutions to perform, with few exceptions.

For example, a libc-mem microlibrary could implement:

<c/mem/chr/memchr.h>
	c_memchr()    // in terms of c_memchrend()
*	c_memchrend() // *like memchr(3), but return mem + size instead of NULL
<c/mem/chr/memrchr.h>
*	c_memrchr()
<c/mem/cmp/memcmp.h>
*	c_memcmp()
<c/mem/cpy/memcpy.h>
*	c_mempcpy()
	c_memcpy()    // in terms of c_mempcpy()
<c/mem/mem/memmem.h>
*	c_memmem()
<c/mem/mv/memmove.h>
*	c_mempmove()
	c_memmove()   // in terms of c_mempmove()
<c/mem/set/memset.h>
*	c_mempset()
	c_memset()    // in terms of c_mempset()
<c/mem/set/memzero.h>
	c_mempzero()  // in terms of c_mempset()
	c_bzero()     // in terms of c_mempzero()

Functions with a '*' would be the primitives, the ones that are optimized, and 
the others just wrappers around them.

See <http://www.alejandro-colomar.es/src/alx/alx/libc/libc-mem.git/tree/include>

Then, you could write a compatibility layer for the standard organization of 
headers would just include the necessary headers in the common ones (e.g., 
<string.h>), and alias without the c_* prefix (or __*, if you prefer it).

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 would even allow the kernel to use a large portion of the userspace C 
library: just link statically to the micro-libraries, but the inline definitions 
are fine to use inside a kernel.

I wrote a proof of concept, with already half a dozen of those micro-libraries 
just for fun here:

<http://www.alejandro-colomar.es/src/alx/alx/libc/>

For now, I wrote the primitives as calls to glibc, but it would be easy to flip 
the dependency so that glibc depends on the microlibraries, if they were 
extended enough for that.

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.

And another advantage of that model of a C library is that it allows replacing a 
single microlibrary, instead of having to replace the entire libc.  If I prefer 
the string-copying functions of library X, but the rest I prefer it from library 
Y, I could mix'n'match them easily.

Disadvantages:  C89 is forbidden (no inline, or GNU inline, which is worse).

So, it has a long list of advantages over the traditional libc.  Maybe it's 
worth thinking about it for the future.  :)


Cheers,
Alex

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

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