Re: Inaccurate description of configure option --without-included-regex

[Jim Meyering]

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.