bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: supporting strings > 2 GB


From: Paul Eggert
Subject: Re: supporting strings > 2 GB
Date: Sat, 12 Oct 2019 20:01:54 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]