www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1998/10/27/17:25:35

Sender: nate AT cartsys DOT com
Message-ID: <363655F3.9C8100C8@cartsys.com>
Date: Tue, 27 Oct 1998 15:23:31 -0800
From: Nate Eldredge <nate AT cartsys DOT com>
X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.35 i486)
MIME-Version: 1.0
To: djgpp AT delorie DOT com
Subject: Re: Is this a bug with DJGPP? Pls Help.
References: <Pine DOT GSO DOT 3 DOT 96 DOT 981026153052 DOT 19076A-100000 AT expert DOT cc DOT purdue DOT edu>
Reply-To: djgpp AT delorie DOT com

Nathaniel Johnson wrote:
> 
> try using long instead of int

I rather doubt that will make any difference; on DJGPP, they are exactly
the same data type.

> > I don't know what happened, I can read both my post and attachment
> > perfectly... Anyhow I'll try this again. My problem is with the following
> > code, when I set number = 996546 the thing runs golden, but when number =
> > 888888, the thing screws up, it reads back in the wrong number (It reads
> > back in something like -32000). I've tested the same code with CC and g++
                                                                         
^^^
On DJGPP, or some other platform?

> > and it worked fine with both. Anybody know why DJGPP is giving me the
> > grief? Did I do something wrong? Did I break some convention that I don't
> > know about?

Yup-- on DOS, you have the text/binary file distinction.  Under DOS,
lines of text files are terminated with CR/LF pairs, while most C/C++
programs expect to see a bare linefeed `\n'.  So the DJGPP library
converts on input and output.  When dealing with files that aren't lines
of text, you must set binary mode to disable this conversion.  In C++, I
believe this is done by or-ing `ios::bin' with your open flags.  In
vanilla C, use a "b" for `fopen' or `O_BINARY' for `open'.

The reason it only showed up with 888888 is this: 888888 decimal =
0x000d9038 hex.  The byte 0d is the ASCII CR, and so DJGPP followed it
with an LF to get the expected CR/LF.  But when it read it back, it saw
CR/LF and converted it to a LF, giving you a different number.

> > --------------8<------------------------------------8<-------------------------------
> >
> > #include <fstream.h>
> > #include <iostream.h>
> >
> > int main(){
> >
> >         char text[26];
> >         int number;
> >
> >         for(int x = 0; x < 25; x++)
> >                 text[x] = (x % 10) + '0';
> >         text[25] = '\0';
> >
> >         number = 888888;
> >
> >         cout << "Before going through the file : " << endl;
> >         cout << text << endl;
> >         cout << number << endl;
> >
> >         fstream file;
> >
> >         file.open("data", ios::out);
> >         file.write(text, sizeof(text));
> >         file.write((char *) &number, sizeof(number));
> >         file.close();
> >
> >         text[0] = 'N';  //  TO SHOW IF THE STUFF IS ACTUALLY GETTING READ
> >         text[1] = 'o';  //
> >         text[2] = 'p';  //
> >         text[3] = 'e';  //
> >         text[4] = '!';  //
> >         text[5] = '\0'; //
> >         number = 0;     //
> >
> >         file.open("data", ios::in);
> >         file.read(text, sizeof(text));
> >         file.read((char *) &number, sizeof(int));
> >         file.close();
> >
> >         cout << "After going through the file : " << endl;
> >         cout << text << endl;
> >         cout << number << endl;
> >
> >         return(0);
> >         }

-- 

Nate Eldredge
nate AT cartsys DOT com

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019