Bug#697017: An improved patch over Jonathan's

[Gabriel Klawitter <gabreal@lavabit.com>]

On 12/31/2012 10:08 PM, Stephen Powell wrote:

> 
> Try the following at a shell prompt:
> 
>    a=$((0xffff))
>    echo $a
>    a=$((0xFFFF))
>    echo $a
>    a=$((0xcompute))
> 
> The first two assignment statements produce no errors, and the result
> of the echo command is 65535 in both cases, but the third assignment
> statement gets a syntax error and the value of the variable "a" remains
> unchanged.  In bash, I get the error
> 
>    bash: 0xcompute: value too great for base (error token is "0xcompute")
> 

Hi Stephen,

sorry for the ambiguity. I did't mean cases like 0xffff and 0xFFFF but
the cases for which this function is being used. These are, as far as
I've understood your post correctly, the case where root equals
something like 08:02 and root equals a hex decimal numer with at most 4
digits like abcd.

The evaluation a=$((0xcompute)) might leave the value of the variable
intact but the script fails and init dies.(http://pastebin.com/7BJAY1Wj)


Your patch will sort out cases like 08:02 but not the case where root
equals 'facade', 'added' or 'dead01'.

I'm using the root= parameter for giving the name of the boot profile,
which might differ from 'compute'. With your patch 'dead01' would still
be interpreted as a hex number which would be parsed correctly this
time, but the function would evaluate it as a hex number that'd be
changed for lilo compatibility. This is a rare case and I could
circumvent it by requiring that the root string shouldn't contain only
hex digits.


I haven't tested your patch yet, as I'm convinced that it'll work fine
for root=compute but not for root=facade01.


Thanks and best regards,
Gabriel