[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 15 Oct 2014 21:03:06 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: regcomp regression?
On Wed, Oct 15, 2014 at 04:01:25PM -0500, Samuel Holland wrote:
> Hello,
>
> I've been rebuilding packages after the 1.1.5 release, and it's caused
> some (apparent) regressions. file no longer compiles as it is unable to
> parse one of its magic files. The offending regex is (windows, line 163)
>
> \\`(\r\n|;|[[]|\xFF\xFE)
>
> It's testing for the BOM at the beginning of an INI/INF file. I
> understand the regex rewrite removed[1] the ability to match arbitrary
> bytes (even with the C locale) because it was broken; is this something
> you plan to add back? Or is the application wrong? If so, what
> workaround do you suggest?
It was not supported before either; it was just silently misprocessed
as if the regex were:
\\`(\r\n|;|[[]|)
Obviously this was undesirable. The fixes made to the parser caught
this bug. I think there's a patch for file upstream already, but it
does not really fix the bug; it just makes the symptom go away again.
The problem is that they're attempting to use regex to process binary
data, which is not a valid usage.
If we add the controversial byte-based C locale that's been discussed,
this could be made to work, but that's still an open question whether
it will be done. It adds a good deal of ugliness and code duplication
to the codebase.
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.
