New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stop redeclaring system functions #7
Comments
Minimally this would eliminate the long-standing issue regarding errno in the qmail codebase, where The level of cross compatibility, correctness, and utility of system headers is materially different than it was in the 90's. I would like to see the standard headers used everywhere in the codebase for their stated purpose. Retrofitting doesn't even have to involve touching every file: a single header can include all possible and necessary system headers and that file can be precompiled for performance, if necessary. (My testing indicates precompiled headers in C projects are marginal to no performance difference.) As such, agreed. |
Touching every file will be no problem I guess, we can probably let IWYU or similar tools do the stupid work for us. |
This should be on our roadmap, no question. I'm worried that if we make a change like this now, before we've implemented most of the features people are currently applying patches for, we'll make it unnecessarily costly for would-be notqmail users to apply their patches, and we'll unnecessarily lose those users. (Related to this, earlier today I added a What happens to my custom patchset? section to the wiki.) Maybe I'm wrong and this particular change wouldn't affect any users. Rather than speculate, I'd like to set up an automated regression test: select a baseline set of popular patches, verify that each patch applies on its own, and maybe verify certain combinations too. Then we can run the regression test for a change like this one, and if it's still passing, I have nothing to be concerned about :-) |
This is definitely nothing for the first 2 releases, agreed. |
Added the regression-test idea as #17. |
We should really include <stdlib.h> and friends and get rid of all the handwritten forward declarations.
I don't think anyone remotely sane should care about SunOS or equally outdated system compatibility anymore. My rule of thumb would be: if it hasn't seen a decently complete C99 implementation we should not care. These machines should be kept away from the internet as far as possible. Oh, wait, the 80's have called and want their rsh security holes back…
The text was updated successfully, but these errors were encountered: