Re: size_t option parsing question

[Eric Blake]

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