Re: Fwd: snprintf?

[Andrew Cagney <andrew.cagney%gmail.com@localhost>]

Just to clarify on one point: the bug is in NetBSD's port, not the
original Lua sources.
Lua doesn't need to do anything (and, so far, doesn't appear to to be
that interested either).  It might be prudent to apply some sort of
fix to the 7.x branch.

Andrew


On 8 June 2015 at 16:19, Marc Balmer <marc%msys.ch@localhost> wrote:
> 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
>>
>