Re: (ITS#8988) Undefined Behavior in slapadd

[openldap-technical@kolttonen.fi]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---1463811718-326687762-1580674674=:196994
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8BIT



On Sun, 2 Feb 2020, openldap-technical@kolttonen.fi wrote:

> I realize this thread is very old, but Jeff and the C compiler folks are 
> right. All C programs that invoke undefined behavior are illegal C 
> programs and should be fixed.
> 
> Posix threads are well-defined by Posix standards, so calling them 
> "undefined behaviour" is not a valid argument.

To make it clear that UB in C programs is horrible, let me provide a real 
world example of UB: Cyrus IMAPD had an unnoticed dormant strcpy() related 
UB bug for several years. You see, the manual page of strcpy() says that 
the src and dst strings must not overlap, or else the C program invokes 
UB.

For many years, Cyrus operated correctly even though the src and dst 
strings *did* overlap in one part of their database code. UB of course 
allows this behaviour too. The reason was because GNU libc folks had 
written their strcpy() implementation in such a way that breaking the 
contract of having non-overlapping strings did not cause any problems.

Then, years later, GNU libc folks deciced to optimize (or otherwise 
change) their strcpy() implementation. Now the new implementation punished 
all UB invokers, and we saw our Cyrus mailbox database slowly but surely 
getting corrupted.

It is indeed shocking to hear that LMDB implementation invokes UB. GCC and 
Clang could change their behaviour tomorrow, and LMDB could get corrupted, 
crash or whatever. And certainly the blame would be on LMDB code, not the 
compiler writers.

Best Regards,
Jokke Hämäläinen
---1463811718-326687762-1580674674=:196994--