Re: databases/sqlite on powerpc

[Taylor R Campbell <campbell+netbsd-tech-pkg%mumble.net@localhost>]

> Date: Fri, 24 Jun 2022 08:24:44 -0400
> From: Greg Troxel <gdt%lexort.com@localhost>
> 
> Roland Illig <roland.illig%gmx.de@localhost> writes:
> 
> > Are you sure about the UB? C11 6.3.1.3p3 and C11 6.5p4 say it's mostly
> > implementation-defined behavior, and GCC says at
> > https://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html that it
> > treats the sign bit as just another value bit.
> 
> Maybe I'm missing something, but implementation-defined code is not ok
> either.

`Implementation-defined' is not bad the way `undefined' is.

For example, from C11 5.1.2.2.1 `Program startup', clause 2 (p. 12):

  `If they are declared, the parameters to the main function shall
   obey the following constraints:
   [...]
  `- If the value of argc is greater than zero, the array members
     argv[0] through argv[argc-1] inclusive shall contain pointers to
     strings, which are given implementation-defined values by the
     host environment prior to program startup.'

Obviously it is OK to use the arguments in argv!

Or, from C11 6.5.3.4 `The sizeof operator', clause 4 (p. 80):

  `The value of the result is implementation-defined, ...'


The point here is that the integer interpretation of the bitwise-and
of two bit strings representing signed integers varies depending on
how signed integers are represented: two's-complement,
ones'-complement, or sign/magnitude (C11 6.2.6.2 `Integer types',
clause 2, pp. 38--39).

Some variation is allowed: on sign/magnitude or ones'-complement
machines, `negative zero' may be a trap representation, in which case,
e.g., -1 & -2 would be undefined behaviour.  However, I think the
undefined behaviour of bitwise operations (i.e., ~ & | ^) is limited
to that -- no other trap representations appear to be allowed as a
result of non-trap inputs (see clause 1 and footnote 44 of 6.2.6.2 on
p. 38, and clause 5 and footnote 45 on p. 39).

(But in any case, this is all academic because the code should be --
and has been patched upstream so that is -- using unsigned arithmetic
for the hash computation, which will almost certainly fix the issue.)