Re: Fwd: Re: [Platform-testers] new snapshot available: coreutils-8.12.178-df9cd

[Markus Duft]

On 09/07/11 16:13, Jim Meyering wrote:
> Markus Duft wrote:
> ...
[snip]
>> also, one more thing i saw from the gentoo ebuilds: we're adding those
>> to CFLAGS for building, as otherwise "id" will be dead slow on
>> domain-controlled windows machines:
>>  -Dgetgrgid=getgrgid_nomembers -Dgetgrent=getgrent_nomembers
>> -Dgetgrnam=getgrnam_nomembers
> 
> It would help a lot if you would give more detail, if possible,
> like why the new version is more efficient, and what (if any)
> is the resulting difference in semantics?

those functions behave exactly like their non-_nomembers counterparts, except, 
that they don't fetch _all_ group members from the domain controller. in my 
case for example, we have > 300 users in the domain, which makes each call to 
the normal versions take > 3 seconds. i'd suggest a test for those in 
configure, and if they exist, use them. i'm unsure on how such a test could 
look like though, my m4-foo is not strong enough ;)

> 
[snip - setgroups patch]
> 
> Does Interix really lack this capability?
> 

sad but true ...

> If so, I would rather something like this, that adds a
> dummy, always-successful setgroups function.
> (maybe also "using" the parameters)

mhm. new patch attached.

> 
[snip]
>>
>> +#ifdef __INTERIX
>> +// very very broken long double "support".
> 
> Thanks for the suggested patch, but what problem are you working around?
> Is this due to insufficient compiler support?  Use a newer gcc?
> Insufficient library support?  If that's it, then won't one of the
> gnulib's replacement functions work for you?

gcc is 4.2.4 and there is no chance to get a newer one to work currently (i 
have big problems forward porting my patches). but i /think/ it's the library 
support anyway thats broken. it seems to be somewhere in the printing (fprintf, 
sprintf). if i run an unpatched "seq 1 10", i get this:

mduft coreutils-8.12.193-d8dc8 $ ./src/seq 1 10
0
0
-2
0
-0
-2
-26815615859885194199148049996411692254958731641184786755447122887443528060147093953603748596333806855380063716372972101707507765623893139892867298012168192
0
-0
-0

in [1], Bruno Haible suggested some test from the gnulib test-suite, with which 
i can investigate the problem more deeply, which i'm now doing (as time allows).

[1] http://lists.gnu.org/archive/html/bug-gnulib/2011-06/msg00136.html

regards, Markus

> 
> I'm very reluctant to replace every use of "long double" with a made-up
> type like dblmax_t only for Interix when there is so little justification.
> 
>> +typedef double dblmax_t;
>> +# define xstrtod_max xstrtod
>> +# define c_strtod_max c_strtod
>> +# define dblmax_fmt_f "f"
>> +# define dblmax_fmt_g "g"
>> +#else
>> +typedef long double dblmax_t;
>> +# define xstrtod_max xstrtold
>> +# define c_strtod_max c_strtold
>> +# define dblmax_fmt_f "gf"
>> +# define dblmax_fmt_g "Lg"
>> +#endif

chroot-setgroups.patch
Description: Text Data