*printf string functions without INT_MAX limitations

As discussed in the thread starting at , I'm adding *zs*printf modules, that are like the existing variants without 'z', except that - they support returning results of length > INT_MAX, - thus the length type is changed to 'p

*printf string functions without INT_MAX limitations in C locale

Here come the c-*zs*printf modules, which are like the existing c-*s*printf modules, except that - they support returning results of length > INT_MAX, - thus the length type is changed to 'ptrdiff_t' from 'int', - an attempt to return a result > PTRDIFF_MAX produces an error ENOMEM (consi

*printf obstack functions without INT_MAX limitations

This series of patches introduces an 'obstack-zprintf' module, that fixes the INT_MAX limitation (and also the unpredictable errno value in case of failure) of the 'obstack-printf' module. I originally planned this set of module dependencies: obstack-printf -> obstack-zprintf obstack-zpr

stdlib: Relax definition of EXIT_FAILURE.

I was looking at the changes in the POSIX 2024 pdf. Historically EXIT_FAILURE has been allowed to be any non-zero value. Gnulib made sure that the value was 1 because on Tandem/NSK it is defined to -1. This leads to issues since the exit status interpreted by 'xargs' is 255 which causes an early ex

Re: stdlib: Relax definition of EXIT_FAILURE.

Hi Collin, > Can we relax this definition to allow for any POSIX 2024 compatible > value? (1-125) We should *not* do that. Our unit tests not only serve to check POSIX or GNU behaviour of constants, header files, and functions. They also serve to check assumptions that are so widely used, that t

Re: stdlib: Relax definition of EXIT_FAILURE.

Hi Bruno, Bruno Haible wrote: > In this case, if EXIT_FAILURE were 2 or 3 instead of 1 on some > platforms, the *documented* exit codes of the 'diff' or 'grep' > commands or other utilities would not hold any more. > > If we ever encounter a platform where EXIT_FAILURE was like this, > we want to