Skip to content
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

Open
DerDakon opened this issue Jul 8, 2019 · 6 comments
Open

Stop redeclaring system functions #7

DerDakon opened this issue Jul 8, 2019 · 6 comments
Labels
Milestone

Comments

@DerDakon
Copy link
Member

DerDakon commented Jul 8, 2019

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…

@alanpost
Copy link
Contributor

alanpost commented Jul 8, 2019

Minimally this would eliminate the long-standing issue regarding errno in the qmail codebase, where extern int errno doesn't work on at least Linux due to macros implementing thread-local storage (if my memory is true).

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.

@DerDakon
Copy link
Member Author

DerDakon commented Jul 8, 2019

Touching every file will be no problem I guess, we can probably let IWYU or similar tools do the stupid work for us.

@schmonz
Copy link
Member

schmonz commented Jul 8, 2019

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 :-)

@DerDakon
Copy link
Member Author

DerDakon commented Jul 9, 2019

This is definitely nothing for the first 2 releases, agreed.

@alanpost alanpost added the build label Jul 9, 2019
@schmonz
Copy link
Member

schmonz commented Jul 11, 2019

Added the regression-test idea as #17.

@alanpost
Copy link
Contributor

PR #43 and PR #44 draw down, in their own way, the pervasive redeclaration of system functions.

@alanpost alanpost added this to the 1.08 milestone Jul 23, 2019
@DerDakon DerDakon pinned this issue Jan 15, 2023
@schmonz schmonz modified the milestones: 1.09, 1.90 Sep 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants