Subject: Re: How to translate this stdio code to netbsd?
To: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
From: John F. Woods <jfw@FunHouse.com>
List: current-users
Date: 03/12/1996 20:11:27
> As far as I can recall, all the code I've seen which tries to get under
> the hood of stdio could be satisifed with a single call: a call which,
> when applied to a readable FILE pointer, returns the number of bytes
> currently buffered
The MH 6.8.3 code attempts to avoid buffer copies by some way-too-clever code
that does reads by extracting pointers to data in the stdio buffers. I managed
to port an older MH to UNOS, which had a completely from-scratch stdio
implementation that was functionally compatible with, but not identical to,
the traditional UNIX implementation; MH was plagued with substitutions of
NUL bytes for newlines at unpredictable places. Curiously enough, though,
when I started using NetBSD 0.8 and ported MH 6.8.2 to it, the NUL
substitutions almost BUT NOT QUITE vanished, despite having what should have
been exactly the same stdio implementation as the author of that horror...
6.8.3 appears not to suffer from this; either they fixed the specific bug,
or NetBSD 1.0 mutated in a way that made it compatible with this mess.
My original fix for UNOS was to scrap that nonsense and do it the right way;
despite the dire comments in the code about the horrible performance of the
copies, I failed entirely to perceive any slowness: perhaps the original
author should have upgraded from his VAX 11/730 instead of spending the time
writing that code. (Alas, I lost the diffs at some point and didn't have
the time to regenerate them when I upgraded to 6.8.2.)
> At least until this last thing, when I saw the poster who started this
> off send something indicating that the code was just too lazy to buffer
> input to provide context, instead peeking into the stdio buffer for the
> purpose. That particular bit of code I have little pity for.
It's curious indeed to want to provide context for an error but not being
willing to actually HAVE the context available for the messages. (Does the
user manual for this thing warn not to make errors near block boundaries
in the source code?) How much effort is worthwhile to make something "work"
that simply isn't right...?