Message-ID: <3EE65932.C87DFF4B@yahoo.com>
Date: Tue, 10 Jun 2003 18:18:26 -0400
From: CBFalconer <cbfalconer AT yahoo DOT com>
Organization: Ched Research
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: DJGPP 2.04 alpha 2 later in the month?
References: <3EE4EB66 DOT DF7891D2 AT phekda DOT freeserve DOT co DOT uk> <3EE4F833 DOT 2B67D8C0 AT yahoo DOT com> <3EE582BB DOT DEC034FA AT yahoo DOT com> <3EE62BC7 DOT F14013F8 AT phekda DOT freeserve DOT co DOT uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Richard Dawe wrote:
> CBFalconer wrote:
> > CBFalconer wrote:
> > > Richard Dawe wrote:
> > > >
> > > > I was thinking we could do DJGPP 2.04 alpha 2 later this month.
> > > > Reasons:
> > > >
> > > > (1) uclock now works on Windows 2000 and later.
> > > > (2) gcc 3.2.3 has a bugfix for the struct passing issue.
> > > > (3) A few other minor fixes that I can think of.
> > > >
> > > > The binary compatibility issue (2) is probably the main reason
> > > > for releasing alpha 2. If people don't think that's important,
> > > > then maybe we should wait a while longer.
> > >
> > > I guess I better rise up off my rump and do those compile time
> > > options for nmalloc :-)
> >
> > Done.  The result is at:
> >
> >    <http://cbfalconer.home.att.net/download/nmalloc.zip>
> >
> > and compiles with no warnings with -W -Wall -O2.  It no longer
> > needs -DNDEBUG, instead the inverse is controlled with
> > -DNEWMALLDBG, so omission gives the production result.
> 
> Thanks. I'll try to take a look at it at the weekend.
> 
> > I could not use gcc.opt, since that collection makes the command lines
> > too long, and I could not find a way to include a reference to it in
> > the compile command.
> 
> Try:
> 
> gcc @c:/some/path/gcc.opt <other-options>

That produces a herd of problems, mostly due to the -nostdinc.  I
see no point to this. After deleting that what remains is the
following:

`-m486' is deprecated. Use `-march=i486' or `-mcpu=i486' instead.
cc1.exe: warnings being treated as errors
cc1.exe: warning: -malign-loops is obsolete, use -falign-loops
cc1.exe: warning: -malign-jumps is obsolete, use -falign-jumps
cc1.exe: warning: -malign-functions is obsolete, use
-falign-functions
nmalloc.c: In function `combinelo':
nmalloc.c:430: warning: passing arg 1 of `badcallabort' discards
qualifiers from pointer target type
nmalloc.c: In function `combinehi':
nmalloc.c:454: warning: passing arg 1 of `badcallabort' discards
qualifiers from pointer target type
nmalloc.c: In function `rmvfromfree':
nmalloc.c:511: warning: passing arg 1 of `badcallabort' discards
qualifiers from pointer target type
nmalloc.c: In function `split':
nmalloc.c:568: warning: passing arg 1 of `badcallabort' discards
qualifiers from pointer target type
nmalloc.c:584: warning: passing arg 1 of `badcallabort' discards
qualifiers from pointer target type
nmalloc.c: In function `free':
nmalloc.c:802: warning: passing arg 1 of `badcallabort' discards
qualifiers from pointer target type
nmalloc.c: In function `realloc':
nmalloc.c:856: warning: passing arg 1 of `badcallabort' discards
qualifiers from pointer target type
nmalloc.c:968: warning: traditional C lacks a separate namespace
for labels, identifier `exit' conflicts

I can easily change the name for label exit, but I have no idea
(see below) how to defeat the arg 1, which is being passed a
constant string, e.g. badcallabort("fromwhere",9,ptr);  This in
turn uses such things as signal and write so it can function
during initialization.  It catches some fatal fouled arena
conditions.  Its code follows:

static void badcallabort(char *msg, int lgh, memblockp m)
{
#if DEBUGM || DEBUGF || DEBUGR
   DBGEOLN;
#endif
   write(STDERR, msg, lgh);
   write(STDERR, ": memory fouled\n", 16);
#if DEBUGM || DEBUGF || DEBUGR
   SHOWBLK(m, "");
   dumpfree();
#else
   (void)m;  /* anti unused warning */
#endif
   raise(SIGABRT);
} /* badcallabort */

and all the DEBUGx conditions are false.  The use of SIGABRT was
discussed here a long time ago, as was emission of messages during
initialization.  Maybe the first parameter should be "const char*"
?  This will never get called during initialization unless
somebody makes a huge mistake, and then it may be worthwhile.

-- 
Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT worldnet DOT att DOT net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!