On Tue. 14 May 2022 à 20:11, Max Staudt <max@xxxxxxxxx> wrote: > On Sat, 14 May 2022 12:14:24 +0900 > Vincent Mailhol <vincent.mailhol@xxxxxxxxx> wrote: > > > But I still think it is possible to do pointer arithmetic. > > > > len = strnchr(elm->rxbuf, elm->rxfill, '\r') - elm->rxbuf; > > (I let you check that I did not do an off by one mistake). > > > > The above should also work with memchr(). Although the C standard > > doesn't allow pointer arithmetic on void *, GNU C adds an extension > > for that: https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html > > > > As I said before, your for loop is not fundamentally wrong, this is > > just not my prefered approach. You have my suggestion, choose what you > > prefer. > > Yeah, this is the arithmetic that I'd like to avoid here. In my > opinion, it is clearer with indices. > > If I were searching through a UTF-8 string (i.e. with variable width > chars), that'd be another matter entirely IMHO, and I'd rely on C > library functions that know more about UTF that I do. But it's really > just naked ASCII bytes this time. > > > ...unless memchr() may be faster than the loop? Could this happen? It depends on many factors, the length of the string, the architecture on which you compile it, whether the compiler decides to inline it or not… For long strings, there are some tricks to scan through the memory using 64 bits operation instead of doing it bytes per bytes. But there is a preparation overhead which makes it not worth it for small buffers. You can look at glibc implementation for reference: https://github.com/lattera/glibc/blob/master/string/memchr.c Of course, the kernel does not use glibc but often compilers __builtin_memchr() instead (one more time, it depends on the architecture). But it will give you an idea of why memchr() can be faster than the loop. Finally, the compiler might also detect your loop and take the initiative to replace it with a call to memchr(). You have to check the assembly to see if this is the case. For a device which speaks on UART which by nature is slow, optimizations are not critical, so readability is the priority, and is why I prefer using the library functions.
