delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2001/01/07/01:51:36

Message-Id: <200101070650.BAA31423@qnx.com>
Subject: Re: valloc and memalign draft
To: djgpp-workers AT delorie DOT com
Date: Sun, 7 Jan 2001 01:50:07 -0500 (EST)
From: "Alain Magloire" <alain AT qnx DOT com>
In-Reply-To: <Pine.SUN.3.91.1010107082143.21289C-100000@is> from "Eli Zaretskii" at Jan 07, 2001 08:25:52 AM
X-Mailer: ELM [version 2.5 PL0b1]
MIME-Version: 1.0
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

> 
> 
> On Fri, 5 Jan 2001, Mark E. wrote:
> 
> > +   /* Temporarily clear chunk-in-use bit so macros work correctly.  */
> > +   b1->size &= ~1;
> 
> Isn't this a bit dangerous?  Doesn't it leave the malloc chain in an 
> inconsistent state, for a small window of opportunities?  What if some 
> signal (i.e. exception) strikes between this line and where you restore 
> the bit, and the code run from the signal handler calls memalign?

I did not follow the thread but malloc and friends cannot be made
async-safe.  What you're describing is undefined behaviour or a programming
error i.e.  calling a none async-safe routine in a signal handler.

To put it another way if you call malloc()(or any routines that is not
specify async-safe) inside a signal handler you will have an undefined
behaviour, and at best a crash since malloc internals are corrupted.
Most of the time the program will appear to work correctly though <g>.

-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!

- Raw text -


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