[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: size_t option parsing question
From: |
Eric Blake |
Subject: |
Re: size_t option parsing question |
Date: |
Thu, 28 Sep 2006 17:02:11 +0000 (UTC) |
User-agent: |
Loom/3.14 (http://gmane.org/) |
Paul Eggert <eggert <at> CS.UCLA.EDU> writes:
> > POSIX also states that size_t is only guaranteed to be 16 bits.
>
> Really? Where?
http://www.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html#tag_13_48
"The following macros specify the minimum and maximum limits of integer types
corresponding to types defined in other standard headers.... Its implementation-
defined value shall be equal to or greater in magnitude (absolute value) than
the corresponding value given below, with the same sign.
...
Limit of size_t:
{SIZE_MAX}
65535 "
> Anyway, this is not an issue for coreutils, since the
> GNU coding standards say:
>
> However, don't make any effort to cater to the possibility that an
> <at> code{int} will be less than 32 bits. We don't support 16-bit machines
> in GNU.
>
> and a reasonable corollary is that you can assume that size_t is at
> least 32 bits.
Thanks. That's what I was hoping.
> > Finally, it looks like suffix parsing is a purely upward compatible
extension
> > to POSIX in many cases.
>
> Yes, that's true too.
>
Then with that, I think I will add suffix parsing to 'm4 -l' and 'm4 -L';
xstrtoul is pretty nice! I'll leave it to you to decide how much of coreutils
is worth extending, but in deference to Jim trying to release, it is worth
holding off this task until after 6.3 is out.
--
Eric Blake