Re: supporting strings > 2 GB

[Paul Eggert <eggert@cs.ucla.edu>]

On 10/12/19 7:38 AM, Bruno Haible wrote:

> 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.

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.

Gnulib may need something like printf_len_t, PRIdPRINTF etc., but I don't quite 
see why POSIX and/or the C standard would need them.

>>    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?

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?

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.

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.