Hi Robert,
I'm back online once more. Have you looked into this topic any
further? Unfortunately as I don't have a Windows box at it's a window
specific problem I'm rather stuck in debugging it.
Looking at it some more, the problem seems to be here:
virtual bool matchString( const std::string& str )
{
std::string s; readString(s); // (1)
if ( s==str ) return true; // (2)
else _in->seekg( -(int)(s.length()), std::ios::cur ); // (3)
return false;
}
(src/osgPlugins/osg/AsciiStreamOperator.h line 277 in trunk)
str is "UserDataContainer". readString(s) reads "Children", without
quotes of course, which is the next item in the string. (1) Then, since
the (s==str) test fails (2), it's supposed to seek back by 8 characters
(3). The call to seekg does give -8 as parameter, but for some reason
the call seems to not do anything, though it doesn't return an error
either...
Oh, I think I've just found the problem, and it's definitely weird if
it's that. It seems that when seeking back by 8 characters, the _fseek()
function (which seekg eventually calls) converts the relative position
of -8 to an absolute one. For that, it must know the current position in
the file, so it calls _ftell. It looks like it counts line endings as
\r\n when counting the characters, even if they are only \n in the
actual file. So the position it seeks back to is 148 - 8 = 140. Notice
that the "Children" line is the 9th line of the file, so there are
exactly 8 extra \r characters counted (by pure coincidence), and the
length of "Children" is also 8, so when seeking back to before
"Children" it actually seeks to right after it.
I don't know how to fix this. It seems to me like the _ftell function is
broken, it should count exactly what is in the file and not add extra
characters that aren't there. I guess setting the file to binary mode,
and then manually replacing all \r\n by \n, and then reading files as on
Linux on all platforms would work. Or, on Windows, we could read the
whole file in binary mode, replace \n with \r\n, and then use that in a
stringstream to be read from by the .osgt plugin. But that sounds like a
lot of work for something that should work automatically.
Did we ever have a similar problem for the other .osg plugin?
J-S
--
______________________________________________________
Jean-Sebastien Guay [email protected]
http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
