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 '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! - For help on using this list, send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".