Path: csiph.com!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: The difference between strtol() and strtoul() ? Date: Sun, 23 Jun 2024 20:11:09 -0700 Organization: None to speak of Lines: 60 Message-ID: <87ed8nt4qa.fsf@nosuchdomain.example.com> References: <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> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Mon, 24 Jun 2024 05:11:14 +0200 (CEST) Injection-Info: dont-email.me; posting-host="0a690d6294358a2c4bce5879f14e083a"; logging-data="799792"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19J6Vsq5AwRA+wRcsCjxEDb" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:LpImyr9NO8Nb+WOIaTPzs0e9R7s= sha1:tCbMz952iSakmilvYVOlCc7qLTQ= Xref: csiph.com comp.lang.c:386434 Kaz Kylheku <643-408-1753@kylheku.com> writes: > On 2024-06-23, Ben Bacarisse wrote: >> I don't want to pre-empt Tim's answer, but the wording that bothers me >> is >> >> "If the subject sequence begins with a minus sign, the value >> resulting from the conversion is negated (in the return type)." >> >> For strtoll("-9223372036854775808", 0, 0) the value resulting from the >> conversion is 9223372036854775808 which can not even be represented in >> the return type, so how can it be negated "in the return type"? > > We have to trust that the specification wants the functions to perform > error checking, rather than precipitate into undefined behavior or > implementation-defined results. > > If the negation, which is a positive value, cannot be represented in the > type, that implies it is out of range. The required behavior for a > positive out-of-range value is to return LLONG_MAX and set errno to > ERANGE. > > The "in the return type" wording sounds like it may be written that way > to cover the unsigned case, strtoull. > > I see in the N3220 draft that the signed and unsigned functions are > lumped together and the wording is now: > > "If the subject sequence begins with a minus sign, the resulting value > is the negative of the converted value; for functions whose return type > is an unsigned integer type this action is performed in the return > type." I should have checked the C23 draft before. I see that the wording has been improved. (Note that N3220 is actually an early draft of C26. The latest public pre-C23 draft is N3149. The content should be very close; I don't believe N3220 includes any post-C23 proposed changes.) It's fairly clear that the "value" referred to in the quoted text is a mathematical value, which might be outside the representable range of any C type. The paragraph describing the returned value confirms this: "If the correct value is outside the range of representable values ...". So for strtoll("-9223372036854775808", NULL, 10) the "converted value" of 9223372036854775808 exceeds LLONG_MAX, but that's ok. That value is negated (mathematically) yielding -9223372036854775808, which is equal to LLONG_MIN. 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). -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */