Re: How does string.format handle undefined behavior?

[Flyer31 Test <flyer31@...>]

Are you really sure what you are writing here?

Result "01" is perfectly correct for this format string as I see it.

The dangerous thing about printf in c is, that you easily can crash
your software with wrong usage of printf.

Try e. g. in c
char ac[100];
int ai[1000];
for( i= 0; i< 1000; i++) a[i]= -1;
sprintf( ac, "%s", af)

... then something VERY weird will happen...  In Lua similar things
should NOT happen (I hope :) ).... .


On Thu, Aug 26, 2021 at 5:40 PM Halalaluyafail3 <luigighiron@gmail.com> wrote:
>
> 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?