On Sat, Jun 8, 2019 at 3:47 AM Howard Chu hyc@symas.com wrote:
Jeffrey Walton wrote:
On Fri, Jun 7, 2019 at 2:37 PM Howard Chu hyc@symas.com wrote:
Jeffrey Walton wrote:
On Fri, Jun 7, 2019 at 10:08 AM Howard Chu hyc@symas.com wrote:
Jeffrey Walton wrote:
On Fri, Jun 7, 2019 at 9:59 AM Howard Chu hyc@symas.com wrote: > > noloader@gmail.com wrote: >> On Fri, Jun 7, 2019 at 9:32 AM Howard Chu hyc@symas.com wrote: >>> >>> noloader@gmail.com 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.
The C standard does specify the behavior. It falls clearly in Undefined Behavior.
The fact a behavior is undefined does not make it illegal.
A program with undefined behavior is, by definition, and illegal program.
And Appendix J.2, Undefined Behavior, says:
Conversion between two pointer types produces a result that is incorrectly aligned (6.3.2.3).You are violating the C standard in macros like COPY_PGNO. Effectively you are casting a uint8_t array to an uint16_t*. You cannot do that because uint16_t* increases the alignment requirements.
All internal fields of LMDB are (at least) 2-byte aligned, so these copies always meet alignment requirements.
No, they are not. Some of them are 1-byte aligned. UBsan tells you that.
Others require 4-byte alignment. UBsan tells you that, too.
Jeff
-
noloader＠gmail.com