On 12/01/2025 at 01:58, David Laight wrote: > On Sat, 11 Jan 2025 23:40:41 +0900 > Vincent Mailhol <mailhol.vinc...@wanadoo.fr> wrote: > >> On Thu. 9 Jan 2025 at 16:52, Vincent Mailhol <mailhol.vinc...@wanadoo.fr> >> wrote: > ... >> Actually, I did more investigation and it is working for some strange >> reasons. Whenever the argument of a function named strlen() is a >> compile time constant, the compiler (both GCC and clang) will replace >> it with the string length on the argument, even if strlen() is >> programmed to return something else: >> >> https://godbolt.org/z/nK4b3fnM7 >> >> So it is only working because the compiler uses its builtin strlen() >> instead of the function we provided. > > It depends on whether -ffreestanding is set. > If not set gcc/clang assume a lot of the basic libc functions have their > expected > behaviour.
Thanks! This rings a bell. More precisely, rather than -ffreestanding, it depends on -fno-builtin (which is implied by -ffreestanding). But some architectures do not provide these flags. Most famously, x86-64 has neither of -fno-builtin nor -ffreestanding c.f.: https://lore.kernel.org/all/20220306171009.1973074-1-mailhol.vinc...@wanadoo.fr/T/#u (above thread is a bit old, but I did a make V=1 to confirm that the flags are still missing as of today). And with either of -fno-builtin or -ffreestanding, the strlen() inline function doesn't work anymore as a static initializer (at least it didn't work in my tests on godbolt). So now, I am convinced that turning this strlen() in a function was a bad idea. I am glad I removed it in v2. Yours sincerely, Vincent Mailhol
