ash: Predefined macro $? gets wrong value

[dmik]

Given test.exe built using the following test.c

int main()
{
    return -1;
}

and the following script:

./test
echo $?

the output of sh.exe (from RPM ash-0.0.0-10.oc00) will be

-/

while it must be a positive number or 0. It may also return other garbage for other negative results (e.g. for the return value of 0xF00000 it will return -/0,(+)*).

This looks like unexpected behavior to me. I assume that such garbage will confuse many scripts. I faced it when trying to run ./configure of the m4 package.

This ticket depends on #26.

[dmik]

Another thing to note is that it seems that the exit code is assumed to be in range 0-255 by many shells. I.e. bash and REXX on OS/2 will return 255 for any negative value and also for any value that is higher than 255. I think that we should make ASH do the same.

JFYI, bash on Mac does something different. It tries to convert the result code to a byte-wide integer keeping its sign. This gives 255 for -1, 254 for -2 but sometimes the results are strange. I.e. for 0xF00000 it returns 0 here).

[dmik]

I tested this with dash which is about to replace ash (see #26). It seems that dash is free of this defect as well, the above test case prints -1 — i.e. exactly what I return from main(). Very good.

BTW, regarding bash on Mac. It looks like the executable itself does something like main() & 0xFF when it returns the result code to the system thus limiting it to be a 8-bit positive integer. This explains why you get such values. I think that this is a limitation of the system (or LIBC) itself rather than bash since all other shells (tried dash and yash here) behave just the same. This link ​http://stackoverflow.com/questions/5149228/main-return-value-range kind of proves this. On OS/2 the return value is a fair 32-bit signed integer hence we get -1 for the examble above.

The question is if we should limit the return value on OS/2 to match the Linux constraints. Most scripts are written with Linux in mind and may not expect any negative values or any values higher than 255... I will check the m4 package again.

[dmik]

I couldn't reproduce the m4 failure now so I can't test if it can stand negative values. But anyway, given the information from the link above (stating that on *nix the process return value in the wait() implementation is technically limited to 8 bits) I will force the same in our dash port to maintain better compatibility. Did that in r1119.