5 ms·
The chances of glibc importing openbsd derived functions are practically nil unfortunately, as we saw with the strlcat saga. With the departure of Drepper, thin
by throwaway2048 12y ago
The chances of glibc importing openbsd derived functions are practically nil unfortunately, as we saw with the strlcat saga. With the departure of Drepper, things might have changed, but strlcat is still not imported.
- sarciszewski 12y agoWhat is the reason for that? :(
- pdw 12y agoNot specified in any standard, not much of an improvement according to the glibc maintainers, and already provided in libbsd.
- edwintorok 12y agoSpeaking of libbsd it should be updated to use ChaCha20 too: https://bugs.freedesktop.org/show_bug.cgi?id=85827 https://bugs.freedesktop.org/show_bug.cgi?id=85827
- IvyMike 12y agoDrepper's caustic style aside, his point ultimately was that truncation is still a problem. Whether or not you think glibc should include strlcat, this is an important point to understand. More discussion here: http://stackoverflow.com/q/2114896/67591 http://stackoverflow.com/q/2114896/67591
- tedunangst 12y agoNote that you can mechanically translate strcat(dst, src) to strlcat(dst, src, SIZE_MAX) with no loss of functionality or change in behavior. No worries about truncation, either. Exactly the same thing. Now, if reading a piece of code that does strlcat(dst, src, SIZE_MAX) would make you feel uncomfortable, the question is how should you feel reading code that uses strcat?
- justincormack 12y agoThings have changed enormously since Drepper left. It is a nice project to work with and many things that were vetoed are getting in.
- fafner 12y agoI don't think that's true. Drepper was against strlcat for specific reasons. And in the meanwhile the C11 standard had adopted an alternative (but imo worse) API for it, based on the Microsoft stuff. Framing this as a general rejection of APIs because they are from OpenBSD is highly disingenuous.