GNOME Bugzilla – Bug 704907
Namespace violations for internal-use functions beginning with __xml - should be xml_internal_
Last modified: 2021-07-05 13:21:29 UTC
libxml2 defines a number of internal-use functions with names beginning with __xml. This is non-conforming C. Per 7.1.3 Reserved identifiers (C99), "All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use." These functions should be renamed to something conforming such as xml_internal_...
Did you got a problem in practice with this ? If yes which toolchain/platform ? I have been doing this kind of things since 1995 without any troubles, and while some linking toolchaines use the _ to expose exported symbols since I use them for symbols not exported precisely, this ought to be just fine ! So unless there is a specific problem, I won't 'fix' this, Daniel
The problem is that you have thousands of libraries, and for one of them to refuse to fix this is not a problem, but once you hit thousands or tens of thousands violating the namespace, the chance of a collision becomes significant. Where this would come into play is if something internal to the implementation (libc, libgcc, etc.) needed to parse XML, and either reused libxml2 or had code with similar naming. All external symbols in such code would have to be renamed to begin with double underscores, to guarantee that they can't clash with valid application/library code. However, if a library like libxml2 already has symbols in this namespace, even code that has been safely prepared for the implementation namespace might clash with libxml2. The reason it's not appropriate to "wait until something breaks" is because, once something breaks, it's hard to fix. There will still be lots of deployments of the old, namespace-violating library around. The other motivation for fixing this bug is to stem off cargo culting. New programmers read existing code and copy idioms from it. The idiom of prefixing "private" symbols with __ is invalid C, and you don't want people copying it.
The symbols are not exported. I'm actually taking a proactive stance here not relying on standard or goodwill, I only export the symbols officially exported from the public header files. Have a look at doc/apibuild.py , doc/libxml2_api.xml, doc/symbols.xml and the generated libxml2.syms namespace is enforced, though the symbol file ! Not a bug ! Daniel
When static linking or incorporating inside part of the implementation, visibility does not do anything. Moreover, if you're already using visibility, there's no reason to also use __ as some kind of (misused) marker that these are private. Just remove the __'s and be done with it.
Static linking is bad practice for a shared library shipped as part of most base OS platform, plus it tends to break on various ways, not gonna develop this here. Incorporating inside of the implementation is also another serious problem, i.e. how do you propagate security updates. You're now using completely different arguments to push for the same request and sorry, I still don't buy them ! I still believe the __ is a very good way to clearly tell "this is private", and if there is no associated risk, why should I change ? Also the mailing list is the place where portability issues ought to be discussed, not a bug hidden somewhere in GNOME bugzilla, that nearly nobody except me is gonna give a look at. Daniel
The reason you shouldn't do it is that it's invalid C. Your belief that it's "a very good way" to do something does not change the fact that it's not valid usage. The GCC developers agree, and in fact there is an open bugtracker/wishlist item for making invalid usage of reserved-namespace identifiers a warning/error: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51437 Basically, breaking this rule is pretty much like running a red light. Nothing bad is automatically going to happen, but if something does break, it's your fault. And it's best to just correct the situation before it becomes an issue.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/libxml2/-/issues/ Thank you for your understanding and your help.