bug-gettext
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gettext] libintl.h redirection of stdio printf functions


From: Eli Zaretskii
Subject: Re: [bug-gettext] libintl.h redirection of stdio printf functions
Date: Sat, 12 May 2018 14:43:30 +0300

> From: Tim Rühsen <address@hidden>
> Date: Sat, 12 May 2018 13:26:00 +0200
> 
> >   #if !(defined sprintf && defined _GL_STDIO_H) /* don't override gnulib */
> >   #undef sprintf
> >   #define sprintf libintl_sprintf
> >   extern int sprintf (char *, const char *, ...);
> >   #endif
> >
> > This interferes with MinGW-supplied replacements for sprintf etc.
> > Every program that includes gettext.h "gains" these redirections, and
> > there doesn't seem to be a way of avoiding that, except when building
> > Gnulib itself, unless I missed something.  The only "solution" I could
> > see is to #undef all those definitions after including gettext.h, in
> > source files that don't use the _ macro, but that sounds fragile, and
> > doesn't work when both _() and C99 printf format specifiers are used.
> >
> > What is the recommended solution for this issue?
> We could simply skip those tests on certain platforms, e.g. on _WIN32.
> 
> These tests are basically to test our own printf implementation against
> glibc's printf.
> So it simply doesn't make sense to test it against the Windows
> implementation.
> 
> Since the MinGW cross build works on Linux (see our Gitlab CIs,
> .gitlab-ci.yml and contrib/mingw), it would be great if you can wrap the
> code with #ifndef _WIN32 until it works for you. Just send us the
> patches / diffs.

That sounds too radical to me, because the MinGW implementation does
support all those specifiers, and once I resolved the libintl.h
redirections, all the tests passed.

It would make sense to me to make those tests maintainer-only tests,
which would run only on the platform where the developers works.  But
singling out Windows while leaving all other platforms run the test in
full makes much less sense.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]