This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: If glibc had a logo what would it be?


Hello,

On Sat, Dec 8, 2012 at 11:13 PM, Andrew Pinski <pinskia@gmail.com> wrote:
> On Sat, Dec 8, 2012 at 9:04 PM, William Pitcock
> <nenolod@dereferenced.org> wrote:
>> Hello,
>>
>> On Sat, Dec 8, 2012 at 5:52 PM, David Miller <davem@davemloft.net> wrote:
>>> From: William Pitcock <nenolod@dereferenced.org>
>>> Date: Sat, 8 Dec 2012 14:04:19 -0600
>>>
>>>> Hello,
>>>>
>>>> On Sat, Dec 8, 2012 at 8:55 AM, Carlos O'Donell <carlos@systemhalted.org> wrote:
>>>>>
>>>>> If glibc had a logo what would it be?
>>>>
>>>> Honestly, I think that it would be better to spend time on integrating
>>>> strlcpy() and strlcat() so that a billion programs don't have to carry
>>>> stubs for them anymore due to GNU arrogance than making a logo.
>>>>
>>>> I also generally don't see the point in having a logo for a C library;
>>>> logos make sense for GUI apps, which a C library is not.
>>>
>>> Wake up on the wrong side of the bed today?
>>
>> No.  The arrogance is very well-documented.
>>
>> If you want to "build a community of people who like GLIBC" - making
>> it where GLIBC is not the odd duckling for downstream developers (you
>> know, the people who write the code that GLIBC exists to run?) would
>> be a great start to improving the perception of GLIBC amongst
>> developers downstream of it.
>>
>> I will be more than happy to submit patches adding strlcpy/strlcat, if
>> people will accept them, but it seems a giant waste of time, because
>> someone will surely say "we don't like this" or whatever.  Well, guess
>> what?  Nobody likes the alternatives proposed by the GLIBC maintainers
>> every time this is discussed, so perhaps the functions should be added
>> now instead of coming up with crappy reasons to avoid doing so.
>
> Post a patch then :).  Also see the FAQ which describe why they are
> not a good idea and an even better alternative:
> http://sourceware.org/glibc/wiki/FAQ#Why_no_strlcpy_.2BAC8_strlcat.3F

Why would I bother posting a patch when you have already attached a
talking point to it to explain why it is in the opinion of the GLIBC
maintainers a bad set of functions?

While I agree that FORTIFY is a better approach (or some other
mechanism which semantically tests for correctness at compile-time),
this does not solve the problem that thousands of apps have to ship
strlcpy() stubs just to work around the fact that the GLIBC
maintainers will not include support for them.  Infact, you have gone
to more work writing the FAQ entry than it would be to just integrate
the functions into GLIBC.

Have you considered the security implications of applications using a
broken strlcpy() stub?  Do you not agree that adding the functionality
to GLIBC would cut down on broken stubs being distributed? (There is a
strlcpy() in Linux, which does not have equivalent behavior to the BSD
one.  Specifically, it's broken.)

William


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]