public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "scrimr at louisville dot stortek dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/17086] New: IOStreams Large File Support (> 2 GB) not fully implemented. Date: Wed, 18 Aug 2004 19:20:00 -0000 [thread overview] Message-ID: <20040818192027.17086.scrimr@louisville.stortek.com> (raw) Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.8/3.4.1/specs Configured with: ../configure --with-as=/usr/ccs/bin/as --with- ld=/usr/ccs/bin/ld --disable-nls Thread model: posix gcc version 3.4.1 Solaris 8 patch level is generic_108528-17 recommended patch cluster I converted this code from c library functions that did work for 64-bit files. Before the 3.4.1 compiler I could not create files >2 GB with this stream code but it was completely working properly for files <= 2 GB(-1). With the same program I can write files larger than 2 GB with the ofstream class (e.g. 5 GB), which I could not do before gcc 3.4.1, but now I am unable to seekg in files of any size with the ifsteam class. I also cannot sequentially read (without seeks) in files larger than 2 GB with the ifstream class (e.g. 5 GB). Code Snippit that fails (throws exception) is as follows: inStream.exceptions( ios::failbit | ios::badbit ); inStream.open( fileToProcess.c_str(), ios::in | ios::binary | ios::ate ); ... int markerLength = (verificationMarker()).size(); // = 5 inStream.seekg( -(rawSumLength()+markerLength),ios::cur); // 5 + 16 ... SumMarkerFromFile = new char[markerLength+1]; SumMarkerFromFile[markerLength] = '\0'; inStream.read( SumMarkerFromFile, markerLength ); The code opens the ifstream for a file in binary mode and at the end of the file. Then I try to back up 21 bytes for some data that I need to read. Then I try to read it and the code then throws an exception on the read. Both seekg and open do not seem to be failing. read is throwing an exception. The problem seems to occurs regardless of file size. I think the seekg call is causing a bad stream state and then the read throws an exception because of the bad stream state. Keep in mind that this does not work even for file less than or equal to 2 GB with the 3.4.1 compiler/libraies. Anyway, seekg may be one of the failing components. The wierd thing is that if I open a file and read it sequentially without seeks for files smaller than 2 GB it works fine. For files above 2 GB, the sequential reading does not work and does not even throw exceptions. It appears to work but I know there is no way that it read a 5 GB file in less than a second. So, it does not appear to be working here either. I think this iostreams LFS support needs to be carefully rechecked for completeness. Also, it seems that iostreams support in general seems to be broken for files below 2 GB now (e.g. seekg). If you have any questions or suggestions I would love to hear them. If you think I am doing something wrong I would love to hear that too. -- Summary: IOStreams Large File Support (> 2 GB) not fully implemented. Product: gcc Version: 3.4.1 Status: UNCONFIRMED Severity: critical Priority: P1 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: scrimr at louisville dot stortek dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: 3.4.1 GCC host triplet: 3.4.1 GCC target triplet: 3.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17086
next reply other threads:[~2004-08-18 19:20 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2004-08-18 19:20 scrimr at louisville dot stortek dot com [this message] 2004-08-18 19:28 ` [Bug libstdc++/17086] " pinskia at gcc dot gnu dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20040818192027.17086.scrimr@louisville.stortek.com \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).