Mail Archives: djgpp-workers/2001/04/27/07:07:39
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: <Pine DOT LNX DOT 4 DOT 10 DOT 10104261430450 DOT 592 AT acp3bf>
>
> 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.
- Raw text -