On Fri, Jun 5, 2009 at 5:24 PM, Michael Abbott<[email protected]> wrote: > On Fri, 5 Jun 2009, Denys Vlasenko wrote: >> On Fri, Jun 5, 2009 at 3:15 PM, Michael Abbott<[email protected]> >> wrote: >> > On Fri, 5 Jun 2009, Michael Abbott wrote: >> > 1.13.3: >> > $ echo $((0x80000000 & 1)) >> > 0 >> > >> > 1.14.1: >> > $ echo $((0x80000000 & 1)) >> > 1 >> Looks like ash and bash act differently on arithmetic overflow. >> bash treats "too big" numbers as 0: >> >> # echo $((0x8000000000000000)) >> -9223372036854775808 >> # echo $((0x80000000000000000)) >> 0 >> >> and ash as -1 (all-ones). It just uses strtol internally, and that's >> what strtol returns. > > Oh, how horrible. I'd been assuming modulo-32-bit arithmetic.
There is no function in C library which would do that. strto[u][l]l error out if the string represents a number which does not fit into [unsigned] [long] long. It is easy to open-code it, but it's better to just emulate bash. This way, users have less PITA when they migrate from full-blown Linux system to (partially) busybox based one. >> Quick fix is to use CONFIG_SH_MATH_SUPPORT_64=y. Perhaps this is >> what you inadvertently switched off (because option name >> has changed in 1.14.x). > > Goodness me, you're quite right! I didn't realise I was using 64-bit > arithmetic... That will fix my immediate problem, thank you. > >> Complete fix is to add "errno = 0" and if() here in math.c: >> >> errno = 0; >> numstackptr->val = strto_arith_t(expr, (char **) >> &expr, 0); >> if (errno) >> numstackptr->val = 0; /* bash compat */ >> goto num; >> >> Does it work for you? > > Well, I actually I'd rather have modulo-2^32 arithmetic everywhere. Why is that better than to be bash compatible? -- vda _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
