Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#34 non-standard extensions may throw off the parser


C for embedded systems often contain pragmas and typedefs like int16 etc. Cscope is not tolerant of these extensions unlike for exmaple "source insight" is. While some of it can be mitigated by defining away pragmas as empty and using typdefs in system level files, but it is not always possible to do so. For example, one processor's C defines extensions of the form:

int storageClass(MEM:ADDR) myVariable;

Now because of colon in the above statement, we cannot do

#define storageClass(x)

and get rid of the problem.

Should expand to look beyond Linux kernel and into other vistas.


  • Your claim that cscope were "not tolorant of these extensions" is doubly wrong. First, those aren't extensions. Second, cscope is every bit as tolerant of these language features as it should be.

    Your accusation about cscope being Linux kernel centric is equally baseless.

    Your explanation about why #define storageClass doesn't have the desired effect is wrong, too. The : is not the problem --- if any, the problem is that cscope, for various reasons, doesn't run the preprocessor at all, so _no_ macros are expanded.

    • status: open --> open-invalid
    • summary: embedded C --> non-standard extensions may throw off the parser
    • status: open-invalid --> closed-invalid
    • Group: -->