nikhilgupta10
commented
7 years ago nikhilgupta10 imported these comments from Sourceforge: "dchassin":- status: new --> accepted
-
assigned_to: Jason Fuller --> David P. Chassin ,
"dchassin":There is definitely a problem, but it's not quite like it's accepting the bad macro. It is not clearly rejecting the bad macro either. The attached test does not emit an error, but it also does not complete processing the GLM file properly either.,
"dchassin":Confirmed that there is a missing error message in load.c/process_macro() when the macro name is not found. Fixed in r5426.,
"dchassin":- status: accepted --> assigned
- assigned_to: David P. Chassin --> Jason Fuller
-
Resolution: none --> validate ,
"dchassin":Note regarding implementation: the macro processing loader should be modularized so that all macros are listing in a table. This would allow modules and core extensions to add macro processing \hooks\ without requiring direct modification of the loader code.,
Parser is not \correctly\ failing on poor choices of macro naming. For example, when accidentally typing #Include\ (capital 'I') or #innclude\ (extra 'n'), the GLM stops loading beyond that point, but the model goes ahead and executes with the information it already has.
Not sure if this applies to other macros, but \include\ is definitely affected. This may be a bit tricky to deal with, considering the explicit ability to create inline macros. How do we catch for degenerative forms of existing macros without losing functionality?,