Eric Blake <[EMAIL PROTECTED]> 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.
_______________________________________________
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
