Mail Archives: djgpp-workers/1997/09/23/11:12:08
On Tue, 23 Sep 1997 molnarl AT cdata DOT tvnet DOT hu wrote:
> Perl's Configure script uses this test, to decide whether libc's stdio is
> "standard". I was a little bit surprised, when I saw that the script wrote
> that "Your stdio isn't very std.". I looked at libc's source, and found,
> that _filbuf doesn't convert 0x0d 0x0a -> 0x0a if the file is opened in
> text mode, but getc() does. Then I found why: there is an optimalization
> in fseek() which wants the bytes unaltered. I'm just curious, is there
> another reason why filbuf doesn't make the conversion?
The reason is that we wanted both CRLF -> NL conversions *and* correct
byte counts from `fseek', without losing the buffering. So the buffer
maintained as part of the FILE structure holds the original contents of
the file on disk, with the CR characters; they are only stripped by the
functions that are used to read the file, like `getc', `fread', etc.
So Perl is right: if ``standard stdio'' means that the contents of the
buffer is the same as what's returned to the application, then DJGPP's
stdio is not very standard.
> $cat >try.c <<EOP
> #include <stdio.h>
> #define FILE_ptr(fp) (fp)->_ptr
> #define FILE_cnt(fp) (fp)->_cnt
Am I to understand that Perl actually assumes that the FILE structure
includes members called `_ptr' and `_cnt'? If so, then it deserves to
fail here. Is there any law against calling these members by any other
name that I can fancy? These are internals of the implementation, and no
program should depend on such internal details.
- Raw text -