Consider prefixing public functions with unique namespace

[jbaldwin]

I ran into an interesting issue where linking a project with libmysql.a as well as this library caused some extremely weird behavior, and eventually I found out there was a namespace clash as mysql also declares two functions base64_encode() and base64_decode(). Please considering prefixing your library C functions with a unique namespace. I've gotten around this by forking and just naming them differently for now but I want to say thanks for the great library, I've enjoyed using it. I'd also make a PR but I don't know what you'd want to prefix with and it is a breaking change to the API.

[aklomp]

Hi, thanks for the suggestion. Currently, this library claims the base64 namespace for all global functions, macros, structures and other objects exposed in the public headers. I guess this can cause conflicts with other software that also claim that prefix, but in my opinion, base64 is a reasonable prefix for a base64 library to claim.

Changing the prefix would break API compatibility, and while I am not opposed to that as long as it's accompanied by a major version change, I'm hesitant to do it unless necessary. As a thought exercise, I tried to come up with a few alternative prefixes, but they all seem poor. libbase64 is overlong, b64 is probably too generic, and using a made-up name would be confusing. Is there a prefix you had in mind?

Possibly this can be solved/fixed in the future when the library switches to building with Cmake, it might make it easier to configure a custom namespace.

[jbaldwin]

Yeah, I was unable to think of a good suggestion for a generic prefix as base64_ logically makes sense for this library.

How about an optional configuration define or macro which would prefix the functions accordingly if it is set by the user? Then you don't have to change the default API and users of the library can then pick any prefix they want. I know rapidjson uses this method to allow its users to namespace the entire codebase (its C++ but same concept I think).

[aklomp]

That sounds like a reasonable solution. However at this point it's hard to implement, because of the archaic way that the build system handles symbol visibility. All visible symbols are currently enumerated in exports.txt, which is a static textfile.

So the plan is to move the library to a Cmake-based build system. That would remove a lot of the build cruft ^{and replace it with new cruft}, and would presumably make it easier to add this sort of customization.

Would you be OK if I leave this issue open, but not resolve it for the time being?

[jbaldwin]

Yes, that sounds good to me. Thanks.