search

opensvc / multipath-tools

Other
59 stars 47 forks source link

Do not export strlcat or strcpy in shared libraries #91

Closed crrodriguez closed 1 week ago

crrodriguez commented 2 months ago

https://github.com/opensvc/multipath-tools/blob/efa6a26c4b1c3bb7fc7f550be918867e1f26a9cb/libmpathutil/util.h#L24

Function names beggining with "str" are reserved to libc implementation of string functions, recent glibc releases have strlcat and strlcpy exported as well..

mwilck commented 2 months ago

Thanks for reporting this. I wasn't aware that glibc has started to support strlcpy.

The only way to "fix" this would be to rename the function. We need to export it because it's used by libmultipath.

What problem exactly do you see? There are only very few programs that link to libmpathutil, and most of them are part of multipath-tools itself. Actually all I can think of is qemu-pr-helper and Red Hat's SID (storage instantiation daemon). And even if there was some other program, then this program would simply call libmpathutil's strlcpy(), which, AFAIK, conforms to the specs.

Can you provide a reference for your assertion that 'function names beggining with "str" are reserved to libc'?

crrodriguez commented 2 months ago

I wish i could make the rules.. https://www.gnu.org/software/libc/manual/html_node/Reserved-Names.html

post-ed: I forgot, strlcpy/strlcat were added to the next revision of POSIX Issue 8 published on 14 June 2024.

mwilck commented 2 months ago

Alright, thanks. We'll rename the function, then.

mwilck commented 2 months ago

We don't comply with this spec at all though. In particular, we use lots of identifiers starting with underscores. I've actually been aware of this for some time, but up to now resolved to ignoring it :-/

mwilck commented 2 months ago

Just for confirmation, AFAIU you aren't aware of any real problems arising from our exporting of strlcpy, it's more a general standards compiance issue. Right?

crrodriguez commented 2 months ago

Well.. there may be a symbol clash/ambiguity which one to call ..now the gibc version is a weak symbol so YOUR version wins. no idea about musl thou.

mwilck commented 2 months ago

IMO our version would win anyway. Because of ld.so's breadth-first symbol lookup algorithm. We might see issues if we tried to link statically.