RE: commit: ldap/servers/slapd/back-ldbm attr.c

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Howard Chu writes:
>> From: Hallvard B Furuseth [mailto:h.b.furuseth@usit.uio.no]
> 
>> (a) Both new and original code gives the wrong result or signals an
>>     overflow for pointers to memory locations that are more than
>>     INT_MAX bytes or so apart.
>>
>> (b) Pointer comparison is only defined between pointers to the same
>>     array.  The result of the original code is undefined if desc and
>>     a->ai_desc point to the results of different malloc operations.
> 
> Problem (b) is true per the ANSI spec, but is not significant
> here. (...) The AttributeDescriptions being compared in back-bdb and
> back-ldbm are all created by the same malloc function

Irrelevant.  To be safe, it must come from the same malloc _call_.

> (...) It all comes from one heap, which is a single array.

Not necessarily.  On machines where malloc just uses sbrk() or something
to grab more memory, yes.  On machines where it uses a system call which
gives a new unconnected memory block, no.  Then comparison can crash.

Another way for comparison to crash is if the implementation uses
array bounds checks.

It seldom pays to try to out-guess the Standard.  The Standard doesn't
leave these hacks undefined just to be difficult, but because there are
existing implementations where they don't work.

That said, I don't have a problem with ignoring (b) until we actually
meet an implementation where (b) is a problem, just as long as we are
aware that it is an unsafe hack.  It might be an idea to move such code
to two files nonstd.h and nonstd.c, though.  And write a test program to
be run by configure or make which tries to detect if some of this code
doesn't work.

> Also for this reason, problem (a) is not relevant; the range of
> addresses being compared will never be so far apart.

Yes, it can.  Two malloc calls might return pointers to memory that is
very far apart, e.g. if the memory for the two calls were not grabbed by
the same call to whatever system call malloc uses to grab memory.  On
some machines there isn't even a meaningful definition of how far
'apart' memory is when it comes from from two different such calls,
because they don't use a model of continuous linear memory.  For
example, I've seen an example where a pointer was treated a sequence of
bytes, where the first bytes were indexes to a page register or
something in the machine.  Well, actually it was a lot stranger than
that, but I don't remember the details.

-- 
Hallvard