reserved identifier violation

[elfring]

I would like to point out that identifiers like "__COCKPIT_H__" and "_Daemon" do not fit to the expected naming convention of the C language standard.
Would you like to adjust your selection for unique names?

[magcius]

Is there a practical fallout that can happen as a result of this? We've been writing code like this for years in other projects, to the point where it's common practice.

[elfring]

How do you think about to avoid that this software depends on undefined behaviour?

[stefwalter]

Hmmm, it's not undefined behavior in any of the compilers we build on, like gcc. There are probably hundreds of thousands of such defines and usages all over the open source.

For example the linux kernel uses the form __HEADER_H__ for it's header guards. You can see this all over glibc, gtk+, glib, and thousands of other projects.

It seems to be one part of the C where the undefined behavior is in fact defined.

If you wish to have a broader conversation about this, you probably want to start a discussion on a broader mailing list. Or if you already have had such a discussion and a consensus was reached, could you point it out?

[elfring]

How do you think about to stop bad habits eventually?

[magcius]

I don't know of any compiler that will make it truly undefined behavior. If it builds the Linux kernel fine, it will build our project fine. That includes gcc, clang, suncc, Intel's C compiler, and others.

If you successfully manage to convince the glibc and the Linux kernel maintainers to remove their invalid identifiers, then we'll talk about fixing GTK+, glib, and Cockpit.

[elfring]

Other software developers applied corrections for the affected implementation detail already. I am curious if you would also like to care for standard-compliance one day.

[magcius]

Are you sure? I went into the Linux source code, picked a random header file, and look what I found:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/video/gbe.h

Almost all the header guards I can find in any header in the Linux kernel source starts with an underscore.

So, as I said, if you successfully convince the Linux kernel and glibc to adopt standards-compliant header guards, we'll follow suit.

[srh]

Ignoring the standards weeneeism for a minute, dangerous things can happen when name conflicts happen at the same time, like an include guard conflict in combination with a struct name conflict where the structs share a common field name. A name like __TYPES_H__ is kind of asking for trouble. Almost all potential problems could be mitigated if you had a project-unique prefix in the include guards.

[stefwalter]

@srh, good point. #204 should fix that.

[elfring]

How do you think about to make your include guards not only standard-compliant but also really unique by appending a kind of UUID?

[maddie-boby]

You seriously want to add a UUID to an include guard? Are you kidding? You've got to be trolling with this. It's seriously the most pedantic thing I've ever seen in my life, especially since there's literally no actual real world consequences for using this sort of undefined behavior.

[ketsuban]

I would charitably suggest they mean "universally unique ID" in a nontechnical sense ("a sigil to prevent name collisions") rather than the specific technical meaning. "Universally unique ID" is an annoyingly generic term to have reserved for one specific kind of thing, it's like ImageMagick taking "convert" all for itself.

[magcius]

No, he is actually suggesting something like this.

[ketsuban]

Wow, okay, yeah, that's completely insane. I was sympathetic to the original argument, but that's absurd given that their own citation says the likelihood of any harm coming from the violation is low.

[stefwalter]

Pushed fix for non-prefixed include guards pointed out by @srh.

If anyone wants to reopen this, do so with a patch ready for review.