From:	huott AT pinebush DOT com (Ed Huott)
Subject:	Re: dos2unix program (was: Bash, history file, and Tcl)
23 Jan 1997 08:40:59 -0800 :
Approved:	cygnus DOT gnu-win32 AT cygnus DOT com
Distribution:	cygnus
Message-ID:	<199701230426.XAA11896.cygnus.gnu-win32@sol.pinebush.com>
Original-To:	gnu-win32 AT cygnus DOT com
In-reply-to:	Your message of "Wed, 22 Jan 1997 13:05:08 PST."
	<32E68104 DOT 6E1B AT netcom DOT com>
Original-Sender:	owner-gnu-win32 AT cygnus DOT com

In message <32E68104 DOT 6E1B AT netcom DOT com>, Jim Balter writes:
>Ed Huott wrote:
>
>> Here's a DOS to Unix file filter that works a little better by leaving
>> lone <cr>'s embedded in the file unmolested.
>
>Except that it leaves CR's in lines that are exactly 998 chars long,
>because fgets splits the line between the CR and the LF.
>And if you think that doesn't matter, you haven't been around
>text filters long enough.
>
Ah, thank you, Jim!  I kinda figured if I tossed that code up, I might
get a decent bug report back on it - especially after reading a lot of
your posts to this list. :^) I wish I could get code reviews as good
that on a more regular basis!

Actually, I had a funny feeling there was probably some "gotcha" in
the splitting of long lines.  But, then again, a 996 character line
limit (to guarantee safety) for a text filter I threw together at the
spur of the moment is something I can live with 99.8% of the time.
(Good to know it's there, though, 'cause I agree, it does matter!)

>> It should also run
>> faster due to the buffering through the use of fgets() and fprintf().
>
>getchar and putchar buffer quite nicely.  In most implementations
>fgets and fprintf("%s") are just getchar and putchar loops.
>I wouldn't make any speed claims without actually running the code;
>the difference is likely to be in the noise.
>
Right again.  Any speed difference would have nothing to do with
buffering.  I should have said I was assuming that the (usually) once
per line call to strstr() and test would be faster than the once per
character test.  My past empirical experience with DOS based systems
suggests to me that this would be true.  But, as you say, no real
claims can be made without testing.

>> It's written using Microsoft compiler semantics, not gcc, sorry.
>
>ANSI C is ANSI C.
>
Oh man, can't I get anything right?!  Yes, "semantics" is the wrong
word.  Should've said "Microsoft library calls" (e.g. _setmode()).

Thanks for helping to keep me (and the rest of us) honest!

<ED>
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -