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

Groups > comp.lang.c > #168596

Re: string to size_t

Show all headers | View raw

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 */

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

string to size_t Oğuz <oguzismailuysal@gmail.com> - 2022-12-19 14:15 +0300
  Re: string to size_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-19 09:59 -0800
    Re: string to size_t Oğuz <oguzismailuysal@gmail.com> - 2022-12-19 21:34 +0300
      Re: string to size_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-19 10:49 -0800
        Re: string to size_t Richard Damon <Richard@Damon-Family.org> - 2022-12-19 14:29 -0500
          Re: string to size_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-19 12:05 -0800
    Re: string to size_t scott@slp53.sl.home (Scott Lurndal) - 2022-12-19 18:40 +0000
      Re: string to size_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-19 12:07 -0800
        Re: string to size_t scott@slp53.sl.home (Scott Lurndal) - 2022-12-19 20:31 +0000
      Re: string to size_t Tony Oliver <guinness.tony@gmail.com> - 2022-12-19 16:33 -0800
    Re: string to size_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-19 11:20 -0800
  Re: string to size_t Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-19 22:16 +0000

csiph-web