Open dehorsley opened 4 years ago
You speak so eloquently in favor of it.
Monolithic by library seems like a way to get things started and get the main benefits relatively quickly, but maybe you have an idea for the logical groups. What kind of a time-scale are you thinking about?
Another suggestion for how to do this is to incrementally add prototype to sections of code as they are worked on for other reasons. This has some advantage since it would allow testing as you go, but would less be complete initially.
I did run into a small issue while looking at incrementally adding prototypes. For functions that have float
arguments, the prototyped functions seem to behave differently than the non-prototyped versions. Specially, the non-prototyped functions seem to convert a float
arguments to double
(really old C). Whereas with the prototype, the float
arguments seem to really be float
. In any event, calls that don't have a prototype declared don't work with the functions defined with a float
in a prototype (and probably vice-versa). One option to deal with this might be to change the float
arguments to double
. Although this is what the old code was actually doing, it seems at least unpleasant to change a function that is conceptually for a float
into one that is for double
.
Perhaps there might also be an issue with passing structures. In the bad old days, I think passing a structure was originally always by pointer. However, at some point (maybe I misremembering), it changed so that structure were passed as local copies unless the address was taken explicitly. If so, there might be a similar issue.
Most of the uses of FS libraries use implicit function declarations, which might be hiding some sleeping bugs --- especially with 64 bit conversion.
A better approach would be to make header files with the function declarations/prototypes and include them when needed. A tool like cproto could help generate the header files from what we currently have. This will also clean up some of those pesky compiler warnings!
We would need to decide how we should structure/arrange the headers. Some options:
include/clib.h
, etc.include/dbbc.h
(maybe these can be merged with the struct definitions that are already there)