[Mingw-notify] [ mingw-Bugs-746583 ] possible file descriptor bug while reading big-endian ints

[SourceForge.net <no...@so...>]

Bugs item #746583, was opened at 2003-05-31 08:41
Message generated for change (Comment added) made by earnie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=746583&group_id=2435

Category: gcc
Group: Known bugs
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Tristan Nowak (sethur)
Assigned to: Danny Smith (dannysmith)
Summary: possible file descriptor bug while reading big-endian ints

Initial Comment:
Here's another strange thing I encountered while 
compiling some linux source using file descriptors with 
MinGW's gcc 3.2.3. The following code compiled and 
runned perfectly using Mandrake 9.1 and GNU gcc. 
However, using MinGW's gcc 3.2.3, a strange runtime 
error occured. The program writes 5 random integers 
converted to network byte order (big-endian) to a file, 
one of which is exactly 26 (hex: 00 00 00 1A). Then it 
opens the file using file descriptors in read only mode 
and reads the integers one by one, converting them 
back to host byte order (on my machine little-endian) 
and displaying them. The number of bytes read by the 
read function is also displayed for each integer. As soon 
as 26 (00 00 00 1A) is read, read returns 3 (only 3 bytes 
read, not 4) and each following call of read returns 0 (no 
mather how many bytes are still left). All other numbers 
I tried did not produce this reaction, only 26 did. As 
mentioned above this problem doens't occur with 
Linux/GNU gcc.
Any ideas?

/* test program for the mentioned fd bug */
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
#ifdef __WIN32
#include <winsock.h>
#include <stdint.h>
#else
#include <netinet/in.h>
#endif

int main  (int argc, char **argv)
{
	int fd, i;
	FILE *output;
	int32_t zahlen[5];
	int32_t rzahlen[5];
	int numread;
	
	/* convert some random numbers to 
                 * big-endian, one must be 26 */
	zahlen[0] = htonl(2);
	zahlen[1] = htonl(123);
	zahlen[2] = htonl(243);
	zahlen[3] = htonl(26); 
	zahlen[4] = htonl(3364);
	
	/* write the numbers to a file, using streams */
	output = fopen(argv[1],"wb");
	fwrite(zahlen, 4, 5, output);
	fclose(output); 
	
	/* open the file for reading, using file 
                 * descriptors */
	fd = open(argv[1],O_RDONLY);
	if (fd < 0) perror(argv[1]);
	
	/* read the integers, convert them back to 
                 * host order and print them
	 * and the number of bytes read for each 
                 * integer */
	for (i=0;i<5;i++) {
	    numread = read(fd, &rzahlen[i], 4);
	    rzahlen[i] = ntohl(rzahlen[i]);
	    printf("%d bytes have been read, number");
                    printf("is: %d\n", numread, rzahlen[i]);
	}
	
	close(fd);
	return 0;
}


----------------------------------------------------------------------

>Comment By: Earnie Boyd (earnie)
Date: 2003-07-18 12:55

Message:
Logged In: YES 
user_id=15438

This is an MS feature.  You need to use or an O_BINARY with
the O_RDONLY to prevent this effect.

Earnie.

----------------------------------------------------------------------

Comment By: Tyrel (thewizard75)
Date: 2003-07-18 12:20

Message:
Logged In: YES 
user_id=625091

So the problematic line is open(argv[1],O_RDONLY).

On Linux, open() opens the file in a binary (untranslated) way 
by default.  On Windows, open() opens the file in text 
(translated) way by default.  Changing the open line to 
open(argv[1],O_RDONLY | O_BINARY) seems to fix the 
problem on my windows box.  Does that solve it on your 
system too?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=746583&group_id=2435