[augeas-devel] Weird print result with Perl bindings on amd64

[David Lutterkort]

On Wed, 2009-01-14 at 19:04 +0100, Dominique Dumont wrote:
> David Lutterkort <lutter at redhat.com> writes:
> 
> >> Actually, after much tinkering with sshd lens, I have the gut feeling
> >> that the problem is in the key_re lens. Looks like the '-' operator
> >> between the 2 regex is not working properly.
> >
> > At first, that was my suspicion, too, but the regular expressions that
> > are used for matching are identical, and I can see in the debugger that
> > the regex matcher produces different results.
> 
> I'm not sure that I follow you.
> 
> IMHO, the suspect lens is 
> 
>    let key_re = /[A-Za-z0-9]+/
>          - /MACs|Match|AcceptEnv|Subsystem|(Allow|Deny)(Groups|Users)/
> 
> The regex before and after the '-' are not identical ?? [ puzzled ]
> 
> So, what do you mean by "the regular expressions that are used for
> matching are identical" ?

Oh .. what I meant was: I checked with gdb what is happening behind the
scenes when the sshd lens is run on your example sshd_config, both
running it with augtool and with your Perl example.

In both cases, the regexp that is fed to re_match[1] is exactly the
same, but the results of matching are different.

> On my side, I've tinkered a lot the regex on the right side and never
> managed to have an effect. Even
> 
>   let key_re = /[A-Za-z0-9]+/ - "Match" 
> 
> does not work. Hence the suspicion regarding the '-'

It does not appear that the '-' is the problem. When you compute the
regexp for the above, you get

        /Match[0-9A-Za-z][0-9A-Za-z]*|Matc([0-9A-Za-gi-z][0-9A-Za-z]*|())|Mat([0-9A-Zabd-z][0-9A-Za-z]*|())|Ma([0-9A-Za-su-z][0-9A-Za-z]*|())|(M[0-9A-Zb-z]|[0-9A-LN-Za-z][0-9A-Za-z])[0-9A-Za-z]*|M|[0-9A-LN-Za-z]/
        
which is correct.

> (which will leas to a call to qsort BTW). [ ok I may be wrong ]

The qsorts in fa.c are not an issue since the comparison routines they
use ignore locales - this is also why augtool/augparse do not exhibit
this behavior: they ignore your LC_* env variables and stick with the C
locale.

> >> > It's not clear to me what causes the different behaviors; it seems
> >> > Perl is doing something with locale setup beyond what glibc does,
> >> > otherwise augtool should produce the same strange result with
> >> > LANG=en_US, but it doesn't.
> >> 
> >> Yes, and there's still the fact that the problem cannot be reproduced
> >> (so far) on a 32 bits arch. 
> >
> > What have you tried to reproduce this on 32bit ? And with what LC_*/LANG
> > vars ?
> 
> Yes. 32 bits has *always* worked whatever LC_*/LANG I set (by default,
> LANG is en_US with utf8). I can provide a more detailed report if you
> want.

I can reproduce these problems with augparse/augtool if I stick a
'setlocale(LC_ALL, "")' into their main, thus making them obey the LC_*
env vars - why that would be architecture specific though is beyond me.

David

[1] http://www.delorie.com/gnu/docs/regex/regex_47.html