At Wed, 23 Oct 2013 11:08:48 +0100,
Eric Blake wrote:
On 10/23/2013 11:02 AM, Claudio Bley wrote:
>>> Seems \s is buggy in this grep version with a non UTF-8 locale
>>> setting. Observe:
>>>
>>> $ LANG=en_US.UTF-8 grep -nE '\<(int|unsigned) ([^(]*
)*(i|j|k)(\s|,|;)' src/conf/interface_conf.h
>>> $ LANG=C grep -nE '\<(int|unsigned) ([^(]* )*(i|j|k)(\s|,|;)'
src/conf/interface_conf.h
>>
>> But 'syntax-check' should be already using grep in the C locale (if
not,
>> that's a bug upstream in gnulib).
>
> But that's the point, the bug manifests itself with LANG=C, NOT with
> LANG=*.UTF-8
Ah, I see - the bug in RHEL 5 grep is in LANG=C.
>>>
>>> So, I think the right fix would be to avoid \s altogether and use
>>> [[:space:]] instead.
>>
>> The \s usage was good enough to work around the grep bug
>
> I'm confused. Which bug are you talking about?
Oops, I typed one thing but meant another:
the \> fix (that Martin has already pushed) is all the more we need to
work around the RHEL 5 grep.
Well, since nobody knows what \s actually does to the state of the
grep matcher, you can't be sure. Fact is, however, it avoids the
syntax-check errors.
> So, what does \s match with, when using LANG=C ?
It's supposed to match space, but that's a problem for the RHEL 5 team
to answer.
Particularly when considering the other usages of \s throughout the
code base...
Claudio
--
AV-Test GmbH, Henricistraße 20, 04155 Leipzig, Germany
Phone: +49 341 265 310 19
Web:<http://www.av-test.org>
Eingetragen am / Registered at: Amtsgericht Stendal (HRB 114076)
Geschaeftsfuehrer (CEO): Andreas Marx, Guido Habicht, Maik Morgenstern