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.
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.