Message-ID:	<366FE4BC.E1996DDC@CGSTE.MQ>
Date:	Thu, 10 Dec 1998 11:11:56 -0400
From:	HANRIGOU <HANRIGOU AT cgste DOT mq>
X-Mailer:	Mozilla 4.06 [en] (Win95; I)
MIME-Version:	1.0
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>,
	"djgpp AT delorie DOT com" <djgpp AT delorie DOT com>
Subject:	Re: read/write in binary mode: fopen/open behaviour
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 981209192515 DOT 11864B-100000 AT is>
Reply-To:	djgpp AT delorie DOT com

Hi Eli,

Eli Zaretskii wrote:
> 
> On Wed, 9 Dec 1998, HANRIGOU wrote:
> 
> > That's why I think that's not a bug of the program. If it is, please
> > let me know.
> 
> I still do not understand why use `read' and `write', but not `open'.
I thought the only interest was the use of fstat (testing S_IFREG)
and fseek. I can't see any other reason. Nevertheless, this is GNU
code (not mine), so I think it is not so bad. Maybe I miss something... If you
want, I can send you the code of the entire function (about 271 lines), so as
making your own mind.

> Perhaps if you describe in a bit more detail how exactly the program
> fails, somebody might have a clue as to what goes wrong.
The programs fails in copying the entire binary file. It stops at
first ^Z, do newline<->CR/LF conversion, etc. That's why I suspect it
is a file mode problem.

> Yes, there is a drawback: there might be a bug lurking somewhere which 
> we sweep under the carpet instead of solving.  And since v2.02 is just
> released, if we don't solve it now, God knows when it will be
> solved...
Ok. I've tried to find a short piece of code that would reveal the problem.
For instance:

 #include <stdio.h>
 #include <unistd.h>

 #define BUFSIZE 100

 int main(int argc, char *argv[]) {
     char buf[BUFSIZE];
     int n;
     int bytes = 0;
     FILE *f;

     if (NULL == (f = fopen("foo", "rb"))) {
         printf("ABORT: cannot open file 'foo'\n");
         return -1;
     }

     while (0 < (n = read(fileno(f), buf, BUFSIZE))) {
         bytes += n;
     }
     if (0 == n)
         printf("%d bytes read\n", bytes);
     else
         perror("read: \n");
 }

Then I ran this program with a foo file containing many ^Z to check
that we read the entire file.
And... everything is OK. In fact in my first tests I had kept too much
from the original GNU code and, between first fopen() and read() loop 
there was a call to a function that resets file mode to ascii. 

I'm really sorry for that and having wasting your (precious) time.
I beg you pardon.

BTW is there an easy way to test current file type associated to a file
descriptor? I haven't been able to find this in libc.

> However, it seems from the library sources that it should have worked 
> as you expected, even without `setmode'.
Definitely!

Thanks for your help. Sorry again for this waste of time.

Best regards,
Philippe.

- Raw text -