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

Reserved names #139

Closed
signoredeltempo opened this Issue Apr 9, 2015 · 4 comments

Comments

Projects
None yet
3 participants
@signoredeltempo

signoredeltempo commented Apr 9, 2015

The code has multiple undefined behavior points because of declaration and/or definition with reserved names, namely two underscores followed by a lower case letter (e.g. "__name") or one underscore and a capitalized letter (e.g. "_Name").

@borkmann

This comment has been minimized.

Show comment
Hide comment
@borkmann

borkmann Apr 9, 2015

Contributor

Could you elaborate on the concrete function signature or variable? Thanks!

Contributor

borkmann commented Apr 9, 2015

Could you elaborate on the concrete function signature or variable? Thanks!

@signoredeltempo

This comment has been minimized.

Show comment
Hide comment
@signoredeltempo

signoredeltempo Apr 9, 2015

Yeah, sure. In pcap_mm.c, for example, you define __pcap_mmap_write_need_remap(int fd), which is not allowed by such rules. See this for more info. Hope it's clearer now.

signoredeltempo commented Apr 9, 2015

Yeah, sure. In pcap_mm.c, for example, you define __pcap_mmap_write_need_remap(int fd), which is not allowed by such rules. See this for more info. Hope it's clearer now.

@tklauser

This comment has been minimized.

Show comment
Hide comment
@tklauser

tklauser Apr 10, 2015

Contributor

Does this cause any trouble (i.e. build failures) currently besides "breaking" the standard?

If not, I'd say this is not really critical. Changing these identifiers just for standard compatibility's sake is not worth it IMO.

Contributor

tklauser commented Apr 10, 2015

Does this cause any trouble (i.e. build failures) currently besides "breaking" the standard?

If not, I'd say this is not really critical. Changing these identifiers just for standard compatibility's sake is not worth it IMO.

@signoredeltempo

This comment has been minimized.

Show comment
Hide comment
@signoredeltempo

signoredeltempo Apr 10, 2015

Would it be ok for you if GCC defined builtin_expect in your name space instead of its (the one of the implementation)?
Anyways, the behavior is simply undefined. Most of the times, it will compile just fine because it's unlike anything beginning with pcap being defined; but it could just suddenly stop or even worse.

It's a pretty simple substitution, however, which you might or might not want to fix (it's no different from dereferencing NULL, actually). What you'd better consider, IMHO, is to no longer break it and so establish a more legal naming convention.
I don't know the motivation behind that mark, maybe are you tagging it as an "internal" function?

signoredeltempo commented Apr 10, 2015

Would it be ok for you if GCC defined builtin_expect in your name space instead of its (the one of the implementation)?
Anyways, the behavior is simply undefined. Most of the times, it will compile just fine because it's unlike anything beginning with pcap being defined; but it could just suddenly stop or even worse.

It's a pretty simple substitution, however, which you might or might not want to fix (it's no different from dereferencing NULL, actually). What you'd better consider, IMHO, is to no longer break it and so establish a more legal naming convention.
I don't know the motivation behind that mark, maybe are you tagging it as an "internal" function?

@tklauser tklauser closed this Oct 20, 2017

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