Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3EF5FF16.6FE61E25@phekda.freeserve.co.uk>
Date: Sun, 22 Jun 2003 20:10:14 +0100
From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: memalign hooks (was: LIBM patch for GCC 3.3 - math changes)
References: <200306201334 DOT h5KDYMWU012441 AT speedy DOT ludd DOT luth DOT se> <000e01c337aa$7b238800$0100a8c0 AT acp42g> <3EF3E113 DOT 1C8C9C2B AT yahoo DOT com> <9743-Sat21Jun2003123351+0300-eliz AT elta DOT co DOT il> <3EF449C0 DOT 8C8A0C61 AT yahoo DOT com> <3791-Sun22Jun2003063027+0300-eliz AT elta DOT co DOT il> <3EF53044 DOT CDEA5BA1 AT yahoo DOT com> <3405-Sun22Jun2003201552+0300-eliz AT elta DOT co DOT il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

Eli Zaretskii wrote:
> 
> > Date: Sun, 22 Jun 2003 00:27:48 -0400
> > From: CBFalconer <cbfalconer AT yahoo DOT com>
> > >
> > > I think we don't need any more hooks beyond those in malloc and
> > > friends.
> >
> > It may be necessary to put them in if only for consistency.  The
> > end result of memalign will be the equivalent of a malloc, so if
> > we want to catch arena errors etc. as early as possible the hooks
> > will need to be there.
> 
> I have no objections to add such hooks, but it is not necessary to do
> that for nmalloc to go into the next alpha.  So I'd suggest to finish
> memalign interface first, which will allow Richard to proceed with
> preparing the next pretest.  Then, if you feel like adding the hooks,
> please do.

In passing: GNU libc 2.1.3 has a memory hook. This is quite an old version of
glibc. The current stable version is 2.3.2, IIRC.

> > I think memalign should also fail for alignment parameter < ALIGN
> > value (i.e. 8 at present).
> 
> IMHO, it should behave in a way that is compatible with other
> implementations.  Could someone please look on their nearest Unix or
> GNU/Linux box and see what does memalign there do for such small
> alignment parameters?  (Sorry, no time to do this myself.)

Try the test program below. memalign only works with boundaries that are a
power of 2 in GNU libc 2.1.3. I don't know about later versions.

SUSv3 (and new POSIX) has a function called posix_memalign. This has the
power-of-2 restriction too. posix_memalign could be implemented as a simple
wrapper for memalign. So I don't think you'd need to do anything nmalloc-wise
to support posix_memalign, CBFalconer.

If successful, it should not display anything. Here's what it does on my
RedHat 6.2 box with glibc 2.1.3:

iolanthe:~/src/tmp/memalign =] ./t-memalign && echo OK
OK

---Start t-memalign.c---
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <malloc.h>

static const size_t MAX_TEST = 64;

int
main (void)
{
  char *p;
  size_t i;

  /* boundary must be a power of 2 for memalign with GNU libc 2.1.3. */
  for (i = 2; i <= MAX_TEST; i *= 2)
    {
      p = memalign(i, i);
      if (!p)
	printf("memalign(%d, %d) failed\n", i, i);
      else
	free(p);
    }

  return(EXIT_SUCCESS);
}
---End t-memalign.c---

Bye, Rich =]

-- 
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]