RE: sl_malloc is unportable (ITS#2551)

[hyc@symas.com]

> -----Original Message-----
> From: owner-openldap-bugs@OpenLDAP.org
> [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of
h.b.furuseth@usit.uio.no

> Full_Name: Hallvard B Furuseth
> Version: HEAD
> OS:
> URL:
> Submission from: (NULL) (129.240.186.42)
> Submitted by: hallvard

> This test in sl_realloc() and sl_free() yields undefined behaviour:
> 	/* Not our memory? */
> 	if ( !sh || ptr < sh->h_base || ptr >= sh->h_end ) {
> Also this in sl_release() and sl_context():
> 	if ( sh && ptr >= sh->h_base && ptr <= sh->h_end ) {
> The operators < <= > >= are only defined between two pointers into the
> same block of memory.  An example of how they can fail with pointers
> to different blocks of memory is if a pointer consists of a segment
> number and an offset into the segment, and an object cannot cross a
> segment boundary.  Then these operators need only compare the offsets,
> they can ignore the segment numbers.
>
> So slapd needs an `#ifdef USE_SL_MALLOC' to be defined for
> architectures
> or architecture/compiler combinations where sl_malloc works.
> Unfortunately I cannot think of a reliable configure test for this,
> the best I can think of is to collect information about where
> it works,
> and hard-code #if tests for that into the code.

I consider these tests optional in the first place. The code generally
doesn't mix TL memory with regular memory; the only time confusion occurs is
when a SLAPI plugin frees and reallocates something because the SLAPI code
has no knowledge of the TL memory. These tests are there only to accomodate
this latter situation. Since using sl_malloc is such a big win in general,
I'd rather we come up with a solution to the SLAPI problem on these esoteric
architectures, rather than just turn it off. (And until someone actually
needs to port to such an architecture, I'd rather ignore the problem.)
>
> Another non-portability is this code:
> 	int pad = 2*sizeof(int)-1;
> 	/* round up to doubleword boundary */
> 	size += pad;
> 	size &= ~pad;
> Some types may need stricter alignment than that.  A better
> way to find
> the required alignment is:
> 	#include <stddef.h>
> 	struct align_test {
> 		char c;
> 		union {
> 			long l;
> 			double d;
> 			void *vp;
> 			struct align_test *sp;
> 			int (*ifp)(int);
> 			void (*vfp)(void);
> 			/* ...other types used by the program... */
> 		} align;
> 	};
> 	#define ALIGN_MAX offsetof(struct align_test, align)

That's fine.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support