I am having a tough time trying to get a simple C++ program to behave correctly in a Fedora 9 emulated environment under Parallels Desktop (v4.0.3810) running on a Macbook (2.4 GHz Intel Core 2 Duo). Basically, seeking to the end of a file being written is not working right. The code that I use (called junk.C) is listed below:
And to compile and run:
The erroneous value is shown in bold. It should have resulted in 32, not 0. It's as if the seek direction flag is being ignored by iostream::seekp() when run on the emulated Fedora system. When run on a native i386 machine (old Compaq from 2002) with an IDENTICAL Fedora Core OS installed, the code runs correctly. Furthermore, when I md5sum the compiled codes on the Compaq and under the emulated system, the executables are identical. And finally, even when I include the -static option to force static linking, the resulting executables also have identical checksums:
These were all compiled with the v4.3.0 gcc that comes standard with Fedora Core 9:
Can anyone suggest something I might be missing? Some hidden DLL or plugin causing the difference in behavior? Just one more data point: the above code compiles and executes correctly under the OS X g++ compiler. Thanks.
#include <fstream>
#include <iostream>
int main()
{
std::fstream outFile("junk.txt", std::ios:ut | std::ios::binary);
char msg[32];
for (int i=0; i<32; i++)
msg = i;
outFile.write(msg, 32);
#include <iostream>
int main()
{
std::fstream outFile("junk.txt", std::ios:ut | std::ios::binary);
char msg[32];
for (int i=0; i<32; i++)
msg = i;
outFile.write(msg, 32);
outFile.flush();
std::cout << "After writing 32 chars: " << std::endl;
std::cout << "tellp = " << outFile.tellp() << std::endl;
outFile.seekp(0, std::ios::beg);
std::cout << "After seeking to beginning:" << std::endl;
std::cout << "tellp = " << outFile.tellp() << std::endl;
// Here's the one that fails under Parallels Fedora Core
outFile.seekp(0, std::ios::end);
std::cout << "After seeking to end:" << std::endl;
std::cout << "tellp = " << outFile.tellp() << std::endl;
outFile.seekp(16, std::ios::beg);
std::cout << "After seeking 16 from beginning:" << std::endl;
std::cout << "tellp = " << outFile.tellp() << std::endl;
return 0;
}
And to compile and run:
% g++ junk.C
% ./a.out
After writing 32 chars:
tellp = 32
After seeking to beginning:
tellp = 0
After seeking to end:
tellp = 0
After seeking 16 from beginning:
tellp = 16
The erroneous value is shown in bold. It should have resulted in 32, not 0. It's as if the seek direction flag is being ignored by iostream::seekp() when run on the emulated Fedora system. When run on a native i386 machine (old Compaq from 2002) with an IDENTICAL Fedora Core OS installed, the code runs correctly. Furthermore, when I md5sum the compiled codes on the Compaq and under the emulated system, the executables are identical. And finally, even when I include the -static option to force static linking, the resulting executables also have identical checksums:
% g++ junk.C
% md5sum ./a.out
bfe32ddd40b13d760007bd5281d80e23 a.out
% g++ junk.C -static
% md5sum ./a.out
f45a77a9556d2d8cd83b8fc642b29233 a.out
These were all compiled with the v4.3.0 gcc that comes standard with Fedora Core 9:
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-cpu=generic --build=i386-redhat-linux
Thread model: posix
gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC)
Can anyone suggest something I might be missing? Some hidden DLL or plugin causing the difference in behavior? Just one more data point: the above code compiles and executes correctly under the OS X g++ compiler. Thanks.