On Monday 23 February 2009 00:25:57 Jon Seymour wrote:
> On Mon, Feb 23, 2009 at 4:03 PM, Mike Frysinger <vap...@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 $?
>
> 255right, 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.
