C++Talk.NET Forum Index C++Talk.NET
C++ language newsgroups
 
Archives   FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Weird ofstream/ifstream behavior

 
Post new topic   Reply to topic    C++Talk.NET Forum Index -> C++ Language (Moderated)
View previous topic :: View next topic  
Author Message
wxkevin@yahoo.com
Guest





PostPosted: Sat Jun 18, 2005 9:25 am    Post subject: Weird ofstream/ifstream behavior Reply with quote



I am writing a file and then reading it back in at another time. I
write a "marker" at the beginning of the file to identify the file. So
in my write method I do something like:

unsigned int marker = 0xFEEDBEEF;
ofstream file;
file.open( fileName );
file.write( (char *)&marker, sizeof(marker) );
// Then a record of data is written out after

In the read method I do:

unsigned int inMarker;
ifstream file;
file.open( fileName );
file.read( (char *)&inMarker, sizeof(inMarker) );

inMarker ends up with the value 0xFEBEEFBE! When I do a hex dump of the
file, I see the 0xFEEDBEEF in the first 4 bytes but for some reason I
am getting the wrong value noted above when I do the read.

Any thoughts? This is running on Solaris 8.


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
Stephen Howe
Guest





PostPosted: Mon Jun 20, 2005 9:00 am    Post subject: Re: Weird ofstream/ifstream behavior Reply with quote



Quote:
I am writing a file and then reading it back in at another time. I
write a "marker" at the beginning of the file to identify the file. So
in my write method I do something like:

[snip]

Quote:
inMarker ends up with the value 0xFEBEEFBE! When I do a hex dump of the
file, I see the 0xFEEDBEEF in the first 4 bytes but for some reason I
am getting the wrong value noted above when I do the read.

Any thoughts? This is running on Solaris 8.

Should you not be opening the file in binary mode?

Stephen Howe



[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]


Back to top
Wadim.Grasza@gmail.com
Guest





PostPosted: Mon Jun 20, 2005 9:01 am    Post subject: Re: Weird ofstream/ifstream behavior Reply with quote



Maybe you should open the file in binary mode to avoid translation of
some characters.


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
kanze@gabi-soft.fr
Guest





PostPosted: Mon Jun 20, 2005 9:19 am    Post subject: Re: Weird ofstream/ifstream behavior Reply with quote

[email]wxkevin (AT) yahoo (DOT) com[/email] wrote:
Quote:
I am writing a file and then reading it back in at another
time. I write a "marker" at the beginning of the file to
identify the file. So in my write method I do something like:

unsigned int marker = 0xFEEDBEEF;
ofstream file;
file.open( fileName );
file.write( (char *)&marker, sizeof(marker) );
// Then a record of data is written out after

In the read method I do:

unsigned int inMarker;
ifstream file;
file.open( fileName );
file.read( (char *)&inMarker, sizeof(inMarker) );

inMarker ends up with the value 0xFEBEEFBE! When I do a hex
dump of the file, I see the 0xFEEDBEEF in the first 4 bytes
but for some reason I am getting the wrong value noted above
when I do the read.

Any thoughts? This is running on Solaris 8.

Just that what you are doing is probably illegal:-).

Have you tried opening the files in binary mode? 0xFEEDBEEF
doesn't look like valid character data to me, so it may cause
problems when read (or written) as character data.

In this case, I suspect that the input routines are interpreting
the first couple of bytes as some sort of byte order sign,
deciding that the file was written in non-native byte order, and
doing some byte swapping. (The normal Unicode byte order mark
is 0xFEFF; the presence of an FE in one of your bytes may be
confusing the input routines.)

I'd also check as to what locale is set. Forcing the locale to
"C" should force one to one character translation in input, and
eliminate the problem (supposing the library conform).

Also, since you say it is under Solaris: if you are using Sun
CC, make sure it is a recent version, and select the option to
use the STLport, instead of the "standard" library -- the
default standard library delivered with Sun CC is really bad.
If the application is single threaded, I think you'll find g++ a
far better compiler than Sun CC. For that matter, even in a
multi-threaded application, I'm not sure that I wouldn't still
prefer working around the weaknesses in g++ (non-standard
handling of pthread_cancel, some small problems in std::string);
Sun seems to have put much of its C++ development on hold:-(.
(I find this a shame, because for a long time, Sun CC was my
favorite C++ compiler.)

Finally, as a general policy: if the file is text, use
character data as the file identifier. You'll gain in
portability. And if the file is binary, make sure you open it
in binary mode, *and* imbue locale( "C" ) before the first
access. (Also, in binary files, I tend to avoid frequent text
characters, 0x20, 0x30, 0x0A, etc. in the magic.) For what its
worth, I'd also write and read the magic as an array of bytes
(char's), and use memcpy to verify it. That makes it
independant of the byte order on the particular machine.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]


Back to top
Display posts from previous:   
Post new topic   Reply to topic    C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2006 phpBB Group
SEO toolkit © 2004-2006 webmedic.