Open ghost opened 6 years ago
This kind of plumbing work is something I've been postponing for a while. (There are plenty of other things to clean up in the source code that have a similar nature; the header files for instance are a mess.)
For things that are lwan-specific, like the configuration file parser, yes, adding a prefix would help. For things that are implementation details, such as the linked list, string pattern matcher, and hash table functions -- I guess the best solution would be to just use a linker version script in the ELF targets.
e2b3ce23 added a version script. Only some symbols are being exposed right now. Next on the list is to determine what other symbols without the lwan_
prefix should be exposed, rename them so that they have the proper prefix, and update the version script.
The shared library exposes commonly used symbols that can be accidentally overridden by the linker. Here's an example:
After successfully compiling this code, the output of the executable will always be:
Lwan will always fail to read the configuration file because the linker has replaced its implementation of
config_open
with this one.Other seemingly harmless names include
str_find
,parse_int
,list_check
andhash_add
. Names like that are common in application code. Users have to either mark their functions static or use prefixes to avoid naming conflicts.Are there any plans to add the
lwan_
prefix or to not expose these symbols from the library?