[Top][All Lists]

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

Re: [POLL] C99, declaration after statement

From: Eric Blake
Subject: Re: [POLL] C99, declaration after statement
Date: Sat, 24 Sep 2011 10:19:07 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110906 Fedora/3.1.14-1.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.14

On 09/24/2011 08:26 AM, Bruno Haible wrote:

Jim Meyering wrote:
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.

What do the gnulib users think?

Can we have a poll?

1) Is it important for you that what you get from gnulib can be compiled
    with a C89 compiler (gcc 2.95, IRIX cc, MSVC)?

I'm thinking of the recent getopt() synchronization with glibc - Ulrich checked in a fix that required C99, and I had to intentionally alter things when synchronizing those changes back into gnulib. I proposed the same change to glibc, and Ulrich flat-out refused to consider anything older than C99, which has the potential to affect more and more of gnulib that borrows from glibc:

At this point, except for MSVC, I'm inclined to think that C99 compilers are getting quite rare, and that the people still using them are better off upgrading to newer systems or installing gcc. The fact that modern MSVC still doesn't implement declaration after statement is a big pain in all of this, but then again, MSVC is already on the fringe of what the GNU project was intending to target.

2) Is it important for you that gnulib-tool displays information about whether
    what you imported from gnulib can be compiled with a C89 compiler?

It might be worth an annotation in each module that wants to take advantage of C99 features, so that we can then use gnulib-tool to compute transitive closure of what features are required (just as we can compute transitive closure of which modules are LGPLv2+ vs. GPLv3+, and report conflicts if a module declares itself one way but depends on other modules that are declared the other way). That is, it might be nice to have modules default to C89, be marked if they require C99, and to have gnulib-tool warn if an unmarked C89 module ends up depending on a C99 module.

3) Is it important for you that you can tell gnulib-tool whether it should
    accept or reject to import code from gnulib that cannot be compiled with
    a C89 compiler?

Not for any of the projects that I maintain. m4 can still be compiled with C89, but requiring C99 for the next m4 release is no longer a show-stopper in my mind. libvirt already requires C99 (and for lots more than just declaration-after-statement).

Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

reply via email to

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