Re: [Fwd: [PATCH] arithmetic - logical shift]
Pádraig Brady wrote: Also arithmetic right shift is not useful. While SAR (shift arithmetic right) is technically redundant with IDIV (integer divide), it's important in C programming where it is often used as an optimized special case of the latter. While this may not be especially important in shells, I'd be willing to argue that there is value in doing the same operation that C programmers expect. Well that means the result is compiler dependent. So scripts could give different results on another platform, or less often within a platform. Isn't the behavior of the C operator well-defined on signed integer types by the C standard? I would have expected that it is, and I would expect that defined behavior to be SAR, for the previously-mentioned reason. I would reiterate Chet's suggestion that you ask the Austin Group for clarification if you wish to continue this discussion. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- When on POSIX, do as POSIX mandates.
Re: [Fwd: [PATCH] arithmetic - logical shift]
Chet Ramey wrote: Pádraig Brady wrote: Original Message Date: Tue, 07 Oct 2008 11:55:51 +0100 From: Pádraig Brady [EMAIL PROTECTED] To: Chet Ramey [EMAIL PROTECTED] CC: [EMAIL PROTECTED] I was just discussing bit shifting with Tim Hockin using shell arithmetic expansion, and he pointed out that bash and ksh use arithmetic rather than logical shift for the operator. Actually, bash and ksh use whatever the native C compiler implements, since both just translate the and into the same operators internally. I don't see a really compelling reason to change, since, as you say, the standard requires signed long ints. Well that means the result is compiler dependent. So scripts could give different results on another platform, or less often within a platform. Also arithmetic right shift is not useful. Pádraig.
[Fwd: [PATCH] arithmetic - logical shift]
Original Message Date: Tue, 07 Oct 2008 11:55:51 +0100 From: Pádraig Brady [EMAIL PROTECTED] To: Chet Ramey [EMAIL PROTECTED] CC: [EMAIL PROTECTED] I was just discussing bit shifting with Tim Hockin using shell arithmetic expansion, and he pointed out that bash and ksh use arithmetic rather than logical shift for the operator. Now arithmetic shift is not useful on 2's compliment machines, and moreover it's compiler dependent as to whether arithmetic or logical shift is done for . Therefore to increase usefulness and decrease ambiguity I suggest applying something like the attached simple patch. I know the opengroup spec says to use signed ints, but I think that is intended to disambiguate input and output, rather than defining internal operations. Some sample output from the patched version: $ printf %x\n $((0x80001)) 4000 $ smax=$((-11)); echo $smax 9223372036854775807 $ echo $((-0x4000/2)) $((-0x40001)) -2305843009213693952 6917529027641081856 And corresponding output from unpatched bash: $ printf %x\n $((0x80001)) c000 $ smax=$((-11)); echo $smax -1 $ echo $((-0x4000/2)) $((-0x40001)) -2305843009213693952 -2305843009213693952 cheers, Pádraig. --- expr.arithmetic_shift.c 2008-10-06 07:35:09.0 + +++ expr.c 2008-10-06 07:11:44.0 + @@ -452,7 +452,7 @@ lvalue = value; break; case RSH: - lvalue = value; + lvalue = ((uintmax_t)lvalue) value; break; case BAND: lvalue = value; @@ -703,7 +703,7 @@ if (op == LSH) val1 = val1 val2; else - val1 = val1 val2; + val1 = ((uintmax_t)val1) val2; } return (val1);
