Re: How does string.format handle undefined behavior?

[Lorenzo Donati <lorenzodonatibz@...>]

On 04/09/2021 21:41, Philippe Verdy wrote:
> string.format() in Lua does not suffer of any buffer overflow in C/C++
> nul-terminated strings with most "*printf"-like functions, and does not
> expose any "%p" and pointer- or memory related fields.
> It just mimics *some* of its behavior but processes each field with its own
> rule and uses safe (and immutable) Lua strings only, with known length and
> bound checks of indices everywhere for every operation on strings.
> There's no "dragon" left behind.

I didn't examine Lua source, but if a format string that causes UB is 
passed to C, then *there are dragons left*.

If I got it right from this thread, specifying something as "%#c" will 
end up with C printf (o fprintf) receiving a "%#c" format string, which 
is clearly (well, if you know how to dig in the standard) marked as UB 
in the standard, as Roberto pointed out and as I provided the reference 
to earlier in the thread.

If this is the case, you definitely could have dragons.

> Le sam. 4 sept. 2021 à 15:54, Egor Skriptunoff <egor.skriptunoff@gmail.com>
> a écrit :
>
> > On Fri, Aug 27, 2021 at 10:31 PM Lorenzo Donati wrote:
> >
> > > UB is just dragons waiting to wreak havoc
> > > on your machine.
> >
> > How dangerous are string.format() dragons?
> > Should string.format() be inaccessible to untrusted Lua code?
> >
> > Or, maybe Lua protects safely from the main threat (buffer overflow),
> > and all other dragons are small and acceptable?