Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 22 Jul 2014 01:45:16 +0200
From: John Spencer <>
Subject: Re: [PATCH] implement glibc's glob_pattern_p

Rich Felker wrote:
> On Mon, Jul 21, 2014 at 02:29:59PM +0400, Glauber Costa wrote:
>>> they seem to have copied a lot of code from musl, but
>>> never said a word about it here.. would be nice to know
>>> where they are going with it.. or why they decided to
>>> use musl in the first place
>> I am sorry about that! The decision to use musl was a very early

i was not delighted when i saw some of the musl code turned into C++ in 
the osv repo...

> No need to be sorry. I think nsz just wanted to alert you that there
> might be serious bugs that should be fixed if you're going to continue
> to use a fork. The WHATSNEW file does a pretty good job of summarizing
> important fixes in each release and could be used to find patches to
> backport.

my idea to keep a fork in tune using a semi-automated approach:

- use a comment line like // SOURCE: $MUSL/src/unistd/getpid.c in every 
file in libc/ that's copied from musl

- use a shell script that updates a musl clone and then iterates over 
the files in osv/libc, and for each file that contains SOURCE tag do 
"git log -p $MUSL/$SOURCE" to see an overview of all commits and changes 
to that file.

you could even add the commit id from which the source was imported as 
another comment to restrict the set of changes that's shown to only the 
relevant ones. after backporting changes, you could manually raise the 
commit id to the one of the corresponding musl commit.

if done like regularly, like once a month, you could probably get away 
with very little work to get all the relevant changes backported.


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.