X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs Date: Fri, 27 Apr 2001 12:13:46 +0200 (MET DST) From: Hans-Bernhard Broeker X-Sender: broeker AT acp3bf To: djgpp workers list Subject: Re: sbrk() storing the size of memory blocks In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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, 27 Apr 2001, Esa A E Peuha wrote: > On Thu, 26 Apr 2001, Hans-Bernhard Broeker wrote: > > > [Attached, you'll find another patch that adds lots of comments to crt0.S. > > I wrote those as I dug my way through all this assembly, I could see > > what's happening. May be useful for others who want to work on this, > > later...] > > Please don't send anything as attachments; with many email programs, > it appears to be nearly impossible to send even plain text attachments > unencoded, and many programs won't allow to include attachments with > the main body of text when replying. Yes, but OTOH, patch files are notorious for breaking badly if included in the text portion of an EMAIL. Over-long lines being wrapped, and such. Been there, been hit by it. As that patch was not meant for discussion purposes, and also a bit too large to be repairable easy after such breakage, I decided to play safe and attach rather than include it. > > Content-Type: TEXT/PLAIN; charset=US-ASCII; name="crt0.S.commenting.diff" > > Content-Transfer-Encoding: BASE64 > > Content-ID: > > I knew that some braindead M$ programs will happily encode us-ascii in > base64, but I didn't think that Pine would do so. Well, that may be a configuration issue on my end. OTOH, what's so bad about BASE64? Either you have a MIME-aware mailer, or you don't. If you do, BASE64 is no worse than QP or raw 8bit stuff. If you don't, QP can be just as unreadable as anything else. And no, DOS line endings were not the reason why PINE decided to encode it at all --- I dtou'ed the file before bringing it. > > --- nimrod.c Wed Apr 11 00:48:06 2001 > > +++ dpmiexcp.c Thu Apr 26 04:05:12 2001 > > @@ -248,6 +248,13 @@ [...] > You don't ifdef away enough of the code. :-) The line Agreed. That's what you get in (partly) experimental code. > BTW, do you intend to leave the DONT_STORE_BLOCKSIZES ifdefs in the > final code? I don't think that would be very useful. No. As mentioned, this is to serve as a discussion basis. I didn't want to delete the older code, yet, so I left myself an option to compile it with -DDONT_STORE_BLOCKSIZES in order to run cross-checks. Like: did all those comments and preprocessor tricks affect the code in any way? Compiled with -DDONT_STORE_BLOCKSIZES, the crt0.o file should be binary-identical to the 'official' one. > > +#if 0 > > addl $4, %edi /* FIXME: checks stored *base* ??? */ > > Do we really need the "#if 0"'d part here, or anywhere else in crt0.S? > These unused sections are available in CVS, if anyone should need them, > and crt0.S certainly wouldn't be too easy to read even without them. :-) That particular block I left in mainly because I simply didn't know for sure whether the problem I thought I found here actually exists. > > +#ifndef DONT_SAVE_BLOCKSIZES > > This (and the other one) should probably be DONT_STORE_BLOCKSIZES. Yep. -- Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.