[9fans] atol() bug

[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.

Re: [9fans] atol() bug

[Steven Stallion]

[-- Attachment #1: Type: text/plain, Size: 653 bytes --]

from atof(2):

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


On Mon, Mar 11, 2013 at 3:09 PM, Bakul Shah <bakul@bitblocks.com> wrote:

> 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.
>
>

[-- Attachment #2: Type: text/html, Size: 1034 bytes --]

Re: [9fans] atol() bug

[Bakul Shah]

On Mon, 11 Mar 2013 15:44:05 PDT Steven Stallion <sstallion@gmail.com> wrote:
> from atof(2):
>
>      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).

Re: [9fans] atol() bug

[erik quanstrom]

On Mon Mar 11 18:56:04 EDT 2013, bakul@bitblocks.com wrote:
> On Mon, 11 Mar 2013 15:44:05 PDT Steven Stallion <sstallion@gmail.com> wrote:
> > from atof(2):
> >
> >      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

Re: [9fans] atol() bug

[Kurt H Maier]

On Mon, Mar 11, 2013 at 07:55:53PM -0400, erik quanstrom wrote:
> On Mon Mar 11 18:56:04 EDT 2013, bakul@bitblocks.com wrote:
> > On Mon, 11 Mar 2013 15:44:05 PDT Steven Stallion <sstallion@gmail.com> wrote:
> > > from atof(2):
> > >
> > >      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
>


http://25.media.tumblr.com/tumblr_l43szb1rFf1qb03ezo1_500.jpg

Re: [9fans] atol() bug

[Bakul Shah]

On Mon, 11 Mar 2013 19:55:53 EDT erik quanstrom <quanstro@quanstro.net> wrote:
> On Mon Mar 11 18:56:04 EDT 2013, bakul@bitblocks.com wrote:
> > On Mon, 11 Mar 2013 15:44:05 PDT Steven Stallion <sstallion@gmail.com> wrote:
> > > from atof(2):
> > >
> > >      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).

> 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?

Re: [9fans] atol() bug

[a]

// 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