Re: fossil build failure on riscv64
On Wed, 2025-04-16 at 15:14 +0100, Barak A. Pearlmutter wrote:
> Okay, the problem was this code, when called with iVal being the most
> negative int:
>
> int Th_SetResultInt(Th_Interp *interp, int iVal){
> int isNegative = 0;
> unsigned int uVal = iVal;
> char zBuf[32];
> char *z = &zBuf[32];
>
> if( iVal<0 ){
> isNegative = 1;
> uVal = iVal * -1;
> }
> *(--z) = '\0';
> *(--z) = (char)(48+(uVal%10));
> while( (uVal = (uVal/10))>0 ){
> *(--z) = (char)(48+(uVal%10));
> assert(z>zBuf);
> }
> if( isNegative ){
> *(--z) = '-';
> }
>
> return Th_SetResult(interp, z, -1);
> }
>
> The expression (char)(48+(uVal%10)), which is intended to be a digit
> character '0' to '9', was coming out to values *below* 48, which are
> ASCII periods and parens and such. Since uVal is unsigned, it seems
> like this should not happen. So it's a compiler bug. (I think! Because
> maybe the "uVal = iVal * -1" is 'undefined' when iVal is the most
> negative 32-bit int, since then "iVal * -1" is not representable as a
> signed int, and this licenses the compiler to shoot flaming monkeys
> out its nose.)
Without looking at the details of the code, but could this be related
to the signedness of char? On riscv64, it seems that char is unsigned
while it's signed on x86_64, for example [1].
Might be better to explicitly use "signed char" when that's wanted.
Adrian
> [1] https://trofi.github.io/posts/203-signed-char-or-unsigned-char.html
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Reply to: