On Sun, Mar 08, 2020 at 11:04:40PM +0100, Bruno Haible wrote:
> Hi Adrian,
Hi Bruno,
>...
> it would
> make sense for gnulib to have "nearly POSIX" compliant variants of these
> functions; this would remove the need for the gnulib *printf* code in
> many cases.
this sounds like a good idea.
Loo
On Sun, Mar 08, 2020 at 06:59:54PM +0100, Bruno Haible wrote:
> Hi Adrian,
Hi Bruno,
> gnulib works as designed. gnulib is designed to override system function so as
> to make them POSIX compliant. POSIX [1] specifies that support for %n in the
> *printf functions is mandatory. As you have shown
rpl_fprintf is wrongly being used on Ubuntu 18.04 due to:
$ cat test.c
/* gl_PRINTF_DIRECTIVE_N */
#include
#include
#include
static char fmtstring[10];
static char buf[100];
int main ()
{
int count = -1;
/* Copy the format string. Some systems (glibc with _FORTIFY_SOURCE=2)
support %
On Thu, Aug 17, 2017 at 08:40:28PM +0200, Bruno Haible wrote:
>...
> Now about your test case: It is not valid C to try to compile just an
> expression.
>...
I was about to say that this was directly copied from intprops.h
And when double-checking that, I finally realized that this is
what is in
On Thu, Aug 17, 2017 at 07:02:47PM +0200, Bruno Haible wrote:
> Hi Adrian,
>
> Could you please give the complete output of "gcc --version"?
>
> Given that [1] references an URL that contains the string
> 'gcc7-20170126' whereas gcc 7 was released on 2017-05-02 [2],
> it could be that the report
> Package: src:rush
> Version: 1.8+dfsg-1
>...
> In file included from inttostr.h:25:0,
> from anytostr.c:31,
> from imaxtostr.c:5:
> intprops.h:236:34: error: expected ')' before '(' token
> __builtin_add_overflow (a, b, (__typeof__ ((a) + (b)) *) 0)
>
