Bug#697017: An improved patch over Jonathan's

[Stephen Powell <zlinuxman@wowway.com>]

On Mon, 31 Dec 2012 12:24:44 -0500 (EST), Gabriel Klawitter wrote:
> 
> thank you for the efforts to solve the problem.
> 
> Maybe I missed something, but isn't the case that is to be sorted out
> (for major/minors) the one that has a colon surrounded by digits (like
> [0-9]*:[0-9]*) and the case where the root string contains at most 4 hex
> digits?
> 
> Why do not match the cases exactly as suggested by your second reply?

I'm confused, Gabriel.  I don't understand what you are asking.
As I see it, "root=compute", which is what you are specifying,
starts with the letter "c", which is a valid hexadecimal digit.
Therefore, the parse_numeric function tries to treat the whole
string as a hexadecimal number, even though it contains non-valid
hex digits, and that causes a syntax error in the shell.  The case
of the letter doesn't matter.

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")

In ash, I get

   ash: arithmetic syntax error

in dash, I get

   dash: 1: arithmetic expression: expecting EOF: "0xcompute"

The exact error message differs depending on which shell is being used,
but an error results in every case.  This will cause a script to
bomb off.  The latest patch proposal fixes this, so that the conversion
is not attempted, as well as fixing some other numeric conversion errors
that you have not encountered.  Have you tried the patch?  (You will of
course need to rebuild the initial RAM file system after applying the
patch.)

-- 
  .''`.     Stephen Powell    
 : :'  :
 `. `'`
   `-