Re: size_t option parsing question

[Paul Eggert]

Eric Blake <address@hidden> writes:

> POSIX also states that size_t is only guaranteed to be 16 bits.

Really?  Where?  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
  @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.

> Second, POSIX does not always guarantee that size_t fits in a long.

Again, the GNU coding standards come to your rescue:

  Similarly, don't make any effort to cater to the possibility that
  @code{long} will be smaller than predefined types like @code{size_t}.


> Next, there is still a big FIXME in xstrtol debating whether the API
> should be changed slightly and all callers updated, so that clients
> of xstrtol can easily get suffix parsing by passing in NULL instead
> of a long list of letters.  The longer we wait to resolve this API,
> the more projects will be impacted by a change.

Yes, that's true.

> And would size_opt be useful in gnulib, alongside xstrtol, rather than 
> buried in uniq.c?

Might be, yes.

> Finally, it looks like suffix parsing is a purely upward compatible extension 
> to POSIX in many cases.

Yes, that's true too.