Re: restructure patch for review [bug-grep]

[Charles Levert]

* On Monday 2005-03-07 at 12:31:30 +0100, Claudio Fontana wrote:
> 
>  --- Charles Levert <address@hidden> ha
> scritto: 
> > * On Monday 2005-03-07 at 00:54:25 +0100, Claudio
> > Fontana wrote:
> > 
> However, note that often what seems only reformatting
> at first glance hides variable renaming for example:
> 
> if (!o.var)
> instead of
> if(!var)

Yes.  I had noticed.


> I would suggest to avoid the if (color ||
> onlymatching) big block with the gotos, which looks a
> bit confusing honestly, and replace it with a call to
> a modified prline_part, which would in turn call
> print_linehead.

I will verify that.


> Please take from this version if there is something in
> EGcompile_aux you might reuse.

Ok.  Thanks.


> lib/ should be really updated. 
> I've encountered trouble with modules 'error' (big
> trouble) and 'savedir' too.
> 
> I will post the savedir fix I have made separately
> too, until lib/ is updated.

I have noticed that some of these lib files are
not quite the same (in structure) as the glibc
(or gcc) ones.  Can some veteran of the GNU
release process shed some light on this?

Is this the result of the evolution of glibc
since a most recent snapshot, or is this the
result of a special adaptation to make them
standalone?

Is there a special GNU repository of those to
be used in the utility/replacement libraries
of specific GNU packages?  Are they kept in
synch between GNU packages?  I think that I am
referring to something different than gnulib
here, which is more utility than replacement,
right?


> Also, would it be possible to use the external
> interfaces whenever possible, relying on lib internals
> only when necessary? (posix api?) This kind of
> philosophy would make lib versions issues less
> damaging.

Yes.  I had assumed that what was in
"lib/posix/regex.h" had to be POSIX, but the
RE_* stuff just is not.  I can understand
that this is not the end of the world, though.
Using --with-included-regex is always an option
for those with a libc that is not glibc.


> To be able to set search options in grepopt.c though I
> would need an interface to your search struct
> (search.h) to set matcher, match_*, eolbyte.

Yes.  There are two possibilities here:

  -- you have direct access to the variable that
     would be of my "struct match_spec" type, or

  -- you also put them in your "struct
     grepopt" o variable and src/grep.c does
     the copying/adaptation from there to a
     "struct match_spec" variable.

The second possibility, although repetitive,
can be more flexible in that "struct
match_spec" could eventually support separate
match_words_begin and match_words_end fields
while "struct grepopt" would continue to support
only match_words because the command-line
interface (same thing for match_lines).

Maybe I should also rename "match_spec" to
"search_spec" to correspond to the file name
before even publishing a first version.


> I do not know about versioning issues, but as I
> already told Stepan in another mail, I see a priority
> in going for a heavy restructure to make grep more
> maintenable, and is what I am offering my help for.

Yes.  I support this fully, but since it can
be quite an undertaking maybe there should be
an interim 2.5.2 release just to get some known
and easy bug fixes out the door while the rest
would go in a 2.6.0 (or even a planned sequence
of 2.6.*).

In addition to our respective work, the current
Red Hat performance-enhancing patches seem to
be non-trivial as well.