From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@9fans.net Date: Mon, 11 Mar 2013 15:09:07 -0700 From: Bakul Shah Message-Id: <20130311220907.46195B82A@mail.bitblocks.com> Subject: [9fans] atol() bug Topicbox-Message-UUID: 274e31c8-ead8-11e9-9d60-3106f5b1d025 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. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <20130311220907.46195B82A@mail.bitblocks.com> References: <20130311220907.46195B82A@mail.bitblocks.com> Date: Mon, 11 Mar 2013 15:44:05 -0700 Message-ID: From: Steven Stallion To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=047d7b86f76a0c21eb04d7ade9f9 Subject: Re: [9fans] atol() bug Topicbox-Message-UUID: 27572fee-ead8-11e9-9d60-3106f5b1d025 --047d7b86f76a0c21eb04d7ade9f9 Content-Type: text/plain; charset=ISO-8859-1 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 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. > > --047d7b86f76a0c21eb04d7ade9f9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
from atof(2):

= =A0 =A0 =A0BUGS
=A0 =A0 =A0 =A0 =A0 Atoi, atol, and atoll accept = octal and hexadecimal numbers
=A0 =A0 =A0 =A0 =A0 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:

=A0 =A0 =A0 =A0 =A0 Atoi and atol recognize an optional string of tabs and<= br> =A0 =A0 =A0 =A0 =A0 spaces, then an optional sign, then a string of decimal= dig-
=A0 =A0 =A0 =A0 =A0 its.

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


--047d7b86f76a0c21eb04d7ade9f9-- From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Mon, 11 Mar 2013 15:44:05 PDT." References: <20130311220907.46195B82A@mail.bitblocks.com> Date: Mon, 11 Mar 2013 15:55:16 -0700 From: Bakul Shah Message-Id: <20130311225516.2EF5CB82A@mail.bitblocks.com> Subject: Re: [9fans] atol() bug Topicbox-Message-UUID: 27621526-ead8-11e9-9d60-3106f5b1d025 On Mon, 11 Mar 2013 15:44:05 PDT Steven Stallion 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). From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Mon, 11 Mar 2013 19:55:53 -0400 To: 9fans@9fans.net Message-ID: <71d5bd1d0ba63c9e3643e932561e1a69@ladd.quanstro.net> In-Reply-To: <20130311225516.2EF5CB82A@mail.bitblocks.com> References: <20130311220907.46195B82A@mail.bitblocks.com> <20130311225516.2EF5CB82A@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] atol() bug Topicbox-Message-UUID: 27694a08-ead8-11e9-9d60-3106f5b1d025 On Mon Mar 11 18:56:04 EDT 2013, bakul@bitblocks.com wrote: > On Mon, 11 Mar 2013 15:44:05 PDT Steven Stallion 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 11 Mar 2013 20:25:11 -0400 From: Kurt H Maier To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20130312002510.GA28452@intma.in> References: <20130311220907.46195B82A@mail.bitblocks.com> <20130311225516.2EF5CB82A@mail.bitblocks.com> <71d5bd1d0ba63c9e3643e932561e1a69@ladd.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <71d5bd1d0ba63c9e3643e932561e1a69@ladd.quanstro.net> Subject: Re: [9fans] atol() bug Topicbox-Message-UUID: 276f5484-ead8-11e9-9d60-3106f5b1d025 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 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 From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Mon, 11 Mar 2013 19:55:53 EDT." <71d5bd1d0ba63c9e3643e932561e1a69@ladd.quanstro.net> References: <20130311220907.46195B82A@mail.bitblocks.com> <20130311225516.2EF5CB82A@mail.bitblocks.com> <71d5bd1d0ba63c9e3643e932561e1a69@ladd.quanstro.net> Date: Mon, 11 Mar 2013 17:40:09 -0700 From: Bakul Shah Message-Id: <20130312004009.0D736B834@mail.bitblocks.com> Subject: Re: [9fans] atol() bug Topicbox-Message-UUID: 27753a84-ead8-11e9-9d60-3106f5b1d025 On Mon, 11 Mar 2013 19:55:53 EDT 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 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? From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@9fans.net Date: Tue, 12 Mar 2013 17:05:56 -0400 From: a@9srv.net Message-ID: <762806b80f61840eb905ae8dc086fefa@9srv.net> In-Reply-To: <20130312004009.0D736B834@mail.bitblocks.com> References: <20130311220907.46195B82A@mail.bitblocks.com> <20130311225516.2EF5CB82A@mail.bitblocks.com> <71d5bd1d0ba63c9e3643e932561e1a69@ladd.quanstro.net> <20130312004009.0D736B834@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] atol() bug Topicbox-Message-UUID: 2820d1f0-ead8-11e9-9d60-3106f5b1d025 // 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 =E2=80=98=E2=80=98gotchas=E2=80=99=E2=80=99 that the user should be awar= e 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