Microsoft visual c++ runtime library runtime error usually happen due to incomplete installation. Incomplete installation would also mean that certain files or folders required to run the program have gone missing or are not found in the directory. It is impossible to replace the missing files manually, and as such, the only way to solve this problem is to uninstall and reinstall the program in question. However, just remember to keep a back up copy of all the files or documents just in case something unexpected happens while reinstalling the program.

That’s why I suggested the yacc output example; the #line directives in the generated C code lead to debugging information and error messages that point to lines in the higher level source, which don’t line up neatly with C data structures. include directives are just one special case of that…

Also, beware that GCC plays games with a slew of extensions that are not part of the C language standards and that can play havoc with your grammars.

In terms of things like #line, I suggest looking at Antlr’s (http://antlr.org/) notion of having multiple channels. I.e., things like #line go into a side-channel separate from the mainline code.

I considered this possibility, but rejected it because handling #line at the level of the lexer is “hackish”. While at the parser level I can simply have the rules (PLY syntax):

""" pp_line_spec    : INT_CONST_DEC STRING_LITERAL
                            | INT_CONST_DEC
        """

""" pp_line  : PPHASH PPLINE pp_line_spec PPEND
"""

At the lexer level I will be forced to parse forward manually after I’ve detected #line. It’s pretty simple to pass the line number from the parser to the lexer (by holding an offset) and get all the line numbers correctly in this manner.

But what you’re saying regarding the complete freedom of #line’s location is true, and perhaps I will be now forced to reconsider this design decision and do it at the lexer level.

int
#line 5 "file"
n = 9;

Basically it’s independent of the language grammar (for example, I run cpp on source files which aren’t C); the idea to me is that you have a token stream, and each token remembers its definition location (file, line), and #line “escapes” the normal token stream and modifies the current file and line maintained by the lexer, but never gets past the lexer.

I see no reason to use the #line directive unless a file was included, and why would a file be included in the middle of a struct spec.

newlib is a good “easy” choice, since it’s based on an old BSD libc so it started out fairly cross-platform and not especially gcc-centric like linux headers tend to be. Depending on what you plan to do with this parser (programmatic augmentation of C code with additional checks? automatic conversion of headers to pyrex or ctypes declarations?) you might consider treating that as merely a starting point and trying GNU libc as your next challenge…