Re: bash-4.0 regression: negative return values

[Mike Frysinger]

On Monday 23 February 2009 00:25:57 Jon Seymour wrote:
> On Mon, Feb 23, 2009 at 4:03 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> > previous versions of bash would happily accept negative values ( treated
> > as a signed integer and masked with like 0xff), but it seems some changes
> > related to option parsing has broken that
> >
> > $ f(){ return -1; }; f
> > -bash: return: -1: invalid option
> > return: usage: return [n]
> >
> > POSIX states that the return value is an "unsigned decimal integer":
> > http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#t
> >ag_18_24_01
> >
> > but bash does not say that in the bash(1) man page ...
> > -mike
> For the record, GNU bash, version 3.2.39(20)-release (i686-pc-cygwin)
>
> behaves this way:
> > f() { return -1; }; f; echo $?
>
> 255

right, every version of bash before 4.0 has treated n as a signed int and 
masked it with 0xff.  so -1 is 255, -2 is 254, etc...

> Which, burnt me the other day. I think I prefer the way bash 4.0
> behaves because I would prefer to know that negative values are
> illegal than to have them silently co-erced to the corresponding
> unsigned integers . The bash 3.0 behaviour played havoc with a binary
> search algorithm that I wrote until I realised that -1 had been
> coerced to 255.

i think people need notice and/or warning of behavior changes.  and the 
documentation needs to be explicit.
-mike

signature.asc
Description: This is a digitally signed message part.