Question

Thank you for maintaining this project — it has been a great foundation for our work.

The Notification_Class object is currently backed by a fixed-size 2-D array:

/* nc.c */
#ifndef MAX_NOTIFICATION_CLASSES
#define MAX_NOTIFICATION_CLASSES 2
#endif
static NOTIFICATION_CLASS_INFO NC_Infos[MAX_NUM_DEVICES][MAX_NOTIFICATION_CLASSES];

Other basic objects such as ai.c and av.c have already moved to OS_Keylist-based dynamic storage, which allows sparse instance numbering and eliminates the static memory footprint. We would like to apply the same pattern to nc.c:

• Replace the fixed array with static OS_Keylist Object_Lists[MAX_NUM_DEVICES].
• Add Notification_Class_Create / Notification_Class_Delete / Notification_Class_Cleanup following the same lifecycle as the other keylist-based objects.
• Remove the instance == index identity assumption and support arbitrary instance numbers on demand.

Another inconvenience with the current approach: to use instance 10, the array must be sized with #define MAX_NOTIFICATION_CLASSES 11, even if only that single instance is needed. A keylist-based approach would allocate instances on demand regardless of their numeric value, avoiding this kind of over-allocation.

Because the internal storage layout changes and new exported symbols are added, this would be an ABI-breaking change and would likely require a version bump.

Would a contribution along these lines be welcome? We are happy to prepare a PR if the direction is agreeable.