POV-Ray : Newsgroups : povray.bugreports : Parse error: Uncategorized error thrown at parser/parsertypes.cpp line 62 : Re: Parse error: Uncategorized error thrownatparser/parsertypes.cppline 62 Server Time
29 May 2024 07:26:58 EDT (-0400)
  Re: Parse error: Uncategorized error thrownatparser/parsertypes.cppline 62  
From: William F Pokorny
Date: 24 Mar 2019 10:59:02
Message: <5c979b36$1@news.povray.org>
On 3/22/19 6:44 AM, William F Pokorny wrote:
> On 3/21/19 3:18 PM, clipka wrote:
>> Am 20.03.2019 um 19:27 schrieb William F Pokorny:
> ...
>> Can't reproduce on Windows; neither with DOS line endings (CR+LF) nor 
>> with Unix line endings (LF).
>> I'm running a slightly modified version, but if any of those 
>> modifications make any difference, I wouldn't know which ones.
>> Do you have the time and energy to investigate this further?
> Not today with a family visit later, but I'll put it on the list to play 
> with the issue more this weekend.

That was painful to run down, but changing Parser::IsEndOfInvokedMacro() 
in the file source/parser/parser_tokenizer.cpp as in the attached file 
fixes the issue.

Have to admit I'm not sure even now I completely understand what was 
happening (how it could happen perhaps). We seem to have been comparing 
structures in the original - which I don't think c++ does by default?

return (Cond_Stack.back().PMac->endPosition ==
CurrentFilePosition()) && ...

If this true though, why no compile warning or error? In any case, once 
in a while on the structure compare some error got thrown and caught by 
the parser code and no message was set which is why we get the unhelpful 
generic something wrong message. Mostly calls to the compare above 
seemed to work - including ones prior to the failing one for the test 
case - returning false always.

I'm tempted to add a throw on a true test for the re-coded version then 
run a bunch of stuff to see if it true ever really happens. Have we been 
doing something like comparing pointers (and so false) always? But, I've 
already spent a day on this and I don't feel like spending additional 

For the particular test cases you can also hard code that function to 
return false always and things work because that test is always false 
for it.

Lastly, I did try a debug -Og compile thinking maybe we had some 
compiler issue here, but it failed in the same way.

Anyone who better understands what happened / how direct struct compares 
could sort of seem to work, please feel free to jump in and explain.

Bill P.

Post a reply to this message

Download 'isendofinvokedmacro_update.txt' (1 KB)

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.