On 2026-07-26 Bruno Haible wrote:
> Looking at these functions only, one could view 'longword'
> as the effective type of this memory, and 'unsigned char' as a valid
> alternate way of accessing it.
>
> Are you concerned about these functions being inlined?
> They are in separate compilation units.
>
> Are you concerned about LTO optimization (global inlining across
> compilation units)?
In theory it can matter with LTO. Before LTO, translation unit
boundaries made this kind of tricks safe in practice. I don't know if
these specific cases can cause issues with LTO in the real world. I
just thought these were straightforward to fix (for compilers that
support the may_alias attribute), and I didn't see any downsides in the
fix.
As a side note, there's still undefined behavior:
SUMMARY: AddressSanitizer: heap-buffer-overflow
../../gllib/rawmemchr.c:119 in rawmemchr
SUMMARY: AddressSanitizer: heap-buffer-overflow
../../gllib/strchrnul.c:115 in rpl_strchrnul
This is expected though, see the comment in strchrnul.c lines 107-111.
It just isn't possible to write fast versions of these functions in
strictly standard C. Perhaps __attribute__((no_sanitize_address)) could
be used to silence it, but I'm not sure if that is a good idea, so I'm
not suggesting any changes.
--
Lasse Collin
