RE: is there small mistake in lib/vsprintf.c of kernel 2.4.20 ?

[Richard B. Johnson]

On Fri, 2 May 2003, Riley Williams wrote:

> Hi Richard.
>
>  >>>>> IOW, %d _does_ mean base=10.  base=0 is %i.  That goes
>  >>>>> both for kernel and userland implementations of scanf
>  >>>>> family (and for any standard-compliant implementation,
>  >>>>> for that matter).
>
>  > What!??????
>  >
>  > The base, in the kernel code is the number that you divide by
>  > to return the remainder for numerical conversions!  the base
>  > is 8 or octal, 10 for decimal, 16 for hexadecimal, and up to
>  > 36 for some other strange unused thing (all 26 letters of the
>  > alphabet).
>
> If you read the definition of the scanf() family of functions, you
> will note that a base of 0 is used to indicate that the standard C
> prefixes should be honoured, such that a number beginning with 0x
> is read as hexadecimal, a number beginning with 0 is read as octal
> and any other number is read as decimal. As a result, the value of
> 0 for base IS valid but is special cased.
>
> Think of it like the code that reads from a file. When the end of
> the file is reached, the "character" EOF (code -1) is returned.
> Such is not a valid character in the normal sense of the word, but
> a special case that the function can produce.
>
>  > If your conversion chances the base to 0, you divide by 0 (not
>  > good) and don't get a remainder. Actually  procedure number()
>  > protects against a base less than 2 or greater than 36 so you
>  > just prevent conversion altogether.
>
> If your conversion puts the base as 0, the code says "ah, we don't
> know what base to use, so we look at the first few digits to decide"
> and follows the above rules. Not a problem.
>
> Best wishes from Riley.
> ---

The base, shown in the definition in scanf() does not have any
correlation to the names of the internal variables used. The
current code, correctly uses the base of 10 when %d, %u, %l, and
all the other decimal variants are encountered, and correctly
uses base octal when %o is encountered, and correctly uses
base 16 when %x or its variations are encountered. The only
known problem is not a problem with base, but a problem with
scanning  the string because the standard allows 0x to preceed
a hexadecimal number.

Kevin Corry <[e-mail]>, submitted a patch which breaks
already working code in an aparent attempt to fix the leading
"0x" problem.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.