Bug#318612: acknowledged by developer (Re: Bug#318612: gcc-4.0: gcc 4.0 refuses to compile void foo(struct bar[]); 3.4 is OK)
I am reopening this bug, this IS a bug and it has NOT been fixed.
On Sat, Jul 16, 2005 at 08:48:41AM -0700, Debian Bug Tracking System wrote:
>
> Jakob Bohm <jbj@image.dk> writes:
>
> > Package: gcc-4.0
> > Version: 4.0.1-2
> > Severity: important
> >
> > gcc 4.0 fails to compile the following 3 line sample:
> >
> > struct bar;
> > void baz(struct bar*);
> > void foo(struct bar[]);
> >
> > gcc 3.4 and older do not complain.
> >
> > The issue is that gcc-3.4 and older realize that [] in a parameter
> > is the same as * and accepts the incomplete structure type, gcc 4.0
> > does not.
>
> It isn't the same; you cannot have arrays of incomplete types. This
> was accidentally accepted anyway in earlier gccs, but that is now
> fixed. You'll have to fix your code.
>
1. It is NOT my code, it is the most recent Linux kernel-source package
currently in unstable!
2. This is not an array of an incomplete type! It is a quirky way to
declare a pointer type whose relationship with arrays is mostly syntactic.
Rejecting perfectly meaningful and functional code because it breaks a
formal reading of the standard, is the job of gcc -pedantic, not of the
default gcc mode for production code.
3. If it was accepted without a stern warning of imminent removal in
previous versions of gcc (accidentally or not), which it was, then it is
irresponsible to remove the functionality in the next version of gcc without
an extremely big and important reason. No such reason is in sight.
4. After filing this report I spent a few hours digging through gcc mailing
lists (there appears to be no meaningful upstream change documentation), all
I could find was a single message on the subject.
The message I found contained NO valid reason for this incompatible change
in gcc behaviour. All it did was to quote from an official 1992 message
from the C standards-committe in which this issue was mixed up with two less
clear cases and then rejected as a bunch with no reason given at all.
Since gcc (and presumably some other compilers, need to test this) have been
consistently accepting this interpretation of the C standard by
gcc-compilable C programs for more than 10 years after that official message
from ISO WG14, users of gcc are entitled to assume this to be a deliberate
and supported gcc language extension, which should not be removed just
because some knee-jerk language lawyer doesn't understand why it makes sense
to keep it.
It IS a bug in gcc 4.0 and if upstream refuses to fix it, Debian will need
to fix it or drop the broken gcc version.
There is NO EXCUSE for gcc rejecting this without -pedantic, especially
considering that they had no problem keeping the behaviour for more than 10
years.
During my research I was chocked to read that language lawyers have made
other such sabotage-removal of language extensions from gcc 4.0 .
I INSIST that this be fixed in the Debian version of gcc, or the gcc 4.0
transition aborted PERMANENTLY until gcc upstream learns the principles of
responsible and competent software maintainence. Demanding that every
program in the world except gcc change to suit the whims of some insane
member of the gcc upstream team is just not a meaningful use of peoples
time.
Yes, I am getting angry about this. gcc 4.0 is the WORST gcc release in
many years, and the cause seems to be a deliberate upstream desire to
maximize breakage and language lawyering. Fix it or drop it.
--
This message is hastily written, please ignore any unpleasant wordings,
do not consider it a binding commitment, even if its phrasing may
indicate so. Its contents may be deliberately or accidentally untrue.
Trademarks and other things belong to their owners, if any.
Reply to: