On 09/09/2010 08:44 AM, Paolo Bonzini wrote:
> The glibc bug at http://sourceware.org/bugzilla/show_bug.cgi?id=5945
> says "This is known but obviously cannot easily be fixed. Suspended
> until somebody takes this serious to actually take a stab at a solution".
>
> I guess that counts as "patche
On 09/09/2010 05:24 PM, Bruno Haible wrote:
This would make no sense to me.
I know, I'm trying to be pragmatic. I prefer a gigabyte-crippled grep
than a feature-crippled grep.
It would be better to push the glibc people so that they offer some
preprocessor macro that makes regoff_t 64-bit
Eric,
> But you are right that on x86_64 glibc, we have:
> (gdb) p sizeof(regoff_t)
> $1 = 4
> (gdb) p sizeof(off_t)
> $2 = 8
> (gdb) p sizeof(ssize_t)
> $3 = 8
> (gdb) p sizeof(ptrdiff_t)
> $4 = 8
>
> Should we go back to the Austin Group to further relax the requirements
> on regoff_t to only
On 09/09/2010 05:04 PM, Eric Blake wrote:
Hmm - here's the current POSIX 2008 wording:
http://www.opengroup.org/onlinepubs/9699919799/basedefs/regex.h.html#tag_13_38
The header shall define the regoff_t type as a signed integer
type that can hold the largest value that can be stored in eit
On 09/09/2010 02:18 AM, Paolo Bonzini wrote:
The included regex cannot support equivalence classes and multibyte
collation symbols properly. On the other hand it supports 64-bit
regoff_t, which glibc cannot provide without breaking the ABI.
We currently favor the latter, but this is no longer co
