Re: Fwd: snprintf?

[Marc Balmer <marc%msys.ch@localhost>]

Am 08.06.15 um 18:24 schrieb Andrew Cagney:
> FYI, want a bug report?

I think this is best handled on the Lua mailing list.

> 
> ---------- Forwarded message ----------
> From: Andrew Cagney <andrew.cagney%gmail.com@localhost>
> Date: 8 June 2015 at 12:22
> Subject: snprintf?
> To: lua-l%lists.lua.org@localhost
> 
> 
> Hi,
> 
> I just found a bug in an embedded port of lua which didn't support
> sprintf().  Specifically, the work-around:
> 
>     #define sprintf(s,fmt,...)  snprintf(s, sizeof(s), fmt, __VA_ARGS__)
> 
> is broken.  Consider correct code such as:
> 
>     char *b = ...; sprintf(b, "%d", 1);
> 
> found in lstrlib.c.
> 
> This, however, begs the question: should lua switch to snprintf()?
> 
> First, I don't think anyone will dispute that snprintf() is more
> robust than sprintf().  Rather, the problem is with portability.
> While snprintf() was formalized in c99, and almost all the C compilers
> have been supporting it since forever, there's been one holdout -
> Microsoft - they have had a somewhat recalcitrant attitude towards C
> standards compliance and, consequently, snprintf wasn't an option
> (Microsoft does have sprintf_s()  and _snprintf() but they have
> different semantics).
> http://en.cppreference.com/w/c/io/fprintf
> https://msdn.microsoft.com/en-us/library/2ts7cx93%28v=vs.120%29.aspx
> 
> However, recently we've been seeing something of a shift in
> Microsoft's attitude. Specifically Visual Studio 14/15 should support
> things like snprintf:
> http://blogs.msdn.com/b/vcblog/archive/2014/06/03/visual-studio-14-ctp.aspx
> 
> So I'd like to float the idea of adopting snprintf(), for instance:
> 
> - just assume snprintf (which would require a very recent Microsoft C compiler)
> 
> - define Lsnprintf() as snprintf() and use that, except on old windows
> systems which can wrap _snprintf() and deal with the different
> semantics
> 
> - define Lsnrintf() as snprintf() and use that, except on windows
> where it is re-defined as sprintf() (ignore the length parameter);
> this means things are no worse than what we have now
> 
> Andrew
>