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: Sun, 13 Oct 2019 13:12:20 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

On 10/13/19 12:50 PM, Bruno Haible wrote:
The C or POSIX standards deal only with layer 1). However, layer 2) is
essential for programs, to make the use of the new APIs easy.

Right, and I see the need for two layers. I'm still not seeing, though, the exact division between the two layers in this instance.

With large file support, POSIX took an old function lseek that used 'long', and said that lseek should use the new type 'off_t' instead. Old implementations could simply add 'typedef long off_t;' and conform. There is no OFF_MAX or PRIdOFF because off_t is not part of ISO C. Programs define _FILE_OFFSET_BITS to choose which off_t they get.

A difference here is that we'd be proposing a change to ISO C (it could be done only in POSIX, but it's really a change to the C standard). In ISO C there's a tradition that types like 'ptrdiff_t' all have macros like PTRDIFF_MAX, PRIdPTR, etc., and so presumably this tradition should apply to printf_len_t.

If we take this approach, there should be no need for %ln vs %n or %**d vs %*d; programs that define _PRINTF_LARGE will get a wide printf_len_t and things will "just work" if programs consistently use printf_len_t instead of int (and use the related macros too).



reply via email to

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