delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2003/04/22/10:59:24

Date: Tue, 22 Apr 2003 17:56:06 +0200
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: <6503-Tue22Apr2003175605+0300-eliz@elta.co.il>
X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9
In-reply-to: <3EA53744.383B819C@yahoo.com> (message from CBFalconer on Tue, 22
Apr 2003 08:36:20 -0400)
Subject: Re: nmalloc revisited
References: <10304211942 DOT AA12379 AT clio DOT rice DOT edu> <3277-Tue22Apr2003105749+0300-eliz AT elta DOT co DOT il> <3EA53744 DOT 383B819C 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

> Date: Tue, 22 Apr 2003 08:36:20 -0400
> From: CBFalconer <cbfalconer AT yahoo DOT com>
> 
> In general, though, DJGPP is not Unix and can never be Unix.

We don't claim DJGPP is Unix, but we do try to be compatible, at least
as far as the API goes, and, when feasible, behave the same.

> In particular it doesn't have the memory protections that Unix does

Really?  What protection do you lack, specifically?  The only one I
know about is that the stack is not protected from overflows.  But I
found the same problem on SGI Irix as well, so it's not that DJGPP is
the only member of that club.

> A unix hook would trap if set to
> point to non-executable memory.  Imagine someone writing:
> 
>    gets((char *)&somehookptr);
> 
> or something equally bizaare.

If you try the same in DJGPP, you will most probably see a crash.

> BTW, the hook documentation says they are specific to DJGPP.  My
> proposal is not compliant with POSIX in the extra argument and
> macros to malloc_debug only, all other variations are in things
> marked as !posix and possibly "available on many unices".

We need to maintain compatibility to "many unices" even if that is
not in Posix.  But DJGPP-specific stuff can be changed.

> Maybe, for compatibility, the malloc_debug should be as previously
> documented, and I should add a function "FILE
> *setmalloc_debug_dump(FILE *fp)".

That'd be fine with me.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019