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

Groups > comp.lang.c > #168599

Re: string to size_t

Show key headers only | View raw

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

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