codegooglecom / libproxy

Automatically exported from code.google.com/p/libproxy
GNU Lesser General Public License v2.1
0 stars 0 forks source link

library exports far too many internal functions #83

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
# nm -D --size-sort libproxy.so.0.0.0 
0000000000000004 T px_pac_get_url
0000000000000005 T px_pac_to_string
000000000000000c T px_url_get_port
000000000000000c T px_url_to_string
000000000000000d T px_url_get_host
000000000000000d T px_url_get_password
000000000000000d T px_url_get_path
000000000000000d T px_url_get_scheme
000000000000000d T px_url_get_username
000000000000000f T px_array_length
0000000000000012 T px_free
0000000000000014 T px_array_sort
0000000000000021 T px_config_file_get_value
0000000000000022 T px_strdict_free
0000000000000022 T px_url_is_valid
0000000000000024 T px_strdup
0000000000000025 T px_strdict_foreach
0000000000000027 T px_module_manager_free
000000000000002a T px_config_file_free
000000000000002a T px_pac_free
0000000000000038 T px_config_file_is_stale
000000000000003a T px_array_get
000000000000003b T px_strstrip
0000000000000040 T px_pac_new_from_string
0000000000000042 T px_proxy_factory_free
0000000000000043 T px_url_equals
0000000000000044 T px_array_foreach
0000000000000047 T px_strfreev
000000000000004b T px_module_manager_new
0000000000000050 T px_strndup
0000000000000055 T px_array_free
0000000000000058 T px_strdict_get
000000000000005c T px_malloc0
000000000000005f T px_strdict_new
000000000000005f T px_strrstrip
0000000000000062 T px_strlstrip
000000000000006c T px_pac_new
000000000000007c T px_array_del
0000000000000080 T px_array_find
0000000000000081 T px_array_new
0000000000000087 T px_url_free
0000000000000093 T px_strdupv
000000000000009c T _px_module_manager_register_type_full
000000000000009d T px_module_manager_load_dir
00000000000000c3 T px_strdict_set
00000000000000dc T px_strsplit
00000000000000ec T px_array_add
00000000000000f0 T px_strjoin
0000000000000105 T px_strcat
0000000000000128 T px_readline
0000000000000131 T _px_module_manager_instantiate_type_full
0000000000000132 T px_proxy_factory_new
0000000000000171 T _px_module_manager_register_module_full
00000000000001d2 T px_module_manager_load
00000000000001fd T px_config_file_new
0000000000000214 T px_url_get
000000000000021c T px_url_get_ips
0000000000000286 T px_pac_reload
00000000000003a5 T px_url_new
0000000000000799 T px_proxy_factory_get_proxies

Most of them should have hidden visibility.

Original issue reported on code.google.com by vda.li...@googlemail.com on 23 Feb 2010 at 4:08

GoogleCodeExporter commented 9 years ago
1. We already default to hidden visibility in trunk
2. trunk is now C++, so most of these functions don't exist anymore
3. Pretty much every symbol must be exported, since the modules require them.  
In
trunk this is especially true since the module manager is now its own library.

Please check out trunk and if you notice any problems, let me know.

Original comment by npmccallum@gmail.com on 23 Feb 2010 at 4:21

GoogleCodeExporter commented 9 years ago
typedef struct _pxProxyFactory  pxProxyFactory;

Names starting with _ are reserved for libc/compiler. Why do you use _ here?

> 2. trunk is now C++, so most of these functions don't exist anymore

Code size is going to grow threefold now.

> 3. Pretty much every symbol must be exported, since the modules require them.

libproxy/proxy.cpp: istringcmp() can be static.

I don't know, I am evaluating the code before deciding whether it's ok to use 
this
library in my project, and the fact that I see such trivial wrong things does 
not
instill much optimism. Sorry if this hurts you...

Original comment by vda.li...@googlemail.com on 24 Feb 2010 at 11:03

GoogleCodeExporter commented 9 years ago
The leading '_' issue should be fixed in r577.  Same for istringcmp().

Code size growth was a trade-off we made for code readability.  This decision 
was
made after gathering feedback from all applications which currently use 
libproxy.  If
code size is a major issue for your project (what is your project?), we can 
certainly
optimize for that.  There are only 3 C functions in the external API, so we are 
not
committed to C++ if it is a major problem.

Regarding trivial things wrong:
1. I don't claim to know everything
2. I don't mind learning
3. I aim to be easy to work with, quick to turn around fixes and accepting of 
patches

In short, I'm glad for you to point out any issues.  I will fix them ASAP.  We 
are
not at 1.0 yet, so we do have some time to fix some issues.

Original comment by npmccallum@gmail.com on 24 Feb 2010 at 2:33