Yes. The "private" signals are not part of the enum, and if a cc module wants to refer to them in a switch{}, the cast is necessary to silence that warning; cc_cdg, cc_chd and cc_vegas make use of these private signals. The alternative would be to add CC_CDG_DELAY, CC_CHD_DELAY, and CC_VEGAS_DELAY into cc.h as global enums.

I thought to leave these only in the scope of the respective cc module, and do the cast to int instead.

I see. Unfortunately enums are not expandable. One hack that can be done is this:

#define CC_GENERIC_ENUM  CC_ACK = 1, CC_DUPACK = .......................

enum cdgsignal_t {CC_GENERIC_ENUM, CC_CDG_DELAY = ...};

Probably using int cast is simpler.

Presumably, if you create a new type, for gdb to consistenly decode these private signals, you would have to use that type in the function definition - which would collide with the cc module function block definition; so to compile, you'd typecast within the switch, and loose gdb visibility again. So probably not much gain after all...