On Sat, Jul 29, 2023 at 8:29 AM Alejandro Colomar <alx@xxxxxxxxxx> wrote: > I lied. I should have said that it writes what is safe to write, and > then uses a somewhat "safer" version of undefined behavior (compared > to other string copying functions). The standard differentiates > "bounded UB", which doesn't perform out-of-bounds stores, from > "critical UB", which performs them. In usual jargon, UB is UB, and > there's no mild form of UB; however, the standard prescribes a bounded > form of UB. However, I'm not sure compilers --and specifically GCC-- > follow such a prescription of bounded UB, so it's better to consider > all UB to be critical UB, just to fall on the safe side. Do you have a source for this? As far as I am aware, the standards have always followed the "UB is UB" philosophy, which is why standards-oriented people keep trying to reiterate it. I've never heard of anything like "bounded UB" vs. "critical UB". C17 draft N2176 provides no such distinction in its definition: > 3.4.3 > undefined behavior > > behavior, upon use of a nonportable or erroneous program construct or of > erroneous data, for which this International Standard imposes no > requirements > > Note 1 to entry: Possible undefined behavior ranges from ignoring the > situation completely with unpredictable results, to behaving during > translation or program execution in a documented manner characteristic of > the environment (with or without the issuance of a diagnostic message), to > terminating a translation or execution (with the issuance of a diagnostic > message). > > EXAMPLE An example of undefined behavior is the behavior on integer > overflow. (In the C23 draft, another note has been added and the example has been modified, but the definition remains the same. In [intro.abstract], C++ is even more thorough, clarifying that UB at any point trashes the entire program execution, past and future.) POSIX is a bit more vague, warning that UB can result in arbitrary nonexistent or invalid values or behaviors: > undefined > > Describes the nature of a value or behavior not defined by POSIX.1-2017 > which results from use of an invalid program construct or invalid data > input. > > The value or behavior may vary among implementations that conform to > POSIX.1-2017. An application should not rely on the existence or validity > of the value or behavior. An application that relies on any particular > value or behavior cannot be assured to be portable across conforming > implementations. The closest thing I can find to "bounded" vs. "critical UB" is an old proposal by Thomas Plum in 2007-8 (documents N1278, N1331, and N1344) to define "critical undefined behavior". Is this proposal what you're referring to? It never made it anywhere near being added to the standard, as far as I can tell. Thank you, Matthew House
