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 <[EMAIL PROTECTED]> 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]