Mail Archives: djgpp-workers/2001/09/28/10:58:52
On 28 Sep 2001 at 10:36, salvador wrote:
> Hi All!
>
> GCC 3.0 changed too much things in the C++ classes to follow the new
> standard (is that ISO C++ 1998?).
> I was "fighting" to support it in the TV library. Thanks to Andris and
> other
> people I got the library compiled. But while testing the examples I found
> a really strange behavior.
I tried at least.
One comment: testing for eof() is not enough (see my modified test
example below)
Unfortunatelly things looks grave to me. I suceeded to get more reasonable stream
output by some hack (by exchanging it to one testsuite failure for filebuf class).
Now it seems that we have problems also for input streams.
I guess that the source of these problems is that libstdc++-v3 assumes that
size of written data is the same as data in the memory (it is it assumes Unix
text file format). I somehow workarounded that for simple stream output but
I'm afraid compete fix would require serious reworking iostreams related stuff
in C++ standard library.
I think M$ Windows ports of GCC (Cygwin, MINGW) should also
suffer from the same problem. I'm not sure I'll touch this in nearest weeks
as I'm leaving to Finland in early morning in Monday
Andris
------------------ modified test example ----------------
#include <cstdio>
#include <fstream>
const int maxLineLength=200;
int main(void)
{
std::ifstream fileToView("test.txt");
char line[maxLineLength+1];
int len=0;
// while(!fileToView.eof())
while(fileToView)
{
fileToView.get(line, sizeof line);
char c;
bool s1 = fileToView;
int pos1 = fileToView.tellg();
fileToView.get(c); // grab trailing newline
bool s2 = fileToView;
int pos2 = fileToView.tellg();
printf("%d (%d) %d(%d) %d(%d) '%s'\n",strlen(line),c,pos1,s1,pos2,s2,line);
// Sanity stop
if (++len==20) return 1;
}
printf("EOF: %d\n",fileToView.eof());
printf("BAD: %d\n",fileToView.bad());
printf("FAIL: %d\n",fileToView.fail());
return 0;
}
------------------ it's output --------------------
10 (10) 15(1) 16(1) 'First Line'
12 (10) 28(1) 29(1) 'Another Line'
0 (10) -1(0) -1(0) ''
EOF: 0
BAD: 0
FAIL: 1
> I don't know if that is a bug and in this case if that's djgpp specific.
> So I need help from somebody with:
>
> a) Access to another systems with gcc 3.x (not djgpp)
> b) Knowledge about the new streams.
>
> It looks like a bug and as it is for lines that only contains EOL (\r\n)
> could
> be related to djgpp's \r\n to \n traslation. The following code compiled
> with
> gcc 2.95.x can read a complete file name meassuring the length of each
> line. The same code compiled with 3.0.1 will stop reading in the first empty
>
> line and from this point will enter in an endless loop. Note that EOF is not
>
> reached nor indicated with gcc 3.
>
> Here is the stripped code (the original loads the text in memory):
>
> #include <fstream.h>
>
> const int maxLineLength=200;
>
> int main(void)
> {
> ifstream fileToView("test.txt");
> char line[maxLineLength+1];
> int len=0;
> while(!fileToView.eof())
> {
> fileToView.get(line, sizeof line);
> char c;
> fileToView.get(c); // grab trailing newline
> printf("%d (%d)\n",strlen(line),c);
> // Sanity stop
> if (++len==20) return 1;
> }
> printf("EOF: %d\n",fileToView.eof());
> return 0;
> }
>
> Here is what you can use for `test.txt' to feed the example:
>
> <--------
> First Line
> Another Line
>
> The above is empty
>
> <---------
>
> Output from gcc 2.95.x compiled code:
>
> 10 (10)
> 12 (10)
> 0 (10)
> 18 (10)
> 0 (10)
> EOF: 1
>
> Output from gcc 3.0.1 compiled code:
>
> 10 (10)
> 12 (10)
> 0 (10)
> 0 (10)
> ....
>
> SET
>
> --
> Salvador Eduardo Tropea (SET). (Electronics Engineer)
> Visit my home page: http://welcome.to/SetSoft or
> http://www.geocities.com/SiliconValley/Vista/6552/
> Alternative e-mail: set AT computer DOT org set AT ieee DOT org
> Address: Curapaligue 2124, Caseros, 3 de Febrero
> Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013
>
>
>
- Raw text -