Re: [PATCH] Implement strlcpy, strlcat [BZ #178]

[Carlos O'Donell <carlos at redhat dot com>]

On 09/26/2016 11:59 PM, Guillem Jover wrote:
> Florian, you mention you'd like to see libbsd disappear, due to lots of
> other gross things in there. Given what I've seen around, I think that
> would make the situation worse. I'd rather improve the stuff in libbsd,
> and switch more projects to it. Besides fgetln() and fgetwln() what else
> do you take issues with? I'm happy to fix, improve or deprecate things
> that are broken, either by myself or by accepting patches!

I find the functions in libbsd are not well integrated into the kernel and
core libraries, and that leaves much to be desired from a QoI perspective,
so much so that other libraries sometimes roll their own because they don't
like the tradeoffs in libbsd. This has nothing to do with the quality of
libbsd itself, just that some things _can't_ be implemented or integrated
well in userspace. The most recent example of this I worked on was
setproctitle.

There should be no setproctitle in userspace, we need a kernel syscall to
support it properly, and once there is a syscall it's relatively easy to
add it to glibc given the infrastructure we have. We don't add it to glibc
because until we can actually implement it, the solutions I've seen do more
harm than good (debugging breakage due to env hacking) on Linux.

Once setproctitle is a syscall, then we _should_ implement a wrapper in glibc
(thought this follows on the Linux syscall wrapper consensus discussion).

>>> The Fedora bug report that corresponds to strlcpy/strlcat
>>> fortification[2] says that this is "Priority low Severity low", and from
>>> the above it appears that this is mainly a packaging problem instead of
>>> being a necessary addition to the core libc API.
>>
>> We did not invest in libbsd development because the right place to offer
>> widely-implemented libc APIs in Fedora is glibc.
> 
> As Paul has mentioned, not all BSD interfaces might be acceptable for
> glibc, and I think libbsd is the proper place for those.

This specific discussion is about strlcpy/strlcat, which I believe should
be implemented in libc proper because of their wide use.

-- 
Cheers,
Carlos.