Hi Paul,
> > Has this already been discussed in the Austin Group, or on the glibc list?
>
> Not as far as I know, though I haven't read all those mailing lists. It would
> be
> a good thing to do.
Thanks for the info. Then, on this topic, gnulib will be going ahead.
> I'm not sold on a new type 'printf_len_t' in the standard. Can't we get by
> with
> using ptrdiff_t instead? That would save standard C libraries the hassle of
> specifying a new length modifier and/or macros like PRIdPRINTF and
> SCNdPRINTF,
> for programs that want to print or read printf_len_t values.
The type printf_len_t is meant to allow the user to write code that works with
and without _PRINTF_LARGE.
1) It would be wrong to write
int ret = printf (...);
because without _PRINTF_LARGE this code will truncate the printf result.
2) It would be wrong to write
ptrdiff_t len;
if (len > PTRDIFF_MAX)
fail ();
because without _PRINTF_LARGE this does not do the necessary checking. And
ptrdiff_t len;
if (len > INT_MAX)
fail ();
is wrong for the case that _PRINTF_LARGE is defined.
The type and macro allow to write these as
printf_len_t ret = printf (...);
printf_len_t len;
if (len > PRINTF_LEN_MAX)
fail ();
There is no need to reserve a new length modifier and/or macros like PRIdPRINTF
and SCNdPRINTF, because the type and macro are only a convenience.
> >> 3) Introduce %ln as a printf_len_t alternative to %n.
>
> Would %ln work only for the new *l functions, or would it also work for the
> already-standard printf functions?
The existing printf functions are left unchanged: Since the entire result
may not be longer than INT_MAX bytes, it makes no sense to add provisions
for returning an index > INT_MAX or using a format directive with width
or precision > INT_MAX.
> How about the '*' field width? There needs to be some way to say that the
> field
> width is of type ptrdiff_t, not int. Would '**' stand for ptrdiff_t field
> widths?
Good point, yes: there ought to be a way to specify a field width or
precision as a ptrdiff_t. I think I'll prefer the syntax 'l*' to '**',
for consistency with %ln.
> Perhaps it would be simpler if the new *l functions use ptrdiff_t everywhere
> that the old functions use 'int' for sizes and widths. Then we wouldn't have
> to
> worry about '**' vs '*', or about '%ln' versus '%n'. The Gnulib layer could
> resolve whether the functions are about int or ptrdiff_t.
But then the valid format strings for the *l functions would not be
a superset of the valid format strings for the existing *printf functions.
One of the goals is that programmers can use the new facility just be
importing the respective gnulib modules and doing
#define _PRINTF_LARGE 1
without reviewing every format string.
> I assume functions like snprintfl would take ptrdiff_t arguments instead of
> size_t arguments for buffer sizes.
>
> Basically, replace size_t and int with ptrdiff_t everywhere we can.
Yes, this is the plan; thanks for the reminder about size_t.
Regarding the naming: I'm now tending towards 'lprintf' and 'flprintf',
to make it look like 'wprintf' and 'fwprintf'.
Bruno
