 |
lua-l archive |
|
|
||
|
On 27/08/2021 20:00, nobody wrote:
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.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.
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