public inbox for linux-man@vger.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx@kernel.org>
To: Thomas Habets <thomas@habets.se>
Cc: linux-man@vger.kernel.org
Subject: Re: [patch] atoi.3: Document return value on under/overflow as undefined
Date: Mon, 11 Dec 2023 12:51:44 +0100	[thread overview]
Message-ID: <ZXb30b00FsKMtYlp@debian> (raw)
In-Reply-To: <CA+kHd+e1SQK1pVb5Uekc7y52QCH6c_qOM89D_8_dUcctsDD5rQ@mail.gmail.com>

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

Hi Thomas,

On Mon, Dec 11, 2023 at 02:53:31AM -0800, Thomas Habets wrote:
> On Sun, 10 Dec 2023 23:47:19 +0000, Alejandro Colomar <alx@kernel.org> said:
> > Yeah, I'm thinking in 50 years from now, assuming all implementations
> > have good intentions and don't want to break programs just because the
> > standard says they can.  Hopefully atoi(3) could be usable in half a
> > century; if the planet is still there.
> 
> Sure, one can lead by example. I wouldn't hold my breath that everyone
> follows, though. I definitely predict maintainers (cough, some BSDs,
> cough) saying "nobody should use ato*() anyway".

To that (very likely) response, I'd reply with:

	Then remove it from your libc.

I'm sure they'll then reply with something like

	"but the standard says the function should exist"

To which I have another reply:

	POSIX also specifies gets(3) as of the latest version
	(POSIX.1-2017), and everyone (rightly) removed it from libc.
	While atoi(3) doesn't produce such an obvious buffer overflow,
	it similarly invokes Undefined Behavior on conditions which the
	program can't control or prevent, which makes the function
	equally broken.

To which they may say:

	But it's not so broken to remove it.  It's just that the
	standard doesn't mandate to implement it in the sane way, so
	nobody did it.

Then I'd reply:

	Then go fix it.

At which point, they may get in an infinite loop, or just redirect to
/dev/null.

> > BTW, regarding your blog post about strtoul(3), I don't think it's so
> > hard to parse unsigned integers.  I couldn't reply to your blong without
> > logging in, but replied to the linked SO post:
> > <https://softwareengineering.stackexchange.com/a/449060/332848>
> 
> Ah, parse it twice to check. Yeah I'd not thought of that. Thanks. I'll add an
> update.

Great.  :)

Have a nice day,
Alex

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

      reply	other threads:[~2023-12-11 11:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-10 14:08 [patch] atoi.3: Document return value on under/overflow as undefined thomas
2023-12-10 20:35 ` Alejandro Colomar
2023-12-10 22:25   ` Thomas Habets
2023-12-10 23:47     ` Alejandro Colomar
2023-12-11 10:53       ` Thomas Habets
2023-12-11 11:51         ` Alejandro Colomar [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZXb30b00FsKMtYlp@debian \
    --to=alx@kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=thomas@habets.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox