Howard Chu wrote: > [email protected] wrote: >> Jeffrey Walton wrote: >>> On Fri, Jun 7, 2019 at 10:08 AM Howard Chu <[email protected]> wrote: >>>> >>>> Jeffrey Walton wrote: >>>>> On Fri, Jun 7, 2019 at 9:59 AM Howard Chu <[email protected]> wrote: >>>>>> >>>>>> [email protected] wrote: >>>>>>> On Fri, Jun 7, 2019 at 9:32 AM Howard Chu <[email protected]> wrote: >>>>>>>> >>>>>>>> [email protected] wrote: >>>>>>>> ... >>>>>>>>> I encourage OpenLDAP to fix the undefined behavior. OpenLDAP is an >>>>>>>>> important project, and the undefined behavior is causing too many >>>>>>>>> tangential problems. >>>>>>>> >>>>>>>> Undefined behavior is not a bug, nor is it prohibited by the C spec. >>>>>>>> It is a necessary >>>>>>>> part of the language for its intended use as a system programming >>>>>>>> language, writing >>>>>>>> machine-specific programs. Anyone who says it is prohibited by the >>>>>>>> spec is wrong. >>>>>>> >>>>>>> I don't believe this is correct. >>>>>>> >>>>>>> Maybe you are thinking of implementation defined behavior? >>>>>> >>>>>> That would apply to how a particular compiler implementation treats some >>>>>> piece of code. >>>>>> Whether a CPU supports unaligned access is machine-defined. Since our >>>>>> code is already >>>>>> properly ifdef'd for the machines which do or don't support it, the fact >>>>>> that this is >>>>>> "non-portable" is not an issue. >>>>> >>>>> The undefined behavior is causing OpenLDAP to fail testing. >>>>> >>>>> Worse, it is causing test failures in programs and libraries which use >>>>> OpenLDAP. The OpenLDAP bugs have cross-pollinated into other programs >>>>> and libraries. It is not simply contained or limited to OpenLDAP. >>>>> >>>>> That's a big problem for testing a QA folks. >>>> >>>> Then the tests are broken, because these are not bugs. >>> >>> They are absolutely OpenLDAP bugs. The unaligned accesses are >>> Undefined Behavior. >> >> Simply because the C standard doesn't specify what the behavior is doesn't >> make it a bug. >> It would be unreasonable to expect the standards body to exhaustively list >> all of the >> possible behaviors on all of the possible hardware architectures that the >> language is >> implemented for. Leaving it undefined in the spec only means they chose not >> to specify >> a behavior. That means the actual behavior depends on the underlying >> machine. On the >> x86 family the behavior is well defined. > > Also note: Behaviors are left undefined when they are non-portable. But being > non-portable > isn't illegal in C. The entire purpose of conditional compilation is to > support non-portable > code. > Worth reading https://www.yodaiken.com/2018/12/31/undefined-behavior-and-the-purpose-of-c/
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
