Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #386268 > unrolled thread

The difference between strtol() and strtoul() ?

Back to article view | Back to comp.lang.c

Contents

  The difference between strtol() and strtoul() ? gazelle@shell.xmission.com (Kenny McCormack) - 2024-06-20 14:06 +0000
    Re: The difference between strtol() and strtoul() ? scott@slp53.sl.home (Scott Lurndal) - 2024-06-20 14:46 +0000
      Re: The difference between strtol() and strtoul() ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-20 14:37 -0700
    Re: The difference between strtol() and strtoul() ? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-06-20 14:48 +0000
    Re: The difference between strtol() and strtoul() ? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-06-20 15:26 +0000
    Re: The difference between strtol() and strtoul() ? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-20 22:55 +0000
      Re: The difference between strtol() and strtoul() ? gazelle@shell.xmission.com (Kenny McCormack) - 2024-06-20 23:35 +0000
    Re: The difference between strtol() and strtoul() ? gazelle@shell.xmission.com (Kenny McCormack) - 2024-06-21 13:58 +0000
      Re: The difference between strtol() and strtoul() ? Michael S <already5chosen@yahoo.com> - 2024-06-21 18:28 +0300
        Re: The difference between strtol() and strtoul() ? Michael S <already5chosen@yahoo.com> - 2024-06-21 18:53 +0300
          Re: The difference between strtol() and strtoul() ? scott@slp53.sl.home (Scott Lurndal) - 2024-06-21 16:14 +0000
            Re: The difference between strtol() and strtoul() ? scott@slp53.sl.home (Scott Lurndal) - 2024-06-21 16:54 +0000
              Re: The difference between strtol() and strtoul() ? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-22 06:44 +0000
                Re: The difference between strtol() and strtoul() ? scott@slp53.sl.home (Scott Lurndal) - 2024-06-22 15:16 +0000
                  Re: The difference between strtol() and strtoul() ? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-22 23:21 +0000
                  Re: The difference between strtol() and strtoul() ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-22 20:10 -0400
          Re: The difference between strtol() and strtoul() ? Ben Bacarisse <ben@bsb.me.uk> - 2024-06-21 18:15 +0100
            Re: The difference between strtol() and strtoul() ? Michael S <already5chosen@yahoo.com> - 2024-06-23 12:19 +0300
              Re: The difference between strtol() and strtoul() ? Ben Bacarisse <ben@bsb.me.uk> - 2024-06-23 12:38 +0100
                Re: The difference between strtol() and strtoul() ? Michael S <already5chosen@yahoo.com> - 2024-06-23 15:32 +0300
                  Re: The difference between strtol() and strtoul() ? Ben Bacarisse <ben@bsb.me.uk> - 2024-06-23 16:30 +0100
                    Re: The difference between strtol() and strtoul() ? Michael S <already5chosen@yahoo.com> - 2024-06-23 18:47 +0300
                    Re: The difference between strtol() and strtoul() ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-23 10:58 -0700
                      Re: The difference between strtol() and strtoul() ? scott@slp53.sl.home (Scott Lurndal) - 2024-06-23 21:19 +0000
                        Re: The difference between strtol() and strtoul() ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-23 22:28 -0700
                      Re: The difference between strtol() and strtoul() ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-23 16:01 -0700
                        Re: The difference between strtol() and strtoul() ? Ben Bacarisse <ben@bsb.me.uk> - 2024-06-24 00:49 +0100
                          Re: The difference between strtol() and strtoul() ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-23 17:49 -0700
                          Re: The difference between strtol() and strtoul() ? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-24 02:29 +0000
                            Re: The difference between strtol() and strtoul() ? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-24 02:31 +0000
                              Re: The difference between strtol() and strtoul() ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-23 20:12 -0700
                                Re: The difference between strtol() and strtoul() ? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-24 06:05 +0000
                            Re: The difference between strtol() and strtoul() ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-23 20:11 -0700
                              Re: The difference between strtol() and strtoul() ? Michael S <already5chosen@yahoo.com> - 2024-06-24 13:19 +0300
                        Re: The difference between strtol() and strtoul() ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-23 22:30 -0700
                    Re: The difference between strtol() and strtoul() ? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-24 00:48 +0000
          Re: The difference between strtol() and strtoul() ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-21 14:38 -0400
            Re: The difference between strtol() and strtoul() ? gazelle@shell.xmission.com (Kenny McCormack) - 2024-06-21 18:43 +0000
              Re: The difference between strtol() and strtoul() ? Michael S <already5chosen@yahoo.com> - 2024-06-23 11:47 +0300
            Re: The difference between strtol() and strtoul() ? Michael S <already5chosen@yahoo.com> - 2024-06-22 21:18 +0300
        Re: The difference between strtol() and strtoul() ? Ben Bacarisse <ben@bsb.me.uk> - 2024-06-21 18:02 +0100
          Re: The difference between strtol() and strtoul() ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-21 10:38 -0700
            Re: The difference between strtol() and strtoul() ? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-22 06:43 +0000
            Re: The difference between strtol() and strtoul() ? Michael S <already5chosen@yahoo.com> - 2024-06-22 21:04 +0300
              Re: The difference between strtol() and strtoul() ? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-22 23:22 +0000
              Re: The difference between strtol() and strtoul() ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-22 16:43 -0700
      Re: The difference between strtol() and strtoul() ? Michael S <already5chosen@yahoo.com> - 2024-06-21 19:00 +0300
        Re: The difference between strtol() and strtoul() ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-21 10:50 -0700
      Re: The difference between strtol() and strtoul() ? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-22 22:07 +0000
    Re: The difference between strtol() and strtoul() ? Richard Kettlewell <invalid@invalid.invalid> - 2024-06-23 17:39 +0100

Page 1 of 3  [1] 2 3  Next page →

#386268 — The difference between strtol() and strtoul() ?

Interestingly, I note that strtoul() accepts strings that begin with a sign
(+ or -).  This is odd, since you'd (*) think that a sign (particularly, a
minus) would be a syntax error in parsing for an unsigned value.

Further, although the (Linux) man page is more than a bit murky on the
subject, it seems that the result of parsing, say, "-1", with strtoul() is
the largest unsigned value (usually, 2**N-1 or a lot of F's (in hex)).
Whereas, I would expect it to be 1 (i.e., just take the absolute value).

Comments?  I find this all very counterintuitive.

(*) Or should I say, "one would" ?

P.S.  Why isn't there a strtoi() or strtou() ?  I know, of course, that
there is atoi(), but that doesn't have the error checking capability that
the strto* functions have.

-- 
If you think you have any objections to anything I've said above, please
navigate to this URL:
    http://www.xmission.com/~gazelle/Truth
This should clear up any misconceptions you may have.

[toc] | [next] | [standalone]

#386269

gazelle@shell.xmission.com (Kenny McCormack) writes:
>Interestingly, I note that strtoul() accepts strings that begin with a sign
>(+ or -).  This is odd, since you'd (*) think that a sign (particularly, a
>minus) would be a syntax error in parsing for an unsigned value.

The strtoul/strtoull function semantics match the C language semantics.

$ cat /tmp/a.c
#include <stdio.h>
int main(int argc, const char **argv)
{
    unsigned long v = -1ul;

    printf("0x%lx\n", v);
    return 0;
}
$ cc -Wall -Werror -o /tmp/a /tmp/a.c
$ /tmp/a                             
0xffffffffffffffff
$ 

[toc] | [prev] | [next] | [standalone]

#386291

scott@slp53.sl.home (Scott Lurndal) writes:
[snip]
> The strtoul/strtoull function semantics match the C language semantics.
>
> $ cat /tmp/a.c
> #include <stdio.h>
> int main(int argc, const char **argv)
> {
>     unsigned long v = -1ul;
>
>     printf("0x%lx\n", v);
>     return 0;
> }
> $ cc -Wall -Werror -o /tmp/a /tmp/a.c
> $ /tmp/a                             
> 0xffffffffffffffff
> $ 

The functions accept a syntax that doesn't exactly match anything
in C's grammar.

Both accept integer constants and a restricted subset of other
integer constant expressions.  "1", "+1", and "-1" are accepted.
"1+1" is not (nor is "- 1").

For signed integers, that's perfectly reasonable; +1 and -1 are
expressions, not constants, but users are not likely to care about
the distinction.  These functions deal with user input, not C syntax.

For unsigned integers, it would have made sense to disallow signs,
or at least disallow leading '-'.  The behavior of unary "-" for
unsigned integers is well defined, but probably not something that
users should need to be aware of when providing program input.

My guess is that the authors of strtol and strtoul thought
consistency between the two functions was important, and I'm not
sure I disagree -- but interpreting "-1" as 18446744073709551615
can certainly be counterintuitive.

The ANSI C Rationale indicates that the strto*() functions were
adopted from UNIX System V.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#386270

On Thu, 20 Jun 2024 14:06:45 +0000, Kenny McCormack wrote:

> Interestingly, I note that strtoul() accepts strings that begin with a sign
> (+ or -).  This is odd, since you'd (*) think that a sign (particularly, a
> minus) would be a syntax error in parsing for an unsigned value.

IIUC, the ISO C standard does not make a distinction between strings that
make sense for an unsigned long vs strings that make sense for a signed long.
The standard says (with regards to the strtol, strtoll, strtoul, and strtoull
functions):
  "... the expected form of the subject sequence is a sequence of letters
   and digits representing an integer with the radix specified by base,
   optionally preceded by a plus or minus sign ... . If the value of base
   is 16, the characters 0x or 0X may optionally precede the sequence of
   letters and digits, following the sign if present."
so, it appears that the ISO C standard permits the input string to specify
a sign, even if the resulting conversion does not.


> Further, although the (Linux) man page is more than a bit murky on the
> subject, it seems that the result of parsing, say, "-1", with strtoul() is
> the largest unsigned value (usually, 2**N-1 or a lot of F's (in hex)).
> Whereas, I would expect it to be 1 (i.e., just take the absolute value).

Why would you expect that? Again, the ISO standard says:
  "If the subject sequence has the expected form ... it is used as the base
   for conversion, ascribing to each letter its value ... . If the subject
   sequence begins with a minus sign, the value resulting from the conversion
   is negated (in the return type)."
and
  "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) ... ."


> Comments?  I find this all very counterintuitive.

I can't comment on /your/ internalization of the standards and expected
behaviour. But, the standard makes sense (in an eccentric sort of way)
to me, in that the defining distinction of the various strto*l() functions
is not the format of the input, but the format of the output of the function. 

> (*) Or should I say, "one would" ?
> 
> P.S.  Why isn't there a strtoi() or strtou() ?  I know, of course, that
> there is atoi(), but that doesn't have the error checking capability that
> the strto* functions have.




-- 
Lew Pitcher
"In Skills We Trust"

[toc] | [prev] | [next] | [standalone]

#386273

On Thu, 20 Jun 2024 14:06:45 +0000, Kenny McCormack wrote:

[snip]

> P.S.  Why isn't there a strtoi() or strtou() ?  I know, of course, that
> there is atoi(), but that doesn't have the error checking capability that
> the strto* functions have.

I don't know, but I'd /guess/ that, because the strto*l() functions return
a value that can easily be range-checked and (possibly) truncated to fit in
an int, the ISO committee didn't see any reason add another set of specialized
functions.

-- 
Lew Pitcher
"In Skills We Trust"

[toc] | [prev] | [next] | [standalone]

#386297

On 2024-06-20, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> Interestingly, I note that strtoul() accepts strings that begin with a sign
> (+ or -).  This is odd, since you'd (*) think that a sign (particularly, a
> minus) would be a syntax error in parsing for an unsigned value.

   unsigned int x = -42; // implementation defined result: UINT_MAX - 41

These functions seem to be geared toward the C language (perhaps writing
compilers or tooling for C). Note that these functions recognize
a leading zero for octal when base is specified as zero, and also
recognize the 0x prefix when base is 0 or 16.

So it is unsurprising that the unsigned functions would accept
negative values and do the modulo reduction.

> Further, although the (Linux) man page is more than a bit murky on the
> subject, it seems that the result of parsing, say, "-1", with strtoul() is
> the largest unsigned value (usually, 2**N-1 or a lot of F's (in hex)).
> Whereas, I would expect it to be 1 (i.e., just take the absolute value).
>
> Comments?  I find this all very counterintuitive.
>
> (*) Or should I say, "one would" ?
>
> P.S.  Why isn't there a strtoi() or strtou() ?  I know, of course, that
> there is atoi(), but that doesn't have the error checking capability that
> the strto* functions have.

I suspect, because, at the time strtol was introduced, long was the
widest integer type.

When designing an integer parsing function, why would you not just
have one function, working with the widest type?

Unfortunately, though, strtoll later had to be added.

If strtol didn't exist today, making it necessary to invent it or
something like it, that function should use the intmax_t type.
Then there wouldn't be any need to add new variants going forward.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#386298

In article <20240620154213.917@kylheku.com>,
Kaz Kylheku  <643-408-1753@kylheku.com> wrote:
...
>If strtol didn't exist today, making it necessary to invent it or
>something like it, that function should use the intmax_t type.
>Then there wouldn't be any need to add new variants going forward.

There actually is.

STRTOIMAX(3)               Linux Programmer's Manual              STRTOIMAX(3)



NAME
       strtoimax, strtoumax - convert string to integer

SYNOPSIS
       #include <inttypes.h>

       intmax_t strtoimax(const char *nptr, char **endptr, int base);
       uintmax_t strtoumax(const char *nptr, char **endptr, int base);

DESCRIPTION
       These  functions  are  just  like strtol(3) and strtoul(3), except that
       they return a value of type intmax_t and uintmax_t, respectively.

-- 
Conservatives want smaller government for the same reason criminals want fewer cops.

[toc] | [prev] | [next] | [standalone]

#386316

In article <v51d1l$2fklr$1@news.xmission.com>,
Kenny McCormack <gazelle@shell.xmission.com> wrote:
>Interestingly, I note that strtoul() accepts strings that begin with a sign
>(+ or -).  This is odd, since you'd (*) think that a sign (particularly, a
>minus) would be a syntax error in parsing for an unsigned value.

There have been some useful responses on this thread, which is Good.  Of
course, there have also been the usual crappola-type responses, but one must
learn to take the good with the bad.

Anyway, I think the takeaway is that while it is what it is, an argument
can certainly be made that it would have been better for the unsigned
versions of these function to not accept signed input.  If I were designing
it, I would have had strtoul("-1") be a syntax error (not a C language
syntax error - but a meta-language syntax error) - or, if not that, then
have it return 1, not 2**N-1.  But that's just me.

I appreciate the responses indicating that it was probably done the way it
was for actually both of these reasons:
    1) Because it makes it more useful for C compiler writers - who were
	seen as the primary audience.
    2) Because it means that the two functions are literally the same code.
	Both calculate the same bit pattern - the difference is only in the
	caller's interpretation of the result.

>P.S.  Why isn't there a strtoi() or strtou() ?  I know, of course, that
>there is atoi(), but that doesn't have the error checking capability that
>the strto* functions have.

Yeah, now I get it.  You really only need strtoimax() and strtoumax().

A result of any smaller type can be obtained by calling one of these
functions and storing the result in an object of the smaller type.

-- 
The randomly chosen signature file that would have appeared here is more than 4
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
	http://user.xmission.com/~gazelle/Sigs/GodDelusion

[toc] | [prev] | [next] | [standalone]

#386318

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.

> A result of any smaller type can be obtained by calling one of these
> functions and storing the result in an object of the smaller type.
> 

Or check for range and handle out of range values as appropriate by
situation.

[toc] | [prev] | [next] | [standalone]

#386319

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.
> 
> > A result of any smaller type can be obtained by calling one of these
> > functions and storing the result in an object of the smaller type.
> >   
> 
> Or check for range and handle out of range values as appropriate by
> situation.
> 
> 

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.

[toc] | [prev] | [next] | [standalone]

#386321

Michael S <already5chosen@yahoo.com> writes:
>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.
>> 
>> > A result of any smaller type can be obtained by calling one of these
>> > functions and storing the result in an object of the smaller type.
>> >   
>> 
>> Or check for range and handle out of range values as appropriate by
>> situation.
>> 
>> 
>
>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.

SuS defines ERANGE as the errno returned if the converted value is out of range.

https://pubs.opengroup.org/onlinepubs/9699919799/functions/strtoull.html

[toc] | [prev] | [next] | [standalone]

#386322

scott@slp53.sl.home (Scott Lurndal) writes:
>Michael S <already5chosen@yahoo.com> writes:
>>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.
>>> 
>>> > A result of any smaller type can be obtained by calling one of these
>>> > functions and storing the result in an object of the smaller type.
>>> >   
>>> 
>>> Or check for range and handle out of range values as appropriate by
>>> situation.
>>> 
>>> 
>>
>>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.
>
>SuS defines ERANGE as the errno returned if the converted value is out of range.
>
>https://pubs.opengroup.org/onlinepubs/9699919799/functions/strtoull.html

It should be quite clear what is stored at endptr in all cases from the
POSIX description.

[toc] | [prev] | [next] | [standalone]

#386342

On Fri, 21 Jun 2024 16:54:33 GMT, Scott Lurndal wrote:

> It should be quite clear what is stored at endptr in all cases from the
> POSIX description.

You really need to be checking the C spec, just in case.

[toc] | [prev] | [next] | [standalone]

#386347

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Fri, 21 Jun 2024 16:54:33 GMT, Scott Lurndal wrote:
>
>> It should be quite clear what is stored at endptr in all cases from the
>> POSIX description.
>
>You really need to be checking the C spec, just in case.

No, I don't.  The posix document clearly states that the text
is from ISO C (and clearly marks any extensions).

You really need to control the need to reply to every post.

[toc] | [prev] | [next] | [standalone]

#386364

On Sat, 22 Jun 2024 15:16:24 GMT, Scott Lurndal wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>On Fri, 21 Jun 2024 16:54:33 GMT, Scott Lurndal wrote:
>>
>>> It should be quite clear what is stored at endptr in all cases from the
>>> POSIX description.
>>
>>You really need to be checking the C spec, just in case.
> 
> No, I don't.

It is the authoritative reference.

[toc] | [prev] | [next] | [standalone]

#386371

On 6/22/24 11:16, Scott Lurndal wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
...
>> You really need to be checking the C spec, just in case.
> 
> No, I don't.  The posix document clearly states that the text
> is from ISO C (and clearly marks any extensions).

It also clearly states:
"The functionality described on this reference page is aligned with the
ISO C standard. Any conflict between the requirements described here and
the ISO C standard is unintentional. This volume of POSIX.1-2017 defers
to the ISO C standard."

This tells you two important things: they believe that there's a small
but significant chance of their description being unintentionally in
conflict with the C standard. And, if that is the case, POSIX defers to C.
You're better off reading the original than the thing that is supposed
to be a faithful copy, but might not be.

[toc] | [prev] | [next] | [standalone]

#386324

Michael S <already5chosen@yahoo.com> writes:

> 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.
>> 
>> > A result of any smaller type can be obtained by calling one of these
>> > functions and storing the result in an object of the smaller type.
>> >   
>> 
>> Or check for range and handle out of range values as appropriate by
>> situation.
>
> 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.

It says what value should be returned.  That's something certain!

As for what gets put into *str_end that page could be clearer.  The
standard says that a pointer just past the last of the digits is stored,
provided the input has the right form (spaces, sign, prefix, digits).
The cppreference page says a pointer just past "the last numeric
character interpreted" which begs the question of what "interpreted"
means when the result is possibly out of range.  Maybe saying "scanned"
rather than interpreted would be better.  The end pointer always points
just past any syntactically valid characters, even when the result is
out of range.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#386376

On Fri, 21 Jun 2024 18:15:07 +0100
Ben Bacarisse <ben@bsb.me.uk> wrote:

> Michael S <already5chosen@yahoo.com> writes:
> 
> > 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.
> >>   
> >> > A result of any smaller type can be obtained by calling one of
> >> > these functions and storing the result in an object of the
> >> > smaller type. 
> >> 
> >> Or check for range and handle out of range values as appropriate by
> >> situation.  
> >
> > 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.  
> 
> It says what value should be returned.  That's something certain!
>

In case of strtol, yes. 
In case of strtoul it also says what value should be returned, but
plain reading of cppreference.com text (at least *my* plain reading)
does not match observed behaviour. The text on cppreference.com
resembles Standard text, but does not match it. 
Also, at least to me, Standard text itself appear very far from clear
and way too open to interpretations.
My own interpretation would be that for any negative input strtoul()
should return ULONG_MAX and set errno to ERANGE. None of the actual
implementation that I tested behaves in this manner.
It seems, the problem is of what is considered "range of representable
 values" for unsigned type is by itself open to interpretations.

IMHO, even if in some part of the standard  there exists text that
clearly states that "range of representable values for unsigned long =
[-ULONG_MAX:ULONG_MAX]" it is worth repeating that in the section that
defines strtol, because it is at all non-intuitive. 

[toc] | [prev] | [next] | [standalone]

#386382

Michael S <already5chosen@yahoo.com> writes:

> On Fri, 21 Jun 2024 18:15:07 +0100
> Ben Bacarisse <ben@bsb.me.uk> wrote:
>
>> Michael S <already5chosen@yahoo.com> writes:
>> 
>> > 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.
>> >>   
>> >> > A result of any smaller type can be obtained by calling one of
>> >> > these functions and storing the result in an object of the
>> >> > smaller type. 
>> >> 
>> >> Or check for range and handle out of range values as appropriate by
>> >> situation.  
>> >
>> > 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.  
>> 
>> It says what value should be returned.  That's something certain!
>>
>
> In case of strtol, yes. 
> In case of strtoul it also says what value should be returned, but
> plain reading of cppreference.com text (at least *my* plain reading)
> does not match observed behaviour. The text on cppreference.com
> resembles Standard text, but does not match it.

Ah.  What's the discrepancy you see?

> Also, at least to me, Standard text itself appear very far from clear
> and way too open to interpretations.
> My own interpretation would be that for any negative input strtoul()
> should return ULONG_MAX and set errno to ERANGE. None of the actual
> implementation that I tested behaves in this manner.

I don't get that from the text.  There is, after all, no "negative
input".  There is a "subject sequence" which, if it starts with a minus
sign, causes the "value resulting from the conversion is negated (in the
return type)" which seems clear enough.

> It seems, the problem is of what is considered "range of representable
>  values" for unsigned type is by itself open to interpretations.
>
> IMHO, even if in some part of the standard  there exists text that
> clearly states that "range of representable values for unsigned long =
> [-ULONG_MAX:ULONG_MAX]" it is worth repeating that in the section that
> defines strtol, because it is at all non-intuitive.

I don't get what you are saying here.  The range of values is [0:ULONG_MAX].

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#386385

On Sun, 23 Jun 2024 12:38:51 +0100
Ben Bacarisse <ben@bsb.me.uk> wrote:

> Michael S <already5chosen@yahoo.com> writes:
> 
> > On Fri, 21 Jun 2024 18:15:07 +0100
> > Ben Bacarisse <ben@bsb.me.uk> wrote:
> >  
> >> Michael S <already5chosen@yahoo.com> writes:
> >>   
> >> > 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.
> >> >>     
> >> >> > A result of any smaller type can be obtained by calling one of
> >> >> > these functions and storing the result in an object of the
> >> >> > smaller type.   
> >> >> 
> >> >> Or check for range and handle out of range values as
> >> >> appropriate by situation.    
> >> >
> >> > 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.    
> >> 
> >> It says what value should be returned.  That's something certain!
> >>  
> >
> > In case of strtol, yes. 
> > In case of strtoul it also says what value should be returned, but
> > plain reading of cppreference.com text (at least *my* plain reading)
> > does not match observed behaviour. The text on cppreference.com
> > resembles Standard text, but does not match it.  
> 
> Ah.  What's the discrepancy you see?
> 

IMHO, the Standard texts allows for more interpretations (and
misinterpretations) than cppreference.com text 


> > Also, at least to me, Standard text itself appear very far from
> > clear and way too open to interpretations.
> > My own interpretation would be that for any negative input strtoul()
> > should return ULONG_MAX and set errno to ERANGE. None of the actual
> > implementation that I tested behaves in this manner.  
> 
> I don't get that from the text.  There is, after all, no "negative
> input".  There is a "subject sequence" which, if it starts with a
> minus sign, causes the "value resulting from the conversion is
> negated (in the return type)" which seems clear enough.
>

I find it less than clear.
The most non-clear part is that for strtouxx() as long as "subject
sequence" is in range, it is first converted and then negated. However
when  "subject sequence" is out of range it is converted, then clipped
and then *not* negated.
I don't feel confused in the similar way by none-u variants of strtoxx()

> > It seems, the problem is of what is considered "range of
> > representable values" for unsigned type is by itself open to
> > interpretations.
> >
> > IMHO, even if in some part of the standard  there exists text that
> > clearly states that "range of representable values for unsigned
> > long = [-ULONG_MAX:ULONG_MAX]" it is worth repeating that in the
> > section that defines strtol, because it is at all non-intuitive.  
> 
> I don't get what you are saying here.  The range of values is
> [0:ULONG_MAX].
>

That as long as you see sign as something detached from the rest of the
number. I tend to see them as parts of the whole. May be, that's my
mistake.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web