[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130221013417.GO20323@brightrain.aerifal.cx>
Date: Wed, 20 Feb 2013 20:34:17 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: strcasestr.c
On Wed, Feb 20, 2013 at 08:30:54PM -0500, Kurt H Maier wrote:
> On Wed, Feb 20, 2013 at 08:03:28PM -0500, Rich Felker wrote:
> >
> > The other somewhat reasonable option would be removing the function,
> > which would expose breakage in programs that were already using the
> > broken version in musl. I'm mildly against this, but I'd be interested
> > in hearing arguments either way.
>
> Please remove it. It's not world-ending to ask people to relink;
> programs known to require the broken functionality can run against an
> older version of musl until they're repaired. If you start enshrining
> mistakes now you're just driving down glibc avenue. I'd rather have
> musl be a correct libc than a quirky libc.
Well the other issue is using glibc-linked binaries/libs. If any of
them reference strcasestr (which they might in all those gnulib
packages mentioned earlier in this thread once gnulib detects that
glibc has its own strcasestr...), then we'd potentially want to
provide strcasestr to be able to use them..
I don't think "enshrining mistakes" is a good policy in itself, but if
they can be fixed (unbreaking the function) in ways that have other
practical benefits, that might be a better alternative.
With that said, opinion #1 noted. :)
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
