Eric Blake wrote:
> Are there any implementations
> of malloc/realloc where malloc(0) does not return dereferencable memory at
> least sizeof(gid_t) in length?
Sure. The malloc in ElectricFence. With it, malloc(0) = malloc(1) returns a
single byte at the end of a memory page, with the next memory
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 12/9/2009 2:31 AM:
>> + {
>> +gid_t first = *g;
>
> This code will do an invalid memory access if ng == 0 (which can happen if
> gid == (gid_t) -1 and getgroups or getugroups does not find a gid).
Good catch. And I
Hi Eric,
> + /* Reduce the number of duplicates. On some systems, getgroups
> + returns the effective gid twice: once as the first element, and
> + once in its position within the supplementary groups. On other
> + systems, getgroups does not return the effective gid at all,
> +
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 12/4/2009 7:55 PM:
> Good thinking. I've pushed the first two, and here's a respin of the
> third for further review.
No further comment, so I've pushed the third patch; mgetgroups now ignores
trivial duplicates.
- --
Don'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Pádraig Brady on 12/4/2009 7:14 PM:
>>> Why does the first element get extra checks.
>>> Is it more likely to be duplicated?
>> Yes, for two reasons. One, we pre-insert an arbitrary gid_t to the front..
>> Two, some OS's actually list the
Eric Blake wrote:
> According to Pádraig Brady on 12/4/2009 6:20 PM:
>>> + /* Remove pair-wise duplicates, as well as any duplicate of the
>> ? + first element. Rather than do a full O(n log n) duplicate
>>> + removal, this only visits the most common duplicates. */
>> Why does the first
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Pádraig Brady on 12/4/2009 6:20 PM:
>> + /* Remove pair-wise duplicates, as well as any duplicate of the
> ? + first element. Rather than do a full O(n log n) duplicate
>> + removal, this only visits the most common duplicates.
Eric Blake wrote:
> The first was a bug I introduced when moving mgetgroups from coreutils to
> gnulib (comparing a gid_t with -1 will fail on platforms where gid_t is
> uint16_t; the coreutils version only used the gid argument in the getugroups
> case, so the bug came from my new code for the
The first was a bug I introduced when moving mgetgroups from coreutils to
gnulib (comparing a gid_t with -1 will fail on platforms where gid_t is
uint16_t; the coreutils version only used the gid argument in the getugroups
case, so the bug came from my new code for the getgroups case). I didn't
