Hi J-S, Thanks for digging into the problem. I find it difficult to believe that tell, seek istream implementations are broken. It might be worth putting a tellg before and after the seek to see what values it's using.
As for moving to binary mode, this is possible, nor sure of the fallout though, but it terms of making sure we get the same results across all platforms it might well be the best thing to do. Off hand I don't know how much of a fallout this would have. As for the .osg plugin, I deliberately avoiding using seek and instead implemented caching of strings within the FieldReaderIterator to hide the fact that we'd read data in but then not use it directly. Potentially would could do something similar with InputStream, but again I'm not sure how much of a impact this might have. Robert. On Mon, Jun 27, 2011 at 6:46 PM, Jean-Sébastien Guay <[email protected]> wrote: > 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 > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
