I wrote:
> This is more hairy than you might think. Because of the GCC attribute syntax.
>
> stdio.in.h does
>
> /* Don't break __attribute__((format(printf,M,N))). */
> #define printf __printf__
>
> because there are not many symbols that can be used in place of 'printf'.
>
> Do you have
Bruno Haible writes:
> This is more hairy than you might think. Because of the GCC attribute syntax.
>
> stdio.in.h does
>
> /* Don't break __attribute__((format(printf,M,N))). */
> #define printf __printf__
>
> because there are not many symbols that can be used in place of 'printf'.
Ah, i
Hi Collin,
> Is the correct way to use them as Paul mentioned previously?
> Like this [1]:
>
>
> #undef printf
> #define printf zprintf
This is more hairy than you might think. Because of the GCC attribute syntax.
stdio.in.h does
/* Don't break __attribute__((format(printf,M,N))). */
Collin Funk wrote:
> I'm not sure how portable the __asm__ redirects are.
Only supported by GCC and clang, I would say.
> could include a header with extern inline functions?
And that extern inline function would be called 'printf', right?
That would work in programs, but would be hairy in libra
And likewise for the c-*z*printf modules:
2024-06-25 Bruno Haible
c-vazsprintf-gnu: Add tests.
* tests/test-vazsprintf-gnu.h: New file, extracted from
tests/test-vazsprintf-gnu.c.
* tests/test-vazsprintf-gnu.c: Include test-vazsprintf-gnu.h.
(test_funct
Hi Bruno,
Bruno Haible writes:
> This set of patches adds -gnu variants for the *z*printf modules
> that we have so far, along with small unit tests.
Looks good (+ previous patches). One question though since I noticed
these functions are defined in stdio.h.
Is the correct way to use them as P
This set of patches adds -gnu variants for the *z*printf modules
that we have so far, along with small unit tests.
2024-06-25 Bruno Haible
obstack-zprintf-gnu: Add tests.
* tests/test-obstack-zprintf-gnu.c: New file, based on
tests/test-vazsprintf-gnu.c.
* modu