After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 704907 - Namespace violations for internal-use functions beginning with __xml - should be xml_internal_
Namespace violations for internal-use functions beginning with __xml - should...
Status: RESOLVED OBSOLETE
Product: libxml2
Classification: Platform
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: Daniel Veillard
libxml QA maintainers
Depends on:
Blocks:
 
 
Reported: 2013-07-26 02:01 UTC by bugdal
Modified: 2021-07-05 13:21 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description bugdal 2013-07-26 02:01:27 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_...
Comment 1 Daniel Veillard 2013-07-30 03:06:16 UTC
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
Comment 2 bugdal 2013-07-30 16:42:39 UTC
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.
Comment 3 Daniel Veillard 2013-07-31 00:11:36 UTC
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
Comment 4 bugdal 2013-07-31 00:54:50 UTC
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.
Comment 5 Daniel Veillard 2013-07-31 02:31:34 UTC
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
Comment 6 bugdal 2013-07-31 03:07:04 UTC
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.
Comment 7 GNOME Infrastructure Team 2021-07-05 13:21:29 UTC
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.