#361 possible file descriptor bug while reading big-endian ints

WSL
closed
None
rejected
Known_Feature
2013-11-22
2003-05-31
No

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;

}

Discussion

  • Tyrel

    Tyrel - 2003-07-18

    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?

     
  • Earnie Boyd

    Earnie Boyd - 2003-07-18

    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.

     
  • Earnie Boyd

    Earnie Boyd - 2003-07-18
    • status: open --> closed-invalid
     
  • Tristan Nowak

    Tristan Nowak - 2003-07-18

    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.

     
  • Tristan Nowak

    Tristan Nowak - 2003-07-18
    • status: closed-invalid --> closed-accepted
     
  • Earnie Boyd

    Earnie Boyd - 2003-07-18
    • status: closed-accepted --> closed-rejected
     
  • Luke Dunstan

    Luke Dunstan - 2003-07-19

    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.

     
  • Earnie Boyd

    Earnie Boyd - 2013-01-24
    • labels: gcc -->
    • status: closed-rejected --> closed
    • resolution: --> rejected
    • category: --> Known_Feature
    • milestone: Known_bugs --> WSL
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks