I wrote the function below for converting a string to size_t without
manually calculating its value digit by digit. It first converts the
string to intmax_t, and if the conversion fails due to a range error and
SIZE_MAX doesn't fit into an intmax_t, it tries again with uintmax_t. In
both cases, if the result is less than zero it fails. And on success it
populates *result with the result.

It works on my machine and a couple others I tried, but I'm not sure if
it's good C, or a good idea at all. What do you think about it?

int
strtosize(const char *nptr, char **endptr, int base, size_t *result) {
intmax_t s;
uintmax_t u;

errno = 0;
s = strtoimax(nptr, endptr, base);

if (errno == 0 && s >= 0 && s <= SIZE_MAX) {
*result = s;
return 1;
}

#if SIZE_MAX > INTMAX_MAX
if (errno == ERANGE && s == INTMAX_MAX) {
errno = 0;
u = strtoumax(nptr, endptr, base);

if (errno == 0 && u <= SIZE_MAX) {
*result = u;
return 1;
}
}
#endif

if (errno == 0)
errno = ERANGE;

return 0;
}

Oğuz <oguzismailuysal@gmail.com> writes:
> I wrote the function below for converting a string to size_t without
> manually calculating its value digit by digit. It first converts the
> string to intmax_t, and if the conversion fails due to a range error
> and SIZE_MAX doesn't fit into an intmax_t, it tries again with
> uintmax_t. In both cases, if the result is less than zero it
> fails. And on success it populates *result with the result.
>
> It works on my machine and a couple others I tried, but I'm not sure
> if it's good C, or a good idea at all. What do you think about it?
>
> int
> strtosize(const char *nptr, char **endptr, int base, size_t *result) {
> intmax_t s;
> uintmax_t u;
>
> errno = 0;
> s = strtoimax(nptr, endptr, base);
>
> if (errno == 0 && s >= 0 && s <= SIZE_MAX) {
> *result = s;
> return 1;
> }
>
> #if SIZE_MAX > INTMAX_MAX
> if (errno == ERANGE && s == INTMAX_MAX) {
> errno = 0;
> u = strtoumax(nptr, endptr, base);
>
> if (errno == 0 && u <= SIZE_MAX) {
> *result = u;
> return 1;
> }
> }
> #endif
>
> if (errno == 0)
> errno = ERANGE;
>
> return 0;
> }

What is the point of trying strotoimax before using strotoumax?
Just call strtotumax and convert the result to size_t.

The checks are probably unnecessary. As of the current C standard,
SIZE_MAX cannot be bigger than UINT_MAX. (C23 will allow for
the possibility that SIZE_MAX > UINT_MAX, but implementations are
unlikely to take advantage of that -- which means your checking
code will at best be difficult to test.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

On 12/19/22 8:59 PM, Keith Thompson wrote:
> What is the point of trying strotoimax before using strotoumax?
To see if the string represents a negative value and fail; can't do that
with strtoumax alone (or I don't know how to). For example, if I call
strtoumax("-40", NULL, 10), it returns 18446744073709551576 (UINTMAX_MAX
- 39) on my computer and leaves errno unchanged. I don't want that,
perhaps it wasn't clear in OP.

> The checks are probably unnecessary. As of the current C standard,
> SIZE_MAX cannot be bigger than UINT_MAX.
I didn't know this. Not sure how much adoption the current C standard
found but it's definitely a step forward for the language. Good.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>Oğuz <oguzismailuysal@gmail.com> writes:
>> I wrote the function below for converting a string to size_t without
>> manually calculating its value digit by digit. It first converts the
>> string to intmax_t, and if the conversion fails due to a range error
>> and SIZE_MAX doesn't fit into an intmax_t, it tries again with
>> uintmax_t. In both cases, if the result is less than zero it
>> fails. And on success it populates *result with the result.
>>
>> It works on my machine and a couple others I tried, but I'm not sure
>> if it's good C, or a good idea at all. What do you think about it?
>>
>> int
>> strtosize(const char *nptr, char **endptr, int base, size_t *result) {
>> intmax_t s;
>> uintmax_t u;
>>
>> errno = 0;
>> s = strtoimax(nptr, endptr, base);
>>
>> if (errno == 0 && s >= 0 && s <= SIZE_MAX) {
>> *result = s;
>> return 1;
>> }
>>
>> #if SIZE_MAX > INTMAX_MAX
>> if (errno == ERANGE && s == INTMAX_MAX) {
>> errno = 0;
>> u = strtoumax(nptr, endptr, base);
>>
>> if (errno == 0 && u <= SIZE_MAX) {
>> *result = u;
>> return 1;
>> }
>> }
>> #endif
>>
>> if (errno == 0)
>> errno = ERANGE;
>>
>> return 0;
>> }
>
>What is the point of trying strotoimax before using strotoumax?
>Just call strtotumax and convert the result to size_t.

What's wrong with strtoul?

Oğuz <oguzismailuysal@gmail.com> writes:
> On 12/19/22 8:59 PM, Keith Thompson wrote:
>> What is the point of trying strotoimax before using strotoumax?
> To see if the string represents a negative value and fail; can't do
> that with strtoumax alone (or I don't know how to). For example, if I
> call strtoumax("-40", NULL, 10), it returns 18446744073709551576
> (UINTMAX_MAX - 39) on my computer and leaves errno unchanged. I don't
> want that, perhaps it wasn't clear in OP.

Ah, I didn't think of that. (IMHO that's an unfortunate and
counterintuitive feature.)

You could check for a '-' character following zero or more whitespace
characters.

>> The checks are probably unnecessary. As of the current C standard,
>> SIZE_MAX cannot be bigger than UINT_MAX.
> I didn't know this. Not sure how much adoption the current C standard
> found but it's definitely a step forward for the language. Good.

uintmax_t and UINT_MAX were introduced in C99. If an implementation
supports [u]intmax_t at all, it will follow the requirement that
they are the widest supported [un]signed integer types. (I don't
know of any current implementations that don't support <stdint.h>.)

It turned out that increasing the width of [u]intmax_t as longer
integer types are introduced (typically 128 bits) caused problems
with ABIs. Adding a 128-bit integer type can be done without
breaking existing code, but changing the size of [u]intmax_t due to
that addition would break the interface been programs and library
codes, since there are standard library functions that take arguments
of those types. I personally would be much happier if we could
maintain the guarantee that [u]intmax_t are the widest [un]signed
integer types, but apparently there's no consistent way to do that.

C23 will allow an implementation, for example, to provide 64-bit long long
and 128-bit *extended integer types*, but (optionally) keep [u]intmax_t
at 64 bits.

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3054.pdf
7.22.1.5

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> O?uz <oguzismailuysal@gmail.com> writes:
>
>> I wrote the function below for converting a string to size_t without
>> manually calculating its value digit by digit. It first converts the
>> string to intmax_t, and if the conversion fails due to a range error
>> and SIZE_MAX doesn't fit into an intmax_t, it tries again with
>> uintmax_t. In both cases, if the result is less than zero it
>> fails. And on success it populates *result with the result.
>>
>> It works on my machine and a couple others I tried, but I'm not sure
>> if it's good C, or a good idea at all. What do you think about it?
>>
>> int
>> strtosize(const char *nptr, char **endptr, int base, size_t *result) {
>> intmax_t s;
>> uintmax_t u;
>>
>> errno = 0;
>> s = strtoimax(nptr, endptr, base);
>>
>> if (errno == 0 && s >= 0 && s <= SIZE_MAX) {
>> *result = s;
>> return 1;
>> }
>>
>> #if SIZE_MAX > INTMAX_MAX
>> if (errno == ERANGE && s == INTMAX_MAX) {
>> errno = 0;
>> u = strtoumax(nptr, endptr, base);
>>
>> if (errno == 0 && u <= SIZE_MAX) {
>> *result = u;
>> return 1;
>> }
>> }
>> #endif
>>
>> if (errno == 0)
>> errno = ERANGE;
>>
>> return 0;
>> }
>
> What is the point of trying strotoimax before using strotoumax?
> Just call strtotumax and convert the result to size_t.
>
> The checks are probably unnecessary. As of the current C standard,
> SIZE_MAX cannot be bigger than UINT_MAX. (C23 will allow for
> the possibility that SIZE_MAX > UINT_MAX, but implementations are
> unlikely to take advantage of that -- which means your checking
> code will at best be difficult to test.)

I think you mean UINTMAX_MAX rather than UINT_MAX.

On 12/19/22 1:49 PM, Keith Thompson wrote:
> Oğuz <oguzismailuysal@gmail.com> writes:
>> On 12/19/22 8:59 PM, Keith Thompson wrote:
>>> What is the point of trying strotoimax before using strotoumax?
>> To see if the string represents a negative value and fail; can't do
>> that with strtoumax alone (or I don't know how to). For example, if I
>> call strtoumax("-40", NULL, 10), it returns 18446744073709551576
>> (UINTMAX_MAX - 39) on my computer and leaves errno unchanged. I don't
>> want that, perhaps it wasn't clear in OP.
>
> Ah, I didn't think of that. (IMHO that's an unfortunate and
> counterintuitive feature.)
>
> You could check for a '-' character following zero or more whitespace
> characters.
>
>>> The checks are probably unnecessary. As of the current C standard,
>>> SIZE_MAX cannot be bigger than UINT_MAX.
>> I didn't know this. Not sure how much adoption the current C standard
>> found but it's definitely a step forward for the language. Good.
>
> uintmax_t and UINT_MAX were introduced in C99. If an implementation
> supports [u]intmax_t at all, it will follow the requirement that
> they are the widest supported [un]signed integer types. (I don't
> know of any current implementations that don't support <stdint.h>.)
>
> It turned out that increasing the width of [u]intmax_t as longer
> integer types are introduced (typically 128 bits) caused problems
> with ABIs. Adding a 128-bit integer type can be done without
> breaking existing code, but changing the size of [u]intmax_t due to
> that addition would break the interface been programs and library
> codes, since there are standard library functions that take arguments
> of those types. I personally would be much happier if we could
> maintain the guarantee that [u]intmax_t are the widest [un]signed
> integer types, but apparently there's no consistent way to do that.
>
> C23 will allow an implementation, for example, to provide 64-bit long long
> and 128-bit *extended integer types*, but (optionally) keep [u]intmax_t
> at 64 bits.
>
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3054.pdf
> 7.22.1.5
>

I think you mean UINTMAX_MAX, not UINT_MAX.

UINT_MAX is the limit for unsigned int, which on many 64 bits systems is
only 32 bits big, and will be smaller that SIZE_MAX.

Richard Damon <Richard@Damon-Family.org> writes:
> On 12/19/22 1:49 PM, Keith Thompson wrote:
>> Oğuz <oguzismailuysal@gmail.com> writes:
>>> On 12/19/22 8:59 PM, Keith Thompson wrote:
>>>> What is the point of trying strotoimax before using strotoumax?
>>> To see if the string represents a negative value and fail; can't do
>>> that with strtoumax alone (or I don't know how to). For example, if I
>>> call strtoumax("-40", NULL, 10), it returns 18446744073709551576
>>> (UINTMAX_MAX - 39) on my computer and leaves errno unchanged. I don't
>>> want that, perhaps it wasn't clear in OP.
>> Ah, I didn't think of that. (IMHO that's an unfortunate and
>> counterintuitive feature.)
>> You could check for a '-' character following zero or more
>> whitespace
>> characters.
>>
>>>> The checks are probably unnecessary. As of the current C standard,
>>>> SIZE_MAX cannot be bigger than UINT_MAX.
>>> I didn't know this. Not sure how much adoption the current C standard
>>> found but it's definitely a step forward for the language. Good.
>> uintmax_t and UINT_MAX were introduced in C99. If an implementation
>> supports [u]intmax_t at all, it will follow the requirement that
>> they are the widest supported [un]signed integer types. (I don't
>> know of any current implementations that don't support <stdint.h>.)
>> It turned out that increasing the width of [u]intmax_t as longer
>> integer types are introduced (typically 128 bits) caused problems
>> with ABIs. Adding a 128-bit integer type can be done without
>> breaking existing code, but changing the size of [u]intmax_t due to
>> that addition would break the interface been programs and library
>> codes, since there are standard library functions that take arguments
>> of those types. I personally would be much happier if we could
>> maintain the guarantee that [u]intmax_t are the widest [un]signed
>> integer types, but apparently there's no consistent way to do that.
>> C23 will allow an implementation, for example, to provide 64-bit
>> long long
>> and 128-bit *extended integer types*, but (optionally) keep [u]intmax_t
>> at 64 bits.
>> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3054.pdf
>> 7.22.1.5
>>
>
> I think you mean UINTMAX_MAX, not UINT_MAX.
>
> UINT_MAX is the limit for unsigned int, which on many 64 bits systems
> is only 32 bits big, and will be smaller that SIZE_MAX.

Yes, thank you for the correction.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

scott@slp53.sl.home (Scott Lurndal) writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>>What is the point of trying strotoimax before using strotoumax?
>>Just call strtotumax and convert the result to size_t.
>
> What's wrong with strtoul?

size_t can be wider than unsigned long. On modern Windows, for example,
unsigned long is 32 bits and size_t is 64 bits.

strtoull could also work (and as far as I know there are no current
implementations with uintmax_t wider than unsigned long long), but
strtoumax (which I misspelled above) makes the point more clearly.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>[...]
>>>What is the point of trying strotoimax before using strotoumax?
>>>Just call strtotumax and convert the result to size_t.
>>
>> What's wrong with strtoul?
>
>size_t can be wider than unsigned long. On modern Windows, for example,
>unsigned long is 32 bits and size_t is 64 bits.

Yes, I meant strtoull, which I use extensively.

Oğuz <oguzismailuysal@gmail.com> writes:

> I wrote the function below for converting a string to size_t without
> manually calculating its value digit by digit. It first converts the
> string to intmax_t, and if the conversion fails due to a range error
> and SIZE_MAX doesn't fit into an intmax_t, it tries again with
> uintmax_t. In both cases, if the result is less than zero it
> fails. And on success it populates *result with the result.
>
> It works on my machine and a couple others I tried, but I'm not sure
> if it's good C, or a good idea at all. What do you think about it?
>
> int
> strtosize(const char *nptr, char **endptr, int base, size_t *result) {

This name encroaches on the implementation's reserved name space. Also,
I would consider mirroring the return value and semantics of the other
standard strtoXXX functions. It's not a great interface to mimic, but
it is what readers are likely to expect.

> intmax_t s;
> uintmax_t u;
>
> errno = 0;
> s = strtoimax(nptr, endptr, base);
>
> if (errno == 0 && s >= 0 && s <= SIZE_MAX) {

This test may not do what you want. When the string contains junk (for
example "#") s will be 0 and errno will not have been changed.

If this matters to you, you need to pass your own non-zero "end" pointer
to strtoimax and check that:

char *ep;
intmax_t s = strtoimax(nptr, &ep, base);

if (errno == 0 && ep > nptr && s >= 0 && s <= SIZE_MAX) {
*result = u;
if (endptr) *endptr = ep;
return 1;
}

I'm late to the party so I'm only making these tangential remarks...

--
Ben.

On Monday, 19 December 2022 at 18:40:20 UTC, Scott Lurndal wrote:
> Keith Thompson <Keith.S.T...@gmail.com> writes:
> >Oğuz <oguzism...@gmail.com> writes:
> >> I wrote the function below for converting a string to size_t without
> >> manually calculating its value digit by digit. It first converts the
> >> string to intmax_t, and if the conversion fails due to a range error
> >> and SIZE_MAX doesn't fit into an intmax_t, it tries again with
> >> uintmax_t. In both cases, if the result is less than zero it
> >> fails. And on success it populates *result with the result.
> >>
> >> It works on my machine and a couple others I tried, but I'm not sure
> >> if it's good C, or a good idea at all. What do you think about it?
> >>
> >> int
> >> strtosize(const char *nptr, char **endptr, int base, size_t *result) {
> >> intmax_t s;
> >> uintmax_t u;
> >>
> >> errno = 0;
> >> s = strtoimax(nptr, endptr, base);
> >>
> >> if (errno == 0 && s >= 0 && s <= SIZE_MAX) {
> >> *result = s;
> >> return 1;
> >> }
> >>
> >> #if SIZE_MAX > INTMAX_MAX
> >> if (errno == ERANGE && s == INTMAX_MAX) {
> >> errno = 0;
> >> u = strtoumax(nptr, endptr, base);
> >>
> >> if (errno == 0 && u <= SIZE_MAX) {
> >> *result = u;
> >> return 1;
> >> }
> >> }
> >> #endif
> >>
> >> if (errno == 0)
> >> errno = ERANGE;
> >>
> >> return 0;
> >> }
> >
> >What is the point of trying strotoimax before using strotoumax?
> >Just call strtotumax and convert the result to size_t.
> What's wrong with strtoul?

Because sizeof( unsigned int ) might be less than sizeof ( uintmax_t ).