Re: How does string.format handle undefined behavior?

[Philippe Verdy <verdyp@...>]

The Lua implementation should not pass "%#c" from Lua call to string.format() directly to a C *printf() function.

It should parse all "%*" placeholders itself, and should not even need to use any *printf() function and not depend on it. It will reject "%#c" as invalid in Lua format strings (providing its own fallback or error). In such case, there will be no UB at all.

Le dim. 5 sept. 2021 à 11:51, Lorenzo Donati <lorenzodonatibz@tiscali.it> a écrit :

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?
>>
>