Re: printf functions without INT_MAX limitation

[Paul Eggert]

On 4/22/24 7:21 AM, Bruno Haible wrote:

> dealing with this problem means to define 2 functions instead of 1.

Since Gnulib is a source library, that complexity would be needed only 
for use inside object libraries - and these libraries already need to 
deal with off_t issues.


> > (Also, the problem will go away soon enough anyway, as 32-bit off_t
> > systems will likely die out by 2038 due to time_t issues of all things....)
>
> The problem will not entirely go away then. Only one function will be
> needed then, but it will be platform-dependent whether its return type
> is 'off_t' (standardized but 32-bit on Haiku) or 'off64_t' (always 64-bit
> but not standardized). [1]

You lost me there. Although I don't use Haiku, my impression is that 
off_t is 64 bits on Haiku. See, for example, 
<https://www.haiku-os.org/docs/api/SupportDefs_8h.html>.


> I think that the problem with regoff_t was that it already had legacy uses
> and therefore could not move to 64 bits. A problem that we won't have with
> 'zoff_t'.

True, but now that you mention off64_t it strikes me that zoff_t would 
basically be off64_t, and off64_t has had its own problems: its only use 
in apps is to deal with deficient libraries, and it is a pain in 
libraries (where its only use is to deal with deficient apps :-). I 
don't offhand see why zoff_t would do any better than off64_t has done, 
or why we would need to give a new name to this unloved type.