Re: Question about some fields in regex's re_pattern_buffer

I attach a patch-set which performs all my promised tidy-up of regex.texi, with the exception of the removal of POSIX documentation, which I will submit later. Note that this set supercedes the previous two patches I supplied: to be precise, the second patch has changed slightly, as I found a typo

Re: Question about some fields in regex's re_pattern_buffer

On 18 August 2010 12:51, Paolo Bonzini wrote: > We have been very strict in adding extensions to the POSIX APIs > (basically only REG_STARTEND). Right, whereas in other parts of the GNU APIs there are rather more liberal additions (just grep the man pages for _GNU_SOURCE). What's the reason not t

Re: Question about some fields in regex's re_pattern_buffer

On Wed, Aug 18, 2010 at 12:36, Reuben Thomas wrote: > On 18 August 2010 08:52, Paolo Bonzini wrote: >> Syntax options are anyway not going to be supported by the POSIX API, > > That's why I mentioned extensions. glibc has many GNU extensions to > POSIX APIs, both in the form of extended semantics

Re: Question about some fields in regex's re_pattern_buffer

On 18 August 2010 08:52, Paolo Bonzini wrote: > Syntax options are anyway not going to be supported by the POSIX API, That's why I mentioned extensions. glibc has many GNU extensions to POSIX APIs, both in the form of extended semantics of existing APIs and new-but-similar APIs; I was wondering w

Re: Question about some fields in regex's re_pattern_buffer

On Tue, Aug 17, 2010 at 19:54, Reuben Thomas wrote: > However, this does raise a more general point, namely the wisdom of > spending effort maintaining the GNU API, rather than extending the > POSIX API where it is deficient with respect to the GNU API. The cost > of maintaining the GNU is relativ

Re: Question about some fields in regex's re_pattern_buffer

3. "@comment xx something about leftmost-longest": I found this comment in the section "Alternation Operator". Since there is already a paragraph about leftmost-longest matching in general ("What Gets Matched?"), what was intended here? Probably we wrote the xx comment before writi

Re: Question about some fields in regex's re_pattern_buffer

On 15 August 2010 14:45, Paolo Bonzini wrote: > > The non-thread-safety isn't only for RE_NO_SUB, but for all syntax options. >  RE_NO_SUB makes it worse only because it is _not_ a syntax option, but a > setting to provide improved matching speed. > > I think RE_NO_SUB should be documented, and a

Re: Question about some fields in regex's re_pattern_buffer

On 14 August 2010 23:15, Bruno Haible wrote: > Reuben Thomas wrote: >> New patch attached. > > I've applied it for you. Thanks again. Reading further, I came up with the following: 1. I believe the @ignored section about RE_NO_EMPTY_ALTS can be removed, as it no longer exists. 2. Equivalence c

Re: Question about some fields in regex's re_pattern_buffer

On 08/14/2010 02:48 PM, Bruno Haible wrote: > re_set_registers is not documented; there's a note about this. I'd be > happy to write some documentation for that. There's also the technique > of re-using a registers data structure by NOT re_compile_fastmap, but > using the fastmap member of th

Re: Question about some fields in regex's re_pattern_buffer

Reuben Thomas wrote: > New patch attached. I've applied it for you. Bruno

Re: Question about some fields in regex's re_pattern_buffer

On 14 August 2010 19:48, Bruno Haible wrote: > Reuben Thomas wrote: >> In the end I found very little to change on a first look. The attached patch: >> >> 1. Removes mentions of regex.c. > > I've committed this part for you. > >> 2. Adds documentation of not_eol. > > I haven't committed this part,

Re: Question about some fields in regex's re_pattern_buffer

re_set_registers is not documented; there's a note about this. I'd be happy to write some documentation for that. I see no reason not to. I don't know why we never got to it. There's also the technique of re-using a registers data structure by NOT re_compile_fastmap, but using t

Re: Question about some fields in regex's re_pattern_buffer

Reuben Thomas wrote: > In the end I found very little to change on a first look. The attached patch: > > 1. Removes mentions of regex.c. I've committed this part for you. > 2. Adds documentation of not_eol. I haven't committed this part, because you added a paragraph about not_eol in the sectio

Re: Question about some fields in regex's re_pattern_buffer

On 3 August 2010 23:21, Bruno Haible wrote: > Feel free to submit a patch that Eric or Karl or I can apply. In the end I found very little to change on a first look. The attached patch: 1. Removes mentions of regex.c. 2. Adds documentation of not_eol. The other questions which I asked are most

Re: Question about some fields in regex's re_pattern_buffer

On 4 August 2010 00:17, Karl Berry wrote: > >    two real arguments in favour >    of regex.texi are: >      - It less Makefile rules to use it directly, and regex.h changes rarely >        enough. > > These days, I agree with that.  I think the simplicity of having the doc > not be generated outw

Re: Question about some fields in regex's re_pattern_buffer

two real arguments in favour of regex.texi are: - It less Makefile rules to use it directly, and regex.h changes rarely enough. These days, I agree with that. I think the simplicity of having the doc not be generated outweighs the automatic sync-ing. (Back in time, Kathy an

Re: Question about some fields in regex's re_pattern_buffer

[resent because the gnu.org mail server was not working right for a short while yesterday] Hello Reuben, Paolo Bonzini wrote: > But Bruno is the doc guru. Actually, Karl is in a much better position to comment here: He is the doc guru, and he wrote part of the regex manual himself. > The first

Re: Question about some fields in regex's re_pattern_buffer

OK, I took a look. The first thing that caught my eye is the mention of "regex.c". This can be expunged, as the gnulib or glibc user doesn't need to know what shape the source is (and it's out of date). This led me to two other things which I need feedback on before I can proceed further: 1. You

Re: Question about some fields in regex's re_pattern_buffer

Thanks very much Bruno; I will try to read over the bits corresponding to my recent corrections to regex.h very shortly.

Re: Question about some fields in regex's re_pattern_buffer

Reuben Thomas wrote: > I mean the manual from the old GNU regex distribution at: > http://ftp.gnu.org/old-gnu/regex/regex-0.12.tar.gz > which documents the GNU API. Paolo Bonzini wrote: > A chapter maybe. But Bruno is the doc guru. I think it makes sense to move this doc to gnulib, since it is a

Re: Question about some fields in regex's re_pattern_buffer

These errors all occur in regex 0.12, i.e. have been in regex.h for at least 18 years! That's rather sad. Hopefully I can prevent their lasting much longer...

Re: Question about some fields in regex's re_pattern_buffer

On 30 July 2010 19:37, Paolo Bonzini wrote: > On 07/30/2010 08:35 PM, Reuben Thomas wrote: >> >> So am I right in concluding that the comment for REG_NEWLINE in >> regex.h is the wrong way around? > > Yes. Thanks, I will update the patch for the bug I submitted to glibc earlier. -- http://rrt.s

Re: Question about some fields in regex's re_pattern_buffer

On 07/30/2010 08:35 PM, Reuben Thomas wrote: So am I right in concluding that the comment for REG_NEWLINE in regex.h is the wrong way around? Yes. Paolo

Re: Question about some fields in regex's re_pattern_buffer

On 30 July 2010 13:06, Paolo Bonzini wrote: > A chapter maybe.  But Bruno is the doc guru. Thanks. While waiting for Bruno to say what he'd like, one more question: in regex.h there's the documentation: /* If this bit is set, then anchors do not match at newline characters in the string.

Re: Question about some fields in regex's re_pattern_buffer

On 07/30/2010 01:09 PM, Reuben Thomas wrote: On 30 July 2010 12:02, Paolo Bonzini wrote: I think that's gone at the moment. Your options are to add it to glibc (harder) or to add it the gnulib manual. The latter not optimal, but it could be good enough for now. I have made enquiries to glib

Re: Question about some fields in regex's re_pattern_buffer

On 30 July 2010 12:02, Paolo Bonzini wrote: > I think that's gone at the moment.  Your options are to add it to glibc > (harder) or to add it the gnulib manual.  The latter not optimal, but it > could be good enough for now. I have made enquiries to glibc, but as you say, it's harder, so I'd be h

Re: Question about some fields in regex's re_pattern_buffer

On 07/30/2010 01:01 PM, Reuben Thomas wrote: On 30 July 2010 11:50, Paolo Bonzini wrote: On 07/30/2010 11:33 AM, Reuben Thomas wrote: I have submitted a bug report with patch at http://sourceware.org/bugzilla/show_bug.cgi?id=11857 This addresses regex.h, but doesn't address the texinfo manu

Re: Question about some fields in regex's re_pattern_buffer

On 30 July 2010 11:50, Paolo Bonzini wrote: > On 07/30/2010 11:33 AM, Reuben Thomas wrote: >> >> I have submitted a bug report with patch at >> >> http://sourceware.org/bugzilla/show_bug.cgi?id=11857 >> >> This addresses regex.h, but doesn't address the texinfo manual. >> Unfortunately the texinfo

Re: Question about some fields in regex's re_pattern_buffer

On 07/30/2010 11:33 AM, Reuben Thomas wrote: I have submitted a bug report with patch at http://sourceware.org/bugzilla/show_bug.cgi?id=11857 This addresses regex.h, but doesn't address the texinfo manual. Unfortunately the texinfo manual is not currently shipped with glibc. I have written to l

Re: Question about some fields in regex's re_pattern_buffer

On 29 July 2010 23:18, Reuben Thomas wrote: > On 29 July 2010 23:14, Bruno Haible wrote: >> Reuben Thomas wrote: >>> Thanks. I guess I should report this documentation bug somewhere, but >>> where? (As mentioned in a recent message to this list, I've not had >>> much mileage from reporting simila

Re: Question about some fields in regex's re_pattern_buffer

On 29 July 2010 23:14, Bruno Haible wrote: > Reuben Thomas wrote: >> Thanks. I guess I should report this documentation bug somewhere, but >> where? (As mentioned in a recent message to this list, I've not had >> much mileage from reporting similar things to glibc in the past.) > > The place to re

Re: Question about some fields in regex's re_pattern_buffer

Reuben Thomas wrote: > Thanks. I guess I should report this documentation bug somewhere, but > where? (As mentioned in a recent message to this list, I've not had > much mileage from reporting similar things to glibc in the past.) The place to report it is glibc bugzilla

Re: Question about some fields in regex's re_pattern_buffer

On 29 July 2010 20:25, Bruno Haible wrote: > Reuben Thomas wrote: >> /* This data structure represents a compiled pattern.  Before calling >>    the pattern compiler, the fields `buffer', `allocated', `fastmap', >>    `translate', and `no_sub' can be set.  After the pattern has been >>    compiled

Re: Question about some fields in regex's re_pattern_buffer

Reuben Thomas wrote: > /* This data structure represents a compiled pattern.  Before calling >    the pattern compiler, the fields `buffer', `allocated', `fastmap', >    `translate', and `no_sub' can be set.  After the pattern has been >    compiled, the `re_nsub' field is available.  All other fie

Question about some fields in regex's re_pattern_buffer

(Thanks for helping with my last question; here's another:) re_pattern_buffer contains the following three fields: /* If set, a beginning-of-line anchor doesn't match at the beginning of the string. */ unsigned __REPB_PREFIX(not_bol) : 1; /* Similarly for an end-of-line anchor. */