On 31 March 2010 15:48, Jim Meyering <[email protected]> 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
