Re: supporting strings > 2 GB

[Bruno Haible <bruno@clisp.org>]

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