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.
