bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: C99, declaration after statement


From: Jim Meyering
Subject: Re: C99, declaration after statement
Date: Sat, 24 Sep 2011 15:22:03 +0200

Bruno Haible wrote:
> Hi Jim,
>
>> > About this change of fts.c from 2011-08-18.
>> > The declaration of max_entries in line 1339 comes after a statement. Not
>> > valid C99.
>>
>> s/C99/C89/
>
> Oops, yes. Not valid C89.
>
>> C89 is now more than 12 years old
>
> You meant s/C89/C99/ ?

No, I meant s/12/22/, to emphasize that C89 is now *22* years old.

>> I see so much more value in using C99's decl-after-statement feature
>
> Sure decl-after-statement is comfortable, But even without it, you can have a
> good code structure, by using braces (compound statements).

That is rarely a viable alternative.
One of the main advantages of decl-after-statement is improved
readability/maintainability.  Requiring added braces just to delimit
the reduced scope is often enough to render the code *less*
readable/maintainable than the original.  The reader will ask
themselves, "Why on earth did the author add braces here?"
Few will guess that we're trying to accommodate a standard that
is 22 years old.

>> accommodating the oh-so-few relevant compilers that still lack
>> support that I have a hard time justifying gnulib's current policy.
>
> The compilers that don't support decl-after-statement that I know of are:
>
>   - gcc 2.95 (still used in some distros, AFAIK).
>
>   - IRIX 6.5 cc
>     ("A declaration cannot appear after an executable statement in a block.")
>
>   - HP-UX 10 cc
>     ("Unexpected symbol: "int".")
>
>   - Solaris 2.6 cc
>     ("syntax error before or at: int")

I hold that the above are all museum-piece compilers.
You may still use them for portability testing,
but very few "real" users do.

>   - MSVC 9.0, also known as MS Visual Studio 2008, released in 2008
>     ("error C2143"). See also
>     
> <http://connect.microsoft.com/VisualStudio/feedback/details/485416/support-c99>
>
> IRIX is among gnulib's usual targets, and MSVC is being added now.

Portability is a worthy goal, but when such old compilers tie us
to an obsolete standard like c89, it is time to reexamine priorities.
I find it ironic that you are willing to let a flaw in MSVC influence
gnulib's coding conventions.

>> Do you still object to allowing declarations after statements in gnulib?
>
> Yes, I think if the gnulib user has the benefit of not needing to
> worry about this
> issue, it's a benefit for everyone. It's useful if we can say that all of 
> gnulib
> is working with C89.
>
>> If so, can you estimate when you will relax that stance?
>
> It depends on what machines are considered "reasonable portability targets"
> and on the compiler vendors. I guess IRIX will be dropped within 5 years,
> but MSVC support is likely to be relevant for ca. 8 years or more.

Sorry, but that is too long to wait.  IMHO, even 4 years would
be too long.  We need another solution.  See below.

>> Here is an alternative to imposing a blanket policy:
>>
>>     Allow/encourage use of C99, but heed requests for conversion to C89,
>>     if there are any.
>
> I can't agree to this. IMO the comfort for the programmer who contributes to
> gnulib is not worth the hassles to people who want to compile the package on
> IRIX or with MSVC.

I will then do what I did for a few years with coreutils:

    Manually maintain a C99-to-C89 patch for each of the few .c files
    that deserve the effort, like fts.c.
    Then, people who require C89 sources can apply the patch manually.
    Or, who knows... maybe gnulib-tool will be extended to apply the
    patch for them, say when given a --c89 option.

Thus, I have the freedom to use the newer feature, yet without
impeding those who insist on using deficient compilers.

Another file for which this would be useful is grep's dfa.[ch].
It is not currently in gnulib, but if we do migrate it, I would
not want to be constrained.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]