Paul Eggert <[email protected]> writes:
> On 2025-09-18 13:34, Bruno Haible wrote:
>> The compilers on FreeBSD 11 and OpenBSD 7.6 (at least) report give this
>> warning:
>> ../src/copy-file-data.c:585:7: warning: variable 'result' is used
>> uninitialized whenever 'if' condition is false
>> [-Wsometimes-uninitialized]
>
> I'm not seeing that on OpenBSD 7.7 which has clang version 16.0.6.
>
> I'm not a fan of 'abort' calls merely to pacify older, buggier
> compilers. That being said, a less-intrusive pacification change would
> be fine. Does the attached patch work for you? It uses 'unreachable'
> instead of 'abort' (except on compilers that lack 'unreachable' and
> where 'unreachable' is #defined to be 'abort', but that's OK).
This reminds me of a question that I had. What is the difference between
affirm (false) and unreachable ()? Does affirm (false) silence compiler
warnings that unreachable () doesn't?
If not, I find unreachable () to convey the meaning much better. If
there is no difference, any opposition to me running
'sed -i s|affirm (false)|unreachable ()|g src/*.c src/*.h'?
> While we're on the subject of bogus OpenBSD warnings, perhaps we
> should do something about OpenBSD's style nattering. Linker warnings
> like this:
>
> warning: strcpy() is almost always misused, please use strlcpy()
>
> are a waste of time for us, and we can fix them in Gnulib by defining
> our own strcpy that overrides OpenBSD's.
Yes, OpenBSD warns about many things which are perfectly safe. But I'm
not sure it is worth the time to spend overriding all of them.
Worth nothing that glibc does this as well, but is much more
conservative in deeming functions unsafe. When building Bash for
example:
/usr/bin/ld: ./lib/sh/libsh.a(tmpfile.o): in function `sh_mktmpname':
/home/collin/.local/src/bash/lib/sh/tmpfile.c:173:(.text+0x17a): warning:
the use of `mktemp' is dangerous, better use `mkstemp' or `mkdtemp'
That warning is more reasonable in my opinion. But Bash uses mkdtemp if
available, so it can be ignored.
Collin
