Name collision with GNU Scientific Library

[ivan-aksamentov]

Guidelines Support Library shorthand "GSL" if will get widespread could be ambiguous in projects that use GNU Scientific Library (shorthand is GSL). Namespace gsl:: is used for some C++ wrappers for GNU Scientific Library. Same goes for macro prefixed with GSL_.
Related to #9 #38

[martinmoene]

To prevent the collision, one can also prefix with lowercase gsl_like

gsl_FEATURE_THROW_ON_FAILURE

as I do in my GSL variant. I think it also improves readability.

P.S. Above name better describes the effect than GSL_SAFER_CPP_TESTING.

Edit: mmm maybe it should be called ...FEATURE_THROW_ON_ASSERTION ?

[neilmacintosh]

We will change the name to be prefixed appropriately once we decide on a namespace.

To be clear about the design: failure should only result in exceptions to support testing of the library. The by-design failure is to call std::terminate().

[martinmoene]

Thanks, so it's more like CONFIG_THROWS_FOR_TESTING.

[neilmacintosh]

Ok. After reflection, we are sticking with "gsl"

We can't avoid conflicts with every other thing out there, so we will stick with something sensible for this library. The language provides simple mechanisms for users to resolve conflicts if they hit them, with minimal effort.

[davidkennedydev]

@neilmacintosh if isn't much painful, can you cite a minimal effort solution that resolve namespace conflicts?

[gdr-at-ms]

Exactly which 'namespace conflicts'? The GNU Scientific library is a C library can be used from a C++ program.

[galik]

When my IDE auto completes for #include <gsl/... I get a myriad of GNU Scientific Library headers presented. Also at least a couple of C++ wrapper libs for the scientific library use namespace gsl {} so it would be good to know how to resolve that problem.

For example: http://gslwrap.sourceforge.net/namespace__gsl.html

Additionally on programming forums and Q&A sites the tag gsl is likely to be already dedicated to the scientific library as it is indeed on Stack Overflow: https://stackoverflow.com/questions/tagged/gsl

@neilmacintosh I appreciate what you say about not being able to avoid conflicts with "every other thing out there" but the GSL (scientific library) is a prominent one that is well known and established.

[gdr-at-ms]

So, do we have an IDE problem?

The GNU scientific library makes it is clear that it is a C library: https://www.gnu.org/software/gsl/manual/html_node/ANSI-C-Compliance.html#ANSI-C-Compliance

[galik]

Perhaps one way of solving this is to create a larger encompassing namespace for the library "vendor" as such. Perhaps this would be a good guideline too (I do it with my libs).

Something like:

namespace microsoft {
namespace gsl {

//...

} // gsl
} // microsoft

Then I can select from different vendors version of the gsl like:

using namespace microsoft;

gsl::span<> spanner;
// etc...

Or if I want to use both the scientific library and this library I can do:

namespace msgsl = microsoft::gsl;

msgsl::span<> wrench;
// etc...

[galik]

"The GNU scientific library makes it is clear that it is a C library"

Well on its introduction page it says:

"The GNU Scientific Library (GSL) is a numerical library for C and C++ programmers."

So,even though it is written in C it is not unlikely they might begin shipping their own C++ wrappers at some point rather like the GMP does (GNU Multiprecision Library).

[gdr-at-ms]

The Microsoft implementation of the GSL (the C++ Core Guidelines Support Library) shouldn't leak into the interface (usage of the GSL), nor should the implementation of the GSL by any other vendor.

What you say above makes sense, when the library is intended to be associated with a specific vendor. The GSL isn't intended to be a Microsoft thing. We actually expected from the very beginning to see more implementations (mostly one per compiler vendor). The fact that the Microsoft implementation works with at least three major compilers shouldn't be used as incentive to leak the implementor to the interface.

[gdr-at-ms]

@galik: the official GNU Scientifc library is unambiguous -- please do read the link I pointed to:

The library is written in ANSI C and is intended to conform to the ANSI C standard (C89). It should be portable to any system with a working ANSI C compiler.

The library does not rely on any non-ANSI extensions in the interface it exports to the user. Programs you write using GSL can be ANSI compliant. Extensions which can be used in a way compatible with pure ANSI C are supported, however, via conditional compilation. This allows the library to take advantage of compiler extensions on those platforms which support them.

When an ANSI C feature is known to be broken on a particular system the library will exclude any related functions at compile-time. This should make it impossible to link a program that would use these functions and give incorrect results.

To avoid namespace conflicts all exported function names and variables have the prefix gsl_, while exported macros have the prefix GSL_.

The Core Guidelines does not use gsl prefixes.

[galik]

I think the main benefit of having an over encompassing namespace is the ability to disambiguate the detailed namespace. If you want to be vendor neutral you could go for something like this:

namespace cpp_core_guidelines {
namespace gsl {

// ...

} // gsl
} // cpp_core_guidelines

Though I still think there is value in being able to differentiate between different implementations of the library with namespaces.

If the wider namespace is gsl then I am unsure how you can rename it to disambiguate:

namespace msgsl = gsl; // whoops, this also renames the scientific library wrapper I am using

[gdr-at-ms]

So, who ever is providing a wrapper around the GNU scientific library could just put gnu around gsl.

[galik]

@gdr-at-ms Exactly.

But they are less likely to do that unless projects like this recommend it as a means to allow users to disambiguate their library from other projects. If every projects had an overall wrapping namespace, that was very unlikely to be duplicated (such as gnus_not_unix), it would make avoiding clashes easy. Otherwise we could end up in this type of situation:

// library A
namespace abc {

//...

} // abc

And...

// library B
namespace abc {

//...

} // abc

Then...

#include <project_a.h>
#include <project_b.h>
// how to disambiguate?
namespace aabc = abc;// whoops that won't work!
namespace babc = abc;// neither will this...

BUT

#include <project_a.h>
#include <project_b.h>
// how to disambiguate?
namespace aabc = project_a::abc; // yay, I can fix this!
namespace babc = project_b::abc; // with either library.!

[gdr-at-ms]

I think my overall point may have been lost.

[galik]

@gdr-at-ms It's possible i missed your point. I think I drifted off into a more general idea about solving potential namespace clashes - not necessarily the GSL. It occurred to me that you have no defense if two libraries use the same general namespace tag. I thought that libraries in general might benefit their users by having a larger, unique, outer namespace. That would allow us to disambiguate any name clashes. I'm not sure how such name clashes can be avoided if neither library provides an outer namespace. Perhaps in an ideal world all libraries would wrap their names in something unambiguous so that users could unambiguously alias the inner names to avoid conflicts should they arise? But I suppose this is probably more CppCoreGidelines territory.

[grahamreeds]

'I'm not sure how such name clashes can be avoided if neither library
provides an outer namespace."

You argue about it on the respective forum(s) until one of them changes
their name.

GR

Sent from my Nexus 6P

On 26 Sep 2016 3:26 p.m., "Galik" notifications@github.com wrote:

@gdr-at-ms https://github.com/gdr-at-ms It's possible i missed your
point. I think I drifted off into a more general idea about solving
potential namespace clashes - not necessarily the GSL. It occurred to
me that you have no defense if two libraries use the same general namespace
tag. I thought that libraries in general might benefit their users by
having a larger, unique, outer namespace. That would allow us to
disambiguate any name clashes. I'm not sure how such name clashes can be
avoided if neither library provides an outer namespace. Perhaps in an
ideal world all libraries would wrap their names in something
unambiguous so that users could unambiguously alias the inner names to
avoid conflicts should they arise? But I suppose this is probably more
CppCoreGidelines territory.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#31 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEy9nLjOo5k-m23gqRweVSd0CWtWwybWks5qt9YdgaJpZM4GC030
.

[rianquinn]

One of the arguments was that they didn't want to expose the "vendor" as part of the GSL. I disagree with this. If you need a more generic namespace, you can always rename it yourself. Having vendor specific namespaces would solve this problem, and it's easy enough for a user to either rename the namespace to something generic, remove the namespace, or just use it. Either way, just ignoring the issue and saying the the GNU Scientific Library should change, and not the GSL doesn't seem fair.

[gdr-at-ms]

@rianquinn Nobody has shown concrete conflicts or problem. The GNU scientific library prefixes its names with gsl_; the GSL doesn't. Nobody has produced concrete conflicts so far. It seems we are now in the middle of non-productive 'arguing' and people are encouraging others to do just that. Given the exceedingly scare time resource at our disposal, I will get back to this when there is new fact that can lead to a productive outcome.

[rianquinn]

@gdr-at-ms I'm pretty sure @galik gave a concrete example.

[MikeGitb]

@gdr-at-ms: Another concrete example of a namespace conflict can be found here https://github.com/kevinchannon/gslpp (although the name is controlled by a macro and can easily be changed). I've no Idea, if there are more libraries that use that namespace and if they are used in many projects or not (the ones galik and I linked to look pretty abandoned to me).

@ALL: Personally, I agree that this name collision is very unfortunate and ideally should have been avoided when the gsl has been invented or at least, after this issue was opened. Especially, because it is not only about namespaces, but - as @galik explained previously - also about (include-) directory names, search keywords, tags etc. I faintly remember, that there was another discussion about this topic some time ago, but I can't find it right now.

However, I think the abbreviation is established by now, the library is apparently used in more and more production environments and we should also keep in mind that the gsl is targeting a much wider audience. Admittedly, that doesn't necessarily mean that it will actually be used more often than the GnuSL, but my gut feeling is (and I'd like to see some actual data on this) that making the gsl's namespace more complicated will "hurt" more users than if a GnuSL wrappers would change theirs (the needs of the many vs. the needs of the few ;) ). That is particularly true, if you consider, that the gsl types are very likely to appear in library interfaces (at least I hope so).

The only counterargument I can think of is: Many types/functions of the gsl are about to be standardized anyway and will move to the std namespace (or become language features). So in the (very very) long run, the whole gsl might become obsolete - unless there is a plan to add more types and functions in the future.

I'm also not looking forward to littering my whole code base with namespace mygsl=<long prefix name>::gsl, but the discussion about best practices to avoid name space collisions in general is imho more fitting for the cppcoreguidelines repository.

Finally, to come back to the question by @davidUser, before it gets swept under the rug:

The language provides simple mechanisms for users to resolve conflicts if they hit them, with minimal effort.

if isn't much painful, can you cite a minimal effort solution that resolve namespace conflicts?

That would indeed be interesting - maybe this is a no-issue after all.

[grahamreeds]

Generally when two open source projects names clash the newer project
changes its name. The example that springs to mind is Firebird which became
Firefox despite the browser being arguably the more popular.

GR

Sent from my Nexus 6P

On 26 Sep 2016 18:22, "MikeGitb" notifications@github.com wrote:

@gdr-at-ms https://github.com/gdr-at-ms: Another concrete example of a
namespace conflict can be found here https://github.com/kevinchannon/gslpp
(although the name is controlled by a macro and can easily be changed).
I've no Idea, if there are more libraries that use that namespace and if
they are used in many projects or not (the ones galik and I linked to look
pretty abandoned to me).

@ALL https://github.com/all: Personally, I agree that this name
collision is very unfortunate and ideally should have been avoided when the
gsl has been invented or at least, after this issue was opened. Especially,
because it is not only about namespaces, but - as @galik
https://github.com/galik explained previously - also about (include-)
directory names, search keywords, tags etc. I faintly remember, that there
was another discussion about this topic some time ago, but I can't find it
right now.

However, I think the abbreviation is established by now, the library is
apparently used in more and more production environments and we should also
keep in mind that the gsl is targeting a much wider audience. Admittedly,
that doesn't necessarily mean that it will actually be used more often than
the GnuSL, but my gut feeling is (and I'd like to see some actual data on
this) that making the gsl's namespace more complicated will "hurt" more
users than if a GnuSL wrappers would change theirs (the needs of the many
vs. the needs of the few ;) ). That is particularly true, if you consider,
that the gsl types are very likely to appear in library interfaces (at
least I hope so).

The only counterargument I can think of is: Many types/functions of the
gsl are about to be standardized anyway and will move to the std
namespace (or become language features). So in the (very very) long run,
the whole gsl might become obsolete - unless there is a plan to add more
types and functions in the future.

I'm also not looking forward to littering my whole code base with namespace
mygsl=::gsl, but the discussion about best practices to
avoid name space collisions in general is imho more fitting for the
cppcoreguidelines repository.

Finally, to come back to the question by @davidUser
https://github.com/DavidUser, before it gets swept under the rug:

The language provides simple mechanisms for users to resolve conflicts if
they hit them, with minimal effort.

if isn't much painful, can you cite a minimal effort solution that resolve
namespace conflicts?

That would indeed be interesting - maybe this is a no-issue after all.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#31 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEy9nJS2TZ0gMtsXJa_8TZySktbFQSD3ks5qt_9mgaJpZM4GC030
.

[gdr-at-ms]

@rianquinn: @galik was gave a more abstract example of possible conflicts, but not a concrete example of the subject of this issue.
@MikeGitb : agreed with your notes to "@ALL".

[rianquinn]

@gdr-at-ms I'm not sure what you mean by concrete if this is not enough:

When my IDE auto completes for #include <gsl/... I get a myriad of GNU Scientific Library headers presented. Also at least a couple of C++ wrapper libs for the scientific library use namespace gsl {} so it would be good to know how to resolve that problem.

For example: http://gslwrap.sourceforge.net/namespace__gsl.html

@MikeGitb I agree with your comment to everyone as well. If this issue is addressed, it should not effect people currently using the GSL.

@grahamreeds I agree 100%. I don't think it's fair to just right off the problem and say it's GnuSL's problem, make them change their (or their wrapper's) code. That's not a great way to make friends in the open source community.

The best solution I have would be to provide a macro that extends the namespace for this library to add the vendor. This way, if your using a GnuSL wrapper, or you have more than one GSL library, you can figure out which one you want to use. By default, the namespace extension should be left turned off so that the mod doesn't effect current users of the library.

[bdeeming]

Disclaimer: I've never used inline namespaces before, so this might not even behave as I describe...
Perhaps an

inline namespace globally_unique_name {
namespace gsl {
}
}

would allow uninterested (and existing) users of the GSL to ignore globally_unique_name's presence, but allow others who have a clash to access & alias the desired inner namespace?

Doesn't address the issue of include paths however...

[omeid]

I can't install microsoft-gsl on my system because the headers will conflict with the original gsl. If you install, microsoft-gsl on linux, you will end up with two different libraries under /usr/include/gsl/, it is only matter of time they use the same filename. gsl.h anyone?

@neilmacintosh: We can't avoid conflicts with every other thing out there, so we will stick with something sensible for this library. The language provides simple mechanisms for users to resolve conflicts if they hit them, with minimal effort.

That is profoundly shortsighted and oblivious to the current ecosystem.