From: SourceForge.net <no...@so...> - 2003-07-19 04:00:58
|
Bugs item #746583, was opened at 2003-05-31 20:41 Message generated for change (Comment added) made by infidel 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: Rejected 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: Luke Dunstan (infidel) Date: 2003-07-19 12:00 Message: Logged In: YES user_id=30442 Please read the MSDN documentation for fopen(). Reading a text file stops at a Ctrl-Z character (0x1a). As for the default behaviour differing from Linux, I agree that MS should have made binary mode the default, or even better, they should have used \n line endings since the beginning of MS-DOS. However, MinGW is not going to attempt to change this because it will just break compatibility with programs that are designed for MSVC or previous versions of MinGW. ---------------------------------------------------------------------- Comment By: Tristan Nowak (sethur) Date: 2003-07-19 01:54 Message: Logged In: YES user_id=786571 Yes, that seemed to be the problem, but IMO the only difference between text mode and binary mode (when reading) is that 0D (\r) 0A(\n) is convertet to just 0A. So I have no idea why this should cause the read function to refuse working anymore when reading 00 00 00 1A. Besides that I don't think it's a good idea to have MS C Compilers have different default behaviors that Linux/Unix ones, especially in such important functions as read or write. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2003-07-19 00: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-19 00: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 |