Date: Sat, 21 Jun 2003 12:33:52 +0300
From: "Eli Zaretskii" <eliz AT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: djgpp-workers AT delorie DOT com
Message-Id: <9743-Sat21Jun2003123351+0300-eliz@elta.co.il>
X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9
In-reply-to: <3EF3E113.1C8C9C2B@yahoo.com> (message from CBFalconer on Sat, 21
	Jun 2003 00:37:39 -0400)
Subject: Re: 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>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Date: Sat, 21 Jun 2003 00:37:39 -0400
> From: CBFalconer <cbfalconer AT yahoo DOT com>
> 
> I don't know the details of this, so I may be talking nonsense,
> but it reminds me of what I found in looking at the present
> memalign.c.  That uses a herd of macros which do not appear in the
> source, nor in malloc.h.

If you mean BEFORE, ENDSZ, DATA, etc., then they are defined in
libc/malloc.h.  Since stdlib.h and libc/malloc.h are the only headers
mentioned in memalign.c, I don't think looking up those macros is such
a formidable taks.  But if searching two headers is too much, you
could always use Grep:

    fgrep -e BEFORE -e ENDSZ -e DATA %DJDIR%/include/.../*.h

or, better yet, install the GNU ID-utils package, run `mkid' on both
the `src' and `include' directories, and then type commands like

    lid ENDSZ

to get much faster (and more accurate) results than with Grep.

> So, while there may be prototypes for the source routines buried
> in this manner, there should not be references IMO.

I'm not sure I understand: are you saying that it is fundamentally
wrong to have macros defined in header files that are used by library
routines?

The reason those macros were put on a header is because several
librray modules use them" malloc.c, malldbg.c, and memalign.c.  I
don't see any flaws in that decision.