>Hmm. Sounds like the parser needs to flag cases like this and, at
>minimum, ignore requests to include files of the same name and location.
>You "may" have cases where you have the same name, but different
>contents, in a different directory though, so you do need to account for
>and allow that, but that means more complex checking, like seeing if the
>files are identical via a "diff" type parse. Just storing the name and
>directory, then refusing to load it, wouldn't cause as much of a problem
>though. Though, why it doesn't just replace one set of definitions with
>the new ones (or fail with an error), and not crash....

There's nothing conceptually wrong with being able to include
files from sub-include files, it's just what causes the crashes.
(Though it's possible to create infinite loops that way, which
probably would cause a nesting error.)

It would be good to just add a handler for those file errors,
either with a parse fail, or a retry after closing and re-opening
the file, (and seeking to the last spot read in).

A typical work-around is to use #ifndef in include files...

#ifndef (_TRANSFORMS_INC)
   #include "transforms.inc"
#end

It's also possible to get invisible garbage at the end of a
file, adding a few blank lines and hitting delete a bit can
fix that sometimes.

Or you could just increase max_trace_level and do a
little voodoo dance =P

Post a reply to this message