Re: How does string.format handle undefined behavior?

[Flyer31 Test <flyer31@...>]

Have you looked at the souce code? If you search the c files in your
lua folder for "format" you should find the c file easily. I did not
look into every detail so far, but as I see it "generally" the
string.format function is programmed quite fail-safe... e. g. it
"cuts" the format string in pieces by itself and does % arguments one
after each other ... so "dangerous c printf" does NOT receive the
format string, but is used only for short and clear format substrings
like "%...s", "%...f", "%...d" with arguments "hand-checked" by Lua
... . So for me this looks nice... .


On Thu, Aug 26, 2021 at 1:39 AM Halalaluyafail3 <luigighiron@gmail.com> wrote:
>
> There was a discussion some time ago about undefined behavior with the
> next function, which made me think about other potential places for
> undefined behavior.
>
> The string.format function definition states: "Returns a formatted
> version of its variable number of arguments following the description
> given in its first argument, which must be a string. The format string
> follows the same rules as the ISO C function sprintf. The only
> differences are that the conversion specifiers and modifiers *, h, L,
> l, and n are not supported and that there is an extra specifier, q."
> Considering it is stated that it follows the same rules as the ISO C
> function sprintf, presumably it has the same undefined behavior that
> the ISO C function sprintf does, using the ISO C definition of
> undefined behavior. I don't think this is intended, but from looking
> at the source for string.format it does seem to accept format strings
> which invoke undefined behavior and calls sprintf using them as the
> format string.
>
> What is the intended result of passing a format string to
> string.format which invokes undefined behavior according to the ISO C
> definition of sprintf?