Closed crrodriguez closed 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'?
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.
Alright, thanks. We'll rename the function, then.
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 :-/
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?
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.
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.
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..