search

tmpvar / stl

parse/serialize stl files
29 stars 7 forks source link

Ensure ascii emissions are queued until we are sure the file is actually ascii #4

Open tmpvar opened 6 years ago

tmpvar commented 6 years ago

The behavior for looking ahead to determine if the file is actually ascii was actually emitting data before we made that determination. This fixes that by adding a queue that holds on to all ascii emissions (mainly description, but the other types are covered as well) until we encounter a facet string.

cc @stuartpb

stuartpb commented 6 years ago

Sounds good to me: does this also fix the issue where endsolid would trigger a second description?

stuartpb commented 6 years ago

Actually, would it be possible to merge this and #3? I'd imagine there are more consuming libraries that'd be tripped up by an embedded null in the description than ones that would want to read past it.

tmpvar commented 6 years ago

I think with this fix we avoid the situation where the ascii codepath is followed (including emitting events) until it finally figures out that it's actually ascii or binary. The fix in #3 is specifically for the ascii codepath (we probably don't expect \0 chars in the ascii version), but if we properly detect that the file is binary we can throw away all of the pending ascii events and restart on the binary path.

I'll add some more testing to make sure description is only emitted once for this case, but I'm pretty confident that had to do with the ascii path emitting one description and then the binary path emitting another.