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

Make an include guard unique #2

Closed
elfring opened this issue Jul 7, 2018 · 10 comments
Closed

Make an include guard unique #2

elfring opened this issue Jul 7, 2018 · 10 comments

Comments

@elfring
Copy link

elfring commented Jul 7, 2018

I find that an include guard like “ACO_H” can be too short for the safe reuse of your header file (when it belongs to an application programming interface).

@hnes
Copy link
Owner

hnes commented Jul 7, 2018

Good point, how about change 'ACO_H' to something like 'ACO_V1_H'?

V1 here means the major version number.

@hnes hnes self-assigned this Jul 7, 2018
@elfring
Copy link
Author

elfring commented Jul 7, 2018

How do you think about to make include guards unique by appending a kind of UUID?

@hnes
Copy link
Owner

hnes commented Jul 7, 2018

I think 'ACO_V1_H' is long enough.

The compilation errors will be yielded when it is happened (could be very rarely) that there is some other c header file has the exactly same include guard 'ACO_V1_H' (because many other 'aco_*' macros and prototypes which are defined in 'aco.h' is always required by the 'aco.c' and other libaco application source files).

I'll commit this adjustment soon :-)

@elfring
Copy link
Author

elfring commented Jul 7, 2018

I am curious then how often corresponding name space issues will occasionally matter.

@hnes
Copy link
Owner

hnes commented Jul 7, 2018

How do you think about to make include guards unique by appending a kind of UUID?

I think that kind of solution probably be a little overweight. Imaging that there is a UUID hex in the include guard :D

But maybe one day this would be added into to the new C standard. Be honestly, personally I think this solution is a very good solution.

@hnes
Copy link
Owner

hnes commented Jul 7, 2018

There is some search results about the "uuid include guard". It has been used on some occasion.

@hnes
Copy link
Owner

hnes commented Jul 7, 2018

One problem here is, the possible inner api & macros collision (say there is another aco.h which also have some maybe different aco_* macros and prototypes) may still exist even when the include guard is unique. In some cases, I think the compilation errors would be yielded more easily when the two collision aco.h have the same include guard.

@hnes
Copy link
Owner

hnes commented Jul 7, 2018

People normally would think that the C header file name (say "aco.h") is usually corresponding to the macro name of the include guard ("ACO_H" in this case).

If there is a totally different macro name of the include guard with the file name, it may would delay or even suppress some compilation errors that should be yielded as soon as possible.

So I think it is not necessary to use a different macro name of the include guard in aco.h, let's keep "ACO_H".

(Unless we choose to change the all aco_* started macros and prototypes into aco_{$UUID}_* in our source files, then the collision naming problems is solved fundamentally... But this kind of solution is only suited for very special and rare situations in real life.)

@hnes hnes added wontfix This will not be worked on Proposal and removed wontfix This will not be worked on labels Jul 7, 2018
@elfring
Copy link
Author

elfring commented Jul 7, 2018

People normally would think that the C header file name (…) is usually corresponding to the macro name of the include guard ….

The expectations are varying, aren't they?

…, let's keep "ACO_H".

  • The probability for name clashes might be low enough also for such an identifier (for a while).
  • Other name variants can be safer.

@hnes
Copy link
Owner

hnes commented Jul 8, 2018

The expectations are varying, aren't they?

…, let's keep "ACO_H".

  • The probability for name clashes might be low enough also for such an identifier (for a while).
  • Other name variants can be safer.

Yes, I agree with you. So, let's just remain what it is.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants