Re: Drop the K&R requirement from binutils?

[Jim Wilson <wilson at redhat dot com>]

>I don't think the binutils project should become a political tool as
>part of an argument within the gcc project.  That makes no sense.

That is certainly a reasonable position.  I think it is important for people
to realize that this is more a political problem than a technical one.
There haven't been any good technical arguments for continuing to use K&R C
in gcc.  The reason we continue to use K&R C is because of politics.

On the political side, it would be useful if binutils maintainers expressed
an opinion, even if they want gcc to switch first.  We don't want to get
deadlocked where gcc can't switch because they think the binutils maintainers
want to continue using K&R C, and binutils can't switch because they think
the gcc maintainers want to continue using K&R C.

On the technical side, it is interesting to note that the current gcc sources
no longer support K&R C as an input language.  This will go out as part of
the next major gcc release, e.g. gcc-3.3.  We still have K&R C preprocessor
support for programs like imake, and we still have a -Wtraditional option,
but there is no longer any -traditional option, and hence no way to tell gcc
that the input is K&R C.  And yet we still use K&R C to write gcc, or more
properly the common subset of K&R C and ISO C90.

Another point, is that while we claim to be using K&R C, so few people have
access to K&R C compilers anymore that most gcc releases have been compilable
as K&R C only with bug fixes.  The same is likely also true of binutils.  As
an experiment, I tried building binutils-2.13 on an HPUX system using the
bundled compiler.  It failed building binutils/readelf.c.
cc: "../../binutils-2.13/binutils/readelf.c", line 2505: error 1716: Automatic aggregate initialization is an ANSI feature.
I also tried building binutils-2.12.1.  It died in gprof/gmon_io.c.  This
one is more serious.  gprof is using 64-bit integer types without checking
for BFD64, which means it isn't even valid ISO C90.  This problem is still
present in binutils-2.13.  So that last two binutils releases weren't K&R C.
If nobody noticed that the code isn't K&R C, then why is it important to
continue trying to use K&R C?

Jim