Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not export strlcat or strcpy in shared libraries #91

Closed
crrodriguez opened this issue Jul 6, 2024 · 7 comments · Fixed by #94
Closed

Do not export strlcat or strcpy in shared libraries #91

crrodriguez opened this issue Jul 6, 2024 · 7 comments · Fixed by #94

Comments

@crrodriguez
Copy link

size_t strlcpy(char * restrict dst, const char * restrict src, size_t size);

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

@mwilck
Copy link
Collaborator

mwilck commented Jul 8, 2024

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
Copy link
Author

crrodriguez commented Jul 8, 2024

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
Copy link
Collaborator

mwilck commented Jul 8, 2024

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

@mwilck
Copy link
Collaborator

mwilck commented Jul 8, 2024

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
Copy link
Collaborator

mwilck commented Jul 8, 2024

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
Copy link
Author

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
Copy link
Collaborator

mwilck commented Jul 8, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants