© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
f33e652
(Get the code!)
> #ifndef REC_TYPE
> #define RECTYPE dbCommon
> #endif
>
> This seems to carry the implicit assumption that each source file has device support for a single
> record type, which is not the case for any driver I've written.
The situation for device support is more complicated than for record support. This is because each record type can (and has to) add methods to the common subset known to base. And these definitions have always been implicit, i.e. not published in a header file, which is the first thing that would have to change when we attack the device support problem.
This is why I tried to focus the discussion to record support, where the situation is more regular. I know of no record support module where a single C file implements more than one record type. Besides, what prompted this bug report was a crash of EPICS base due to type errors in dbConvert.c, when calling record support methods.
The most immediately pressing issue is to fix these bugs ASAP in all branches. This (and lazyness) is why the patch I made is against the 3.14 branch. I did not mean to ask you to apply that patch in any public bzr repo without modification. The patch I sent is there to help you identify these bugs and as proof that the idea is sound in principle.
> An expensive change with no way back.
Adding one line per C file is not expensive. And there is no reason why anyone would want to go back on this.
I already said (but perhaps not with enough emphasis) that the changes needed to adapt record supports are compatible. Why would one additional #define before including recSup.h break anything w.r.t. the old recSup.h? Also note that there are *no* uses of the typedef RECSUPFUN in base. This implies that if record supports that are not in base remove their uses of RECSUPFUN (so they are 3.16 compatible) then they are still compatible to base versions with the old recSup.h.