Paul Eggert wrote:
> > 2) Introduce variants of *printf functions, that return a 'ptrdiff_t'
> > instead
> > of 'int'. (For results longer than PTRDIFF_MAX, they will fail with
> > error
> > ENOMEM, not EOVERFLOW.) This gives rise to several new gnulib modules.
>
> This sounds like a good idea. However, shouldn't output-oriented
> functions like 'printf' return off_t rather than ptrdiff_t?
Hmm. I see how you get there: Because calling
fprintf (fp, "%s%s%s%s%s%s%s%s%s%s", s, s, s, s, s, s, s, s, s, s)
might return up to nearly 10 * PTRDIFF_MAX.
But direct use of off_t has two problems:
- off_t is not defined by ISO C; thus it's an odd return type for things
like zsprintf.
- off_t changes depending on whether gl_LARGEFILE is in use or not;
thus it's a bad idea to use it in the API of any shared library or
(more generally) any independently-built component.
I would prefer to solve this dilemma by defining a new type, say 'zoff_t',
that is required to be
- at least as wide as off_t, and
- at least as wide as ptrditt_t.
Similar to how regoff_t is specified in POSIX [1], except that in practice,
regoff_t does not satisfy these constraints [2] (because regoff_t is only
32-bits wide
- in 32-bit mode on glibc, Solaris, Android, even with -D_FILE_OFFSET_BITS=64,
- in 32-bit mode on AIX, even with -D_LARGE_FILES=1,
- on Haiku.)
In the foreseeable future, zoff_t would be equivalent to int64_t. But
it could even be defined as '__int128' with gcc, if need arises.
> Also, I'm tempted to use "#define printf zprintf" and leave most of the
> source code alone. Perhaps there should be a Gnulib option for that.
I see... a pervasive macro, a bit like gl_LARGEFILE. I think we can worry
about that when the function-based modules are present.
Bruno
[1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/regex.h.html
[2]
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=tests/test-regex.c;h=175cdf4fe63422fcb1c7de214185caf1b0b4bd24;hb=HEAD#l475
