[9fans] atol() bug

[Bakul Shah]

The atol() manpage says:

Atoi and atol recognize an optional string of tabs and
spaces, then an optional sign, then a string of decimal dig-
its.

And yet atol(x) acts exactly like strol(x, nil, 0). This makes
it unnecessarily incompatible with the unix version. Ditto
for atoll(). My preference would be to fix the code and not
the man page.

[Steven Stallion]

from atof(2):

BUGS
Atoi, atol, and atoll accept octal and hexadecimal numbers
in the style of C, contrary to the ANSI specification.

Post by Bakul Shah
Atoi and atol recognize an optional string of tabs and
spaces, then an optional sign, then a string of decimal dig-
its.
And yet atol(x) acts exactly like strol(x, nil, 0). This makes
it unnecessarily incompatible with the unix version. Ditto
for atoll(). My preference would be to fix the code and not
the man page.

[Bakul Shah]

Post by Steven Stallion
BUGS
Atoi, atol, and atoll accept octal and hexadecimal numbers
in the style of C, contrary to the ANSI specification.

This BUG is obviously very easy to fix but it hasn't been....
Any good reason for this or just laziness? Anyway, more cruft
to remember (and debug when porting software).

[erik quanstrom]

Post by Bakul Shah

Post by Steven Stallion
BUGS
Atoi, atol, and atoll accept octal and hexadecimal numbers
in the style of C, contrary to the ANSI specification.

This BUG is obviously very easy to fix but it hasn't been....
Any good reason for this or just laziness? Anyway, more cruft
to remember (and debug when porting software).

there is a deep-seated assumption on the system that strtou?ll? accept
hex and octal. the fact that it's in the BUG section rather than fixed
means there are good reasons for not fixing it.

if you were to make this change, i would be surprised if you could
boot your kernel.

- erik

[Kurt H Maier]

Post by erik quanstrom

Post by Bakul Shah

Post by Steven Stallion
BUGS
Atoi, atol, and atoll accept octal and hexadecimal numbers
in the style of C, contrary to the ANSI specification.

This BUG is obviously very easy to fix but it hasn't been....
Any good reason for this or just laziness? Anyway, more cruft
to remember (and debug when porting software).

there is a deep-seated assumption on the system that strtou?ll? accept
hex and octal. the fact that it's in the BUG section rather than fixed
means there are good reasons for not fixing it.
if you were to make this change, i would be surprised if you could
boot your kernel.
- erik

Loading Image...

[Bakul Shah]

Post by erik quanstrom

Post by Bakul Shah

Post by Steven Stallion
BUGS
Atoi, atol, and atoll accept octal and hexadecimal numbers
in the style of C, contrary to the ANSI specification.

This BUG is obviously very easy to fix but it hasn't been....
Any good reason for this or just laziness? Anyway, more cruft
to remember (and debug when porting software).

there is a deep-seated assumption on the system that strtou?ll? accept
hex and octal. the fact that it's in the BUG section rather than fixed
means there are good reasons for not fixing it.

I assume you meant to write atou?ll? as strtou?ll? *do*
accept all three forms even in ANSI.

I am saying either make it ANSI compatible (my choice) or at
least fix the wording in the atof(2) that says "string of
decimal digits". If the behavior is intended why not say so
upfront and remove the BUGS section (or rename it to something
else).

Post by erik quanstrom
if you were to make this change, i would be surprised if you could
boot your kernel.

This is easy. Replace atou?ll?(x) with Atou?ll?(x) and map
these to the equivalent strou?ll?(x, nil, 0).

plan9 strings are not just ASCII anymore so the 'a' prefix
makes less sense now! Why not call them stou?ll? or utou?ll?
or something?

[a***@9srv.net]

// If the behavior is intended why not say so upfront and
// remove the BUGS section (or rename it to something else).

In Plan 9, the BUGS section is not really all about "bugs". This is
arguably unfortunate, but it's the way the system is. You might
check out
http://doc.cat-v.org/plan_9/misc/man_page_writing_howto
In particular, the section on BUGS says:
The BUGS section briefly lists shortcomings or other
‘‘gotchas’’ that the user should be aware of when using
the program. This is the place to mention things which
are unsatisfactory or tricky about the program, even if it
is not clear that they are bugs. Mentioning something in
a BUGS section does not imply a commitment to fix it.
Whenever you see the BUGS section in a Plan 9 man page,
mentally replace it with NOTE or BE CAREFUL ABOUT THIS BIT.

Changing the language in the actual description to be more
clear is largely an independent issue, and seems worthwhile.

// plan9 strings are not just ASCII anymore so the 'a' prefix
// makes less sense now!

More logically consistent, but I suspect originally this was a
concession to porting existing unix code, or a bad mental
habbit. At this point, it seems unreasonable to change.

Anthony