Path: csiph.com!news.mixmin.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: string to size_t Date: Mon, 19 Dec 2022 12:05:30 -0800 Organization: None to speak of Lines: 52 Message-ID: <875ye7rwfp.fsf@nosuchdomain.example.com> References: <87r0wvs291.fsf@nosuchdomain.example.com> <87a63jrzxs.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: reader01.eternal-september.org; posting-host="8e7fdbea1bc660c36eba0e0212d247ec"; logging-data="463869"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/Q0m5MK/tT+DkJYHHDIB/A" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:VdOn01fjOmU62j/jYVqS6PJXUHs= sha1:ELg3nlo2L3VrUiE2Tic1fHWqZiI= Xref: csiph.com comp.lang.c:168599 Richard Damon writes: > On 12/19/22 1:49 PM, Keith Thompson wrote: >> Oğuz 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 .) >> 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 */