[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Inaccurate description of configure option --without-included-regex
From: |
Jim Meyering |
Subject: |
Re: Inaccurate description of configure option --without-included-regex |
Date: |
Tue, 17 Mar 2009 15:21:56 +0100 |
Reuben Thomas wrote:
> The documentation says:
>
> --without-included-regex
> don't compile regex; this is the default on 32-bit
> systems with recent-enough versions of the GNU C
> Library (use with caution on other systems). On
> systems with 64-bit ptrdiff_t and 32-bit int,
> --with-included-regex is the default, in case regex
> functions operate on very long strings (>2GB)
>
> which surprised me, as it implied that glibc is still broken on 64-bit
> systems. Fortunately, the code is more reassuring; in regex.m4 is the
> following comment:
>
> /* Reject hosts whose regoff_t values are too narrow.
> These include glibc 2.3.5 on hosts with 64-bit ptrdiff_t
> and 32-bit int. */
>
> I suggest that the documentation be changed to read:
>
> --without-included-regex
> don't compile regex; this is the default on systems
> with recent-enough versions of the GNU C Library
> (use with caution on other systems).
>
> I do not suggest replacing the old technical explanation with the new,
> as that will merely lead to future bugs of the same sort by
> duplicating the reasoning. The output of configure options is not a
> good place for detailed technical explanation in any case.
Thanks. That sounds like a fine improvement.
Do you feel like writing a commit-log/ChangeLog entry, too?
(i.e., git format-patch output, per e.g.,
http://git.sv.gnu.org/cgit/coreutils.git/plain/HACKING)
Then I can just run "git am your-patch" and push the result.