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
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 correct since
there's clearly no hope of ever pas
