makeheaders bug?

(1) By anonymous on 2024-02-04 15:44:59 [source]

Thanks to makeheaders, I haven't written a header file since 2009. So, thanks for the great tool.

I just came across a bug - or what looks like a bug - when feeding this code to makeheaders (from checkin 8c7bf45096cfc0f5):

#if EXPORT_INTERFACE
typedef struct thing1 thing1;
typedef struct thing2 thing2;
typedef int (*thing3)(thing4, thing2*, void*);
enum thing4 {
    VERY,
    LITTLE,
    BRAIN,
};
#endif

#if LOCAL_INTERFACE
struct thing1 {
    int stuff;
    char *bother;
    thing3 fun;
    void *data;
};

struct thing2 {
    int more_stuff;
    char *more_bother;
    thing3 more_fun;
    void *more_data;
};
#endif

Which results in the following header:

/* This file was automatically generated.  Do not edit! */
#undef INTERFACE
#define LOCAL_INTERFACE 0
enum thing4 {
    VERY,
    LITTLE,
    BRAIN,
};
typedef enum thing4 thing4;
typedef struct thing2 thing2;
struct thing2 {
    int more_stuff;
    char *more_bother;
    thing3 more_fun;
    void *more_data;
};
typedef int(*thing3)(thing4,thing2 *,void *);
typedef struct thing1 thing1;
struct thing1 {
    int stuff;
    char *bother;
    thing3 fun;
    void *data;
};
#define EXPORT_INTERFACE 0

With the obvious problem that thing3 is defined after its first use.

Thanks,

Mark

(2) By anonymous on 2024-02-04 18:13:14 in reply to 1 [link] [source]

Reduced test case:

Input:

#if EXPORT_INTERFACE
typedef struct thing1 thing1;
typedef struct thing2 thing2;
typedef int (*thing3)(thing2*);
#endif

#if LOCAL_INTERFACE
struct thing1 { thing3 fun; };
struct thing2 { thing3 also_fun; };
#endif

Output:

/* This file was automatically generated.  Do not edit! */
#undef INTERFACE
#define LOCAL_INTERFACE 0
typedef struct thing2 thing2;
struct thing2 { thing3 also_fun; };
typedef int(*thing3)(thing2 *);
typedef struct thing1 thing1;
struct thing1 { thing3 fun; };
#define EXPORT_INTERFACE 0

(3) By Stephan Beal (stephan) on 2024-02-04 23:35:16 in reply to 1 [link] [source]

I just came across a bug - or what looks like a bug - when feeding this code to makeheaders

Thank you for the report.

A cursory glance at makeheaders.c suggests (possibly incorrectly) that it doesn't have enough context to properly handle the ordering in a recursive case like the one you demonstrate. It could (should?) possibly be modified to emit all typedefs first, which looks like it would resolve your case, but...

As makeheaders is a build-infrastructure tool, rather than a separate supported deliverable, it's unlikely to be significantly changed until it breaks for its intended uses in the main fossil tree. That's not to say that it can't or shouldn't be done, but is to say that it won't be treated as a priority problem. (That said: there would of course be no objections if someone itched by this problem scratches that itch.)