Re: [POLL] C99, declaration after statement

[Eric Blake]

On 09/24/2011 08:26 AM, Bruno Haible wrote:
> All,
>
> 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:
http://sourceware.org/bugzilla/show_bug.cgi?id=12922#c3

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