Closed WickedSmoke closed 9 months ago
Doesn't the fact that it's marked static
mean it's only accessible from that file, and so shouldn't cause name collisions? Similar for the rstrip
and lskip
helper functions -- they're also marked static
.
ini.c is being included in another module. This allows inih to be used and all the option macros to be set without touching the make files.
I'd rather not make changes here -- ini.c is intended to be a separate compilation unit, not included, otherwise static
kind of becomes meaningless. If you'd like to do amalgamation or https://en.wikipedia.org/wiki/Single_compilation_unit type stuff, unfortunately you're on your own. If you want, you could use #define strncpy0 ini_strncpy0
before the include, and #undef strncpy0
after -- that might work.
Using the same namespace for both internal & public symbols doesn't add any complexity or risk, so it seems a rather arbitrary decision to not allow the code to be used in a wider variety of environments.
I'll just have to maintain my own fork of the code.
Perhaps it's arbitrary. I just don't like the additional verbosity imposed for static
/ internal function names. That said, I'm not super-strongly opposed to it, but would like to see if or how other projects handle this. Can you point me to some respectable C projects that do what you're suggesting for static
/ internal names? (I've been out of the C world proper for a while.)
I'm not here to twist your arm, but thanks for considering it.
The stb project is a popular set of single-file libraries. So looking at stb_image.h as an example, I see every static function has an "stbi__" prefix (double underbars even). Not every file in the library takes such precautions but most do.
Another example is ImGui where in imgui_internal.h every static function has an "Im" prefix.
Okay, you've twisted my arm. :-) This won't hurt, and it's not as ugly as I thought it might be, so I'll merge this in #164.
My current project has a similarly named re-implementation of strncpy, so there was a compiler declaration error. Adding an "ini_" prefix to the three lines where the strncpy0 symbol is used fixed the problem, but it would be nice if ini.c was a bit more isolated out of the box.