Re: inconsistency in libintl_vsnprintf interface under Windows

[Bruno Haible]

Ben Pfaff wrote:
> When libintl is used under Windows, it replaces the native
> vsnprintf by a wrapper function, libintl_vsnprintf, to add
> support for $ in format specifiers.  When $ is not present in a
> format string, it falls back to the system vsnprintf.

Yes, it does this, because the system vsnprintf on Windows does not
support argument reordering, which is essential for translations in
some languages.

> However, under Windows, the system vsnprintf has argument, return
> value, and output semantics that differ from C99 semantics and,
> furthermore, from libintl_vasnprintf semantics.  The result is
> that libintl_vsnprintf will have C99 semantics when a format
> string contains $ (whether in a format specifier or not) and
> Windows semantics otherwise.  It may be debatable which set of
> semantics should be used

libintl_vsnprintf can use either the C99 or the Windows convention.
  - It can use the C99 convention because the GNU gettext manual,
    section "C Format Strings", mentions that there are replacement
    functions. And obviously the replacement functions can be standards
    compliant.
  - It can use the Windows convention because said doc does not say
    that _all_ features missing from the system's vsnprintf are added
    by the replacement function.

> but it seems certain that they should
> not be mixed randomly in this way.

Why not? As a programmer, it's an unwise idea to rely on the Windows
behaviour if the C99 standard says the opposite, and it's equally unwise
to rely on the C99 behaviour when you know that the Windows library
routines do it differently.

> I propose to fix it by always using the C99 semantics.

This is outside of the scope of libintl. libintl cares about the needs of
internationalization. The right place for such C99 or POSIX compliance fixes
is gnulib.

Bruno