Re: dfa.c fix for C89 compilers

[Reuben Thomas]

On 31 March 2010 15:48, Jim Meyering <address@hidden> wrote:
> Thanks, but I have to refuse such changes, especially in the likes
> of dfa.c.  They decrease readability.  It is already too complex,
> and as soon as grep stabilizes (i.e. goes a week or so without a new bug
> report) I plan to move many more declarations "down", along with other
> clean-up and maintainability- and readability-improving changes.
>
> I moved coreutils away from strict c89 compliance
> with the introduction of such declare-after-stmt uses about 3 years
> ago.  Since then, there have been very few complaints, and most of
> those were out of laziness in using long-out-of-date compilers and
> not having the time to build/install gcc.
>
> c89 is now 21 years old.

It is a pity that making grep non-C89 was not announced, as it is an
important change: many older systems don't have a C99 compiler as
standard, and building GCC is non-trivial, and more thankless when you
discover that you have to build an out-of-date version because the
latest doesn't support your old system. The point about C89's age is
irrelevant; what is important is how well and widely C99 is
implemented, which, to put it mildly, depends on your perspective.
(Even GCC doesn't fully implement it, though thankfully the holes are
now pretty small and esoteric.) Making a program require C99,
therefore, relegates it to mainstream, modern systems.

However, I'm inclined to agree with Jim in this case, because GNU grep
is, for non-GNU systems, merely an enhancement to a standard tool, nor
is it needed by autotools to build further programs. Given that
"mainstream, modern systems" account for the vast majority of our
users, it seems to me much more worth spending maintainer effort on
improving grep for them, and in particular, those for whom GNU grep is
their system grep, that is, GNU users, who are just now starting to
benefit from its getting some serious attention for the first time in
a few years.

FWIW I have kept GNU Zile C89-compatible simply to make it more
portable, as it is not a standard utility (it's a cut-down version of
Emacs), and have not found it to be a significant problem: one can
always insert an extra block if declarations near use are really
desired, but in my case I've always found that code sufficiently long
to benefit is more improved by decomposition into more functions. It
builds on a huge array of systems, some of considerable antiquity,
which is nice, but this took significant effort to achieve, and
continues to require significant effort to maintain. For Zile, this
makes sense: it's designed specifically for use cases in which Emacs
isn't suitable, but this clearly doesn't apply to grep.

-- 
http://rrt.sc3d.org