Re: How does string.format handle undefined behavior?

[Flyer31 Test <flyer31@...>]

But what is your problem with this result "1" or better "01" for

str= "1"
string.format("%02c", str)

?

Isn't this exactly what would be expected, or am I standing on the line somehow?


On Fri, Aug 27, 2021 at 9:31 PM Lorenzo Donati
<lorenzodonatibz@tiscali.it> wrote:
>
> On 27/08/2021 20:00, nobody wrote:
> > On 27/08/2021 16.28, Roberto Ierusalimschy wrote:
> >> Thanks for the report. Do you have any real case where this is causing
> >> problems? (e.g., a platform with a weird behavior for these uses, a tool
> >> that complains about Lua source code.)
> >
> > For reference, the standard *explicitly* says "behavior is undefined"
> > and not just unspecified, but I tried both gcc and clang in gnu99 and
> > C11 modes with -fsanitize=undefined and neither of them produced any
> > warnings when formatting "%02c" or "%#02.4c" and other nonsense.  (That
> > said, as far as I understand UBSAN isn't supposed to catch _everything_,
> > just a subset of all undefined stuff.)
> >
> >>> And from testing them on my machine,
> >>> string.format("%02c",string.byte"1") results in "01", so it isn't
> >>> ignored.
> >
> > On my machine, "%02c" produces " 1" so while it seems to be not truly
> > undefined "in practice", at least the behavior can't be relied on.
> >
> Just for the record, as always in C, undefined behavior is to be avoided
> at all costs, since the *actual behavior* of the specific platform can
> change unexpectedly even with the same executable on the same machine.
>
> What appears to be consistent and sane behavior (e.g. no segfault) after
> compilation could even change if the OS runs low on memory (for
> example). The only way to tell if the behavior is sane is to check the
> disassembled compiler output and see if the machine code behaves sanely
> *in every possible case*, which is of course ridiculous.
>
> Unless an implementation chooses to define an otherwise UB (and
> specifies that in the docs), UB is just dragons waiting to wreak havoc
> on your machine.
>
> Such bugs can lay dormant for years, until someone changes a compiler
> setting or switches to a new compiler or, even worse, changes the
> runtime environment of the same old executable, then Murphy will grant
> you hours and hours of fun! <grin>
>
>
> > Cheers!
> > -- nobody
> >
>
>
> Cheers!
>
> -- Lorenzo