Re: printf functions without INT_MAX limitation

Paul Eggert wrote: > Although I don't use Haiku, my impression is that > off_t is 64 bits on Haiku. See, for example, > . Indeed, you're right. Tested on 32-bit Haiku installations from 2017 and 2022. Bruno

Re: printf functions without INT_MAX limitation

Paul Eggert wrote: > 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

Re: printf functions without INT_MAX limitation

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

Re: printf functions without INT_MAX limitation

On Montag, 22. April 2024 09:27:47 CEST Paul Eggert wrote: > >- off_t changes depending on whether gl_LARGEFILE is in use or not; > > thus it's a bad idea to use it in the API of any shared library or > > (more generally) any independently-built component. > > That ship sailed long

Re: printf functions without INT_MAX limitation

On 2024-04-21 14:36, Bruno Haible wrote: But direct use of off_t has two problems: - off_t is not defined by ISO C; thus it's an odd return type for things like zsprintf. I was thinking that zsprintf should return ptrdiff_t and zprintf would return off_t. off_t is defined by POSIX ,

Re: printf functions without INT_MAX limitation

Paul Eggert wrote: > > 2) Introduce variants of *printf functions, that return a 'ptrdiff_t' > > instead > > of 'int'. (For results longer than PTRDIFF_MAX, they will fail with > > error > > ENOMEM, not EOVERFLOW.) This gives rise to several new gnulib modules. > > This sounds like a

Re: printf functions without INT_MAX limitation

On 2024-04-21 09:27, Bruno Haible wrote: 2) Introduce variants of *printf functions, that return a 'ptrdiff_t' instead of 'int'. (For results longer than PTRDIFF_MAX, they will fail with error ENOMEM, not EOVERFLOW.) This gives rise to several new gnulib modules. This sounds like a

printf functions without INT_MAX limitation

Hi Paul, In several places, we have hit the possibility that the *printf functions fails with EOVERFLOW (due to a result larger than INT_MAX characters): - While trying to avoid analyzer warnings from xasprintf(). [1] - IIRC, you also wrote that in coreutils you would prefer to 'printf'