Re: (ITS#8988) Undefined Behavior in slapadd

[noloader@gmail.com]

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.

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

You seem to have a misunderstanding of the standard and unaligned
accesses. You also seem to be conflating two different concepts.

First, unaligned accesses, are undefined behavior. They are forbidden
by the standard in 6.3.2.3 Pointers:

    7. A pointer to an object type may be converted to
    a pointer to a different object type. If the resulting pointer
    is not correctly aligned for the referenced type, the
    behavior is undefined.

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.

Tools like UBsan are telling you when you violate the rules. They
specifically flagged COPY_PGNO as incurring undefined behavior. (Tools
like UBsan will miss some UB, but that's a different error and not
applicable to this discussion).

You insistence on claiming the code is correct is befuddling. You are
effectively saying the world is wrong, including the C standard, the
compiler writers, other projects, the QA personnel testing the
software and users like me.

There's nothing special about me being wrong. I've had to acknowledged
that often. However, I would take pause in claiming the C standard is
wrong or the compiler writers, like GCC and LLVM devs, are wrong.
That's pretty bold.

Second, conflating concepts, is the difference between the C standard
and processor capabilities. The C code has undefined behavior, and it
does not matter what the processor is capable of.

And it does not matter if the compiler decides to generate code that
performs unaligned accesses. The compiler is free to do what it wants,
even when it frustrates the user or makes the user envious. However,
you cannot wrote code that uses unaligned objects even though the
compiler may generate equivalent code.

Jeff