Mail Archives: djgpp-workers/1998/09/18/05:45:29
On Thu, 17 Sep 1998, Charles Marslett wrote:
> Porting Unix text processing code would have been
> a tiny bit harder, but then the "... For Dummies" books would not have as
> hard a time telling you why reading in a file and writing it back out
> can give you an "identical" file that has a different length (!?!).
Some DJGPP ports of GNU programs actually try very hard not to produce
this side effect. But it usually takes some code to do that
inobtrusively. Check out e.g. in v2gnu/txt122s.zip (the GNU Textutils),
especially `cat' and other programs that can work as filters. Something
like "cat foo > bar" doesn't change the EOL format of `foo'.
> How do you force a file to be binary/text in emacs, Solaris or PC?
In 19.34, use `M-x find-file-binary' and `M-x find-file-text' (I think
they are only available in the DOS/Windows versions). In Emacs 20, use
`M-x find-file-literally', which is available on all platforms (since
Emacs 20 converts DOS-style CR/LF pairs even on Unix).
> > DJGPP's versions of `fseek' and `ftell' don't have these
> > side-effects.
>
> They are hard to avoid if you have two types of files. I guess you could
> eliminate fseek()ing and ftell()ing a text file. djgpp doesn't do that,
> does it?
No, it just is careful to return correct values even for text files.
> What numeric value does ftell() return?
The true byte offset into the file, including any CR characters that are
stripped when the application consumes the file.
> How does fseek() work on a text file?
It seeks on the original file contents, before the CRs are stripped.
> Can you do any arithmetic at all on the value returned from ftell()?
Yes, you can, see above.
> Can you ftell() after a binary fopen(), and then fseek() to the same point
> after fopen()-ing in text mode?
Yes, you can, and you will end up in the same place in the file.
DJGPP can achieve all this magic because the mechanism that strips the CR
characters is *above* the one that reads them into the buffer of the FILE
object. In other words, the file is read without any conversions into
the buffer, and the CR characters are only stripped when the application
actually consumes the characters via functions like `getc', `fscanf',
`fread', etc., on the way to the application's buffer.
> Answering these questions will tell you what the side effects are, but
> they don't eliminate them.
Well, I think the above indicates that there are no side-effects in the
DJGPP implementation. Do you agree?
> I would think that if you could eliminate the side effects on fseek() and
> ftell(), you probably could eliminate the need for "rb" as well.
No, this is another problem, since in text mode, not all characters that
are in the file are delivered to the application.
- Raw text -