Scanner

Scanner splits parse tree into individual declarations and performs various manipulations with them.

Declarations are uniquely identified by their primary symbol names. This means that we can get clashes of symbols that actually live in different namespaces in C – modern C anyway. Hard clashes (i.e. also in C) are:

• macro name with anything else (we let functions supersede parameterless macros though)
• among variable, function, type and enum value names

We get additional artifical name clashes between

• enum or struct names and the names from the second point above

This restriction can be lifted, but there are expenses and using identical names for structs or enums and other symbols is considered a bad practice. So I'm not sure whether it worths fixing. In any case this has to be decided rather soon as it has wide consequences for the data structures.

Since we have struct-field splitting mechanisms in place, it would be possible to use them for splitting declarations such as:

typedef struct _LineFace {
    double  xa, ya;
    int     dx, dy;
    int     x, y;
    double  k;
} LineFaceRec, *LineFacePtr;

The parser extension required would be easy, the problem is that the usual splitting would give us:

typedef struct {
    double  xa, ya;
    int     dx, dy;
    int     x, y;
    double  k;
} LineFaceRec;

typedef struct {
    double  xa, ya;
    int     dx, dy;
    int     x, y;
    double  k;
} *LineFacePtr;

which means everything would have to be documented twice. It would be nice (and is possible) to split it into

typedef struct {
    double  xa, ya;
    int     dx, dy;
    int     x, y;
    double  k;
} LineFaceRec;

typedef LineFaceRec *LineFacePtr;

although this cannot be done generally. I'm not sure whether implementing such a singular transform is that useful.

We wish to support anonymous enums such as

enum {
    G_ASCII_DTOSTR_BUF_SIZE = 29 + 10
};

as they are preferred to

#define G_ASCII_DTOSTR_BUF_SIZE (29 + 10)

because they form a symbol and show in the debugger. The difficulty is the presentation. As this moment generates an impossible symbol name of the form anonymous-enum-file-num for the enum. However, this name should not appear in the documentation, yet it should be referrable.