Pro-C has problems when limits.h is included

Question

I know an (the?) answer, but to be sure:
What do you get when you run 'proc' on a file that includes
<limits.h>? The answer is only interesting if proc-parameter
PARSE is one of FULL or PARTIAL, but not NONE.
null

Answer 1

Michael Hasenstein (guest) wrote:
: Pinwu Xu (guest) wrote:
: : INTERNAL ERROR: Failed assertion [PGE Code=90105]
: : make: *** [lim_err.o] Segmentation fault (core dumped)
: I found two bugs.
: bug 1: When Pro-C finds a precompiler-directive it doesn't
know,
: it complains. So far so good. The bug is that the error message
: is different depending on if the unknown directive is in the
: top-level file proc was originally called for or in one of the
: included files. In the latter case the error message is a
: meaningless and wrong "Failed assertion", where the real
error
: would be something like "Encountered the symbol
: "here's-the-offending-symbol" when expecting one of the
: following:...".
: bug 2: There's an '#include_next <..>' in limits.h. Pro-C
doesn't
: know #include_next. I was told that directive is relatively new
: but standard, and Pro-C shouldn't complain, but there's more:
the
: #include_next in limts.h is protected by #if...#endif, but Pro-
C
: parses it anyway, which is okay, how else would it find #else
or
: #endif, but it should not comlain about unknown commands in a
: section it has to ignore anyway. YOu can also test with #if
: 0...#endif and an unknown #bla in between that Pro-C complains
: about the #bla. gcc's precompiler cpp on the other hand will
: ignore the #bla, because it doesn't have to deal with it anyway
: because of the '#if 0'.
: Both bugs together lead to the error message "failed assertion"
: when <limits.h> is included (there are some more glibc-.h files
: that use #include_next)
We experience the same problem whit mathcalls.h
proc coredumps with PGE Code=90105
null