Path: ...!feeds.phibee-telecom.net!3.eu.feeder.erje.net!feeder.erje.net!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: Sat, 22 Jun 2024 21:18:35 +0300
Organization: A noiseless patient Spider
Lines: 84
Message-ID: <20240622211835.00004b62@yahoo.com>
References: <v51d1l$2fklr$1@news.xmission.com>
	<v540t9$2gsdu$1@news.xmission.com>
	<20240621182839.00000dc4@yahoo.com>
	<20240621185314.00004fda@yahoo.com>
	<v54hc0$39bpi$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 22 Jun 2024 20:18:44 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="7a3173de95d34aa93b263d5871a07199";
	logging-data="4065153"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19crp6P02PVCaPbqQBztB8HdXRlX0Bi/PM="
Cancel-Lock: sha1:k+ksIhDNIBFO2vMeSCo7GUAPxNk=
X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)
Bytes: 4688

On Fri, 21 Jun 2024 14:38:56 -0400
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

> On 6/21/24 11:53, Michael S wrote:
> > On Fri, 21 Jun 2024 18:28:39 +0300
> > Michael S <already5chosen@yahoo.com> wrote:
> >   
> >> On Fri, 21 Jun 2024 13:58:01 -0000 (UTC)
> >> gazelle@shell.xmission.com (Kenny McCormack) wrote:  
> >>>
> >>> Yeah, now I get it.  You really only need strtoimax() and
> >>> strtoumax().   
> >>
> >> Which are? uunfortunately, not part of C standard.  
> 
> They have been part of the C standard since C99.
> 
> > BTW, I don't know what The Standard says about out-of-range inputs,
> > but at least https://en.cppreference.com/w/c/string/byte/strtol
> > does not say anything certain. especially about what stored in
> > *str_end.  
> 
> "The strtoimax and strtoumax functions are equivalent to the strtol,
> strtoll, strtoul, and strtoull functions, except that the initial
> portion of the string is converted to intmax_t and uintmax_t
> representation, respectively." (7.8.2.3p2)
> 
> You need to go to the descriptions of those other functions to get the
> detailed specifications.
> 
> "If the correct value is outside the range of representable values,
> LONG_MIN, LONG_MAX, LLONG_MIN, LLONG_MAX, ULONG_MAX, or ULLONG_MAX is
> returned (according to the return type and sign of the value, if any),
> and the value of the macro ERANGE is stored in errno."
> 
> As I understand it, that means that if the input string represents a
> value outside of the range of representable values, then strtoimax()
> should return INTMAX_MIN or INTMAX_MAX, depending upon the sign, and
> strtouimax() should return UINTMAX_MAX. Both of them should store the
> value of ERANGE in errno, to distinguish these results from what you
> would get if the string happened to represent those values.
> 

That what is done by my implementation, but I can not understand how it
follows from the text, esp. for a case of out of range negative input
for strtou**() functions.
That creates rather non-intuitive discontinuity.
  strtoull("-18446744073709551615") => 1
  strtoull("-18446744073709551616") => 18446744073709551615

> 
> The C standard uses end_ptr rather than str_end in it's description of
> these functions.
> 
> "... First, they decompose the input string into three parts: an
> initial, possibly empty, sequence of white-space characters, a subject
> sequence resembling an integer represented in some radix determined by
> the value of base, and a final string of one or more unrecognized
> characters, including the terminating null character of the input
> string. ..." (7.21.4.7p2).
> 
> That defines what the "final string" is.
> 
> "If the subject sequence has the expected form, ... A pointer to the
> final string is stored in the object pointed to by endptr, provided
> that endptr is not a null pointer." (7.24.1.7p5).
> 
> "If the subject sequence is empty or does not have the expected form
> ... the value of nptr is stored in the object pointed to by endptr,
> provided that endptr is not a null pointer." (7.21.4.7p7)
> 
> That seems very precise and unambiguous to me, aside from what "the
> expected form" is, which is described elsewhere.

Yes, this part of description is good and unambiguous.  
I wonder why cppreference.com had chosen to use less clear wording "The
functions set the pointer pointed to by str_end to point to the
character past the last numeric character interpreted."