Date: Tue, 23 Sep 1997 18:11:02 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: molnarl AT cdata DOT tvnet DOT hu
cc: djgpp-workers AT delorie DOT com
Subject: Re: perl and stdio test
In-Reply-To: <Pine.SOL.3.95.970923155740.3138B-100000@dumballah.tvnet.hu>
Message-ID: <Pine.SUN.3.91.970923180333.15819F-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


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.