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" In-Reply-To: from "Eli Zaretskii" at Jan 07, 2001 08:25:52 AM X-Mailer: ELM [version 2.5 PL0b1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 > > > 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 . -- au revoir, alain ---- Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!