Re: How does string.format handle undefined behavior?

[Halalaluyafail3 <luigighiron@...>]

Yes, and I've found a few places where it accepts strings which cause
undefined behavior:
If precision is specified for conversion specifiers other than d, i,
o, u, x, X, a, A, e, E, f, F, g, G, and s.
If the '#' flag is specified for conversion specifiers other than o,
x, X, a, A, e, E, f, F, g, and G.
If the '0' flag is specified for conversion specifiers other than d,
i, o, x, X, a, A, e, E, f, F, g, and G.

And from testing them on my machine,
string.format("%02c",string.byte"1") results in "01", so it isn't
ignored.

On Thu, Aug 26, 2021 at 2:13 AM Flyer31 Test <flyer31@googlemail.com> wrote:
>
> 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?