Gabi had a look at the code and we decided to merge it.

I checked your change on my machine, now the file gets parsed without any
problems. Interesting that you still got "your" error with my file, maybe it is
because of the Visual Studio version...

I could avoid the problem on Windows by not using putback(). The code no longer
has the nice symmetry in

  check_magic(in, "begin_SG"); 
  ...
  check_magic(in, "end_SG");

but since this code only is about a part of the input that we ignore and since
we want to remove it in the future anyway, I hope this is ok. 

peek_magic wasn't used anywhere else, so I removed it as well. I think the
origin of the function was to support the old legacy file format.

The code is in my repository:
https://bitbucket.org/flogo/downward-issues/pull-requests/2



Salome, could you test if your error goes away with this change as well? You
would have to merge the two issues locally (or just manually copy and replace
the two lines from the pull request for the test). By the way, when I copied
your output file to the buildbot, I still got "my" error, not "yours". Seems
there is nothing wrong with the file, but the two machines generate different
errors.

For the record: we debugged the other error today and found that the DTG parser
read numbers [..., 3, 8, 206, ...] where the actual file only had [..., 3, 206,
...] while passing all of the "in.good()" assertions. The DTG parsing happened
after skipping the successor generator with peek_magic, so it potentially had
the same reason.

For now, I just added an assertion to check_magic(), so we'll recognize the
issue when it happens and the parser will not go into infinite loops.

On Windows there are problem files that are not completely parsed by
read_everything() because the input stream goes into an error state. In an error
state, every call to getline() returns an empty string.

Depending on where this happens, different errors can show up. For me this
happend while skipping the successor generator, and the parser then looped
forever to find the magic "end_SG". Salome reported a similar error where the
magic "end_DTG" was not found as expected.

The reason seems to be the function istream::putback which we use in
check_magic() to put the word we peeked at back into the stream if it wasn't the
magic word we looked for. The documentation
(http://www.cplusplus.com/reference/istream/istream/putback/) says that this
function can fail:

> If the call to sputbackc fails, the function sets the badbit flag.
> Note that this may happen even if c was indeed the last character
> extracted from the stream (depending on the internals of the
> associated stream buffer object).

The documentation of sputbackc says that it fails if

> the function calls the virtual protected member pbackfail if
> either there are no putback positions available at the get pointer
> (gptr), or if c does not match the character right before the
> current get position. 

I did not find any definitive information on how many "putback positions" a
stream has and if there is any way to control this.