Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c
Subject: Re: The difference between strtol() and strtoul() ?
Date: Mon, 24 Jun 2024 13:19:41 +0300
Organization: A noiseless patient Spider
Lines: 20
Message-ID: <20240624131941.000057ee@yahoo.com>
References: <v51d1l$2fklr$1@news.xmission.com>
	<v540t9$2gsdu$1@news.xmission.com>
	<20240621182839.00000dc4@yahoo.com>
	<20240621185314.00004fda@yahoo.com>
	<87o77uqktg.fsf@bsb.me.uk>
	<20240623121952.00005fa9@yahoo.com>
	<87r0cnq46s.fsf@bsb.me.uk>
	<20240623153219.000009b0@yahoo.com>
	<87jzifpth6.fsf@bsb.me.uk>
	<864j9jh77d.fsf@linuxsc.com>
	<87r0cntga9.fsf@nosuchdomain.example.com>
	<87o77rnrt2.fsf@bsb.me.uk>
	<20240623191452.334@kylheku.com>
	<87ed8nt4qa.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 24 Jun 2024 12:19:22 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a033234f5eaff00d281aad432da64e4a";
	logging-data="884345"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18yS36UBAJYv4/OxpSzdeFLxLhBf+GS0Tc="
Cancel-Lock: sha1:K+e4/Imz2uv45yHJsA4tZH5KEXs=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 2301

On Sun, 23 Jun 2024 20:11:09 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

> 
> There's still some ambiguity for strtoull("-9999999999999999999",
> NULL, 10) (that's well outside the range of a 64-bit integer).  For
> that to work as expected, we have to assume that the determination
> that "the correct value is outside the range of representable values"
> happens *before* the negation "is performed in the return type".
> It's not clear that this problem is worth fixing (doing so would
> likely make that section longer and perhaps more confusing).
> 

There is nothing wrong with longer sections.
Personally I would prefer for each strtoxxx() function to have
its own description fully independent of all others. It would make
each of them easier to follow.
DRY is a good principle for programming, not necessarily for writing
Standards.