On Jul 22 11:17, Eric Blake wrote:
> On 07/22/2013 02:12 AM, Corinna Vinschen wrote:
>
> >>> However, please note that this behaviour, while being provided by glibc
> >>> and now by Cygwin, is *not* standards-compliant. In the narrow sense
> >>> the characters beyond 0x7f are still invalid ASCII
On 07/22/2013 02:12 AM, Corinna Vinschen wrote:
>>> However, please note that this behaviour, while being provided by glibc
>>> and now by Cygwin, is *not* standards-compliant. In the narrow sense
>>> the characters beyond 0x7f are still invalid ASCII chars, and other
>>> functions working with w
On Jul 21 22:59, Mark Levedahl wrote:
> On 07/21/2013 03:39 PM, Corinna Vinschen wrote:
>
> >So, what I did now was this: I added a workaround to Cygwin's regcomp.
> >If the current codeset is ASCII, the characters in the pattern are
> >converted to wchar_t by simply using their unsigned value ve
On 07/21/2013 03:39 PM, Corinna Vinschen wrote:
So, what I did now was this: I added a workaround to Cygwin's regcomp.
If the current codeset is ASCII, the characters in the pattern are
converted to wchar_t by simply using their unsigned value verbatim.
This allows to compile (and test) the pat
On Jul 20 15:52, Mark Levedahl wrote:
> Current git fails two sets of tests on cygwin due apparently to
> problems in the regex library. One set of tests does language based
> word-matching, and has a common failure during regex compilation.
> The suffix clause ("|[^[:space:]]|[\xc0-\xff][\x80-\xbf
Current git fails two sets of tests on cygwin due apparently to problems
in the regex library. One set of tests does language based
word-matching, and has a common failure during regex compilation. The
suffix clause ("|[^[:space:]]|[\xc0-\xff][\x80-\xbf]+") is common to all
of these, removing t
6 matches
Mail list logo
