Compile the following with -std=c99 -pedantic-errors void f(unsigned int [*]); foo.c:1: error: '[*]' not allowed in other than a declaration
Confirmed, a regression from 4.1.2 which we accepted this but gave a warning saying we don't implement the semantics yet. Since we accepted this with a warning before and now reject it, I am going to say this is a regression. Note I think Mike Stump's work in this area caused this bug but I am not 100% for sure.
Subject: Re: New: Strictly conforming code rejected On Mon, 18 Sep 2006, neil at gcc dot gnu dot org wrote: > Compile the following with -std=c99 -pedantic-errors > > void f(unsigned int [*]); > > foo.c:1: error: '[*]' not allowed in other than a declaration As the diagnostic indicates, "unsigned int [*]" is not a declaration with function prototype scope but a type name. Feel free to submit a DR regarding the exact meaning of "can only be used in declarations with function prototype scope".
Subject: Re: [4.2 Regression] Strictly conforming code rejected joseph at codesourcery dot com wrote:- > > foo.c:1: error: '[*]' not allowed in other than a declaration > > As the diagnostic indicates, "unsigned int [*]" is not a declaration with > function prototype scope but a type name. Feel free to submit a DR > regarding the exact meaning of "can only be used in declarations with > function prototype scope". I'm quite happy my reading is correct, thanks, but don't let me stop you. I'd be interested in why you believe an alternative reading is justified despite its explicit inclusion in the grammar of 6.7.6, plus examples. DR 295 is an example of continuing imprecise wording that is far more gratuitous. Neil.
Suspending pending DR. Neil's interpretation would be a more useful sense of the standard, but there is a deliberate decision to err on the side of rejecting code rather than of accidentally creating an extension. If the WG14 Spring 2007 meeting does happen in the UK as proposed then I may try to prepare DRs for this and other issues.
Given that Joseph doesn't think we should change the behavior, we shouldn't have this on the release watchlist.
Will not be fixed in 4.2.0; retargeting at 4.2.1.
Change target milestone to 4.2.3, as 4.2.2 has been released.
4.2.3 is being released now, changing milestones of open bugs to 4.2.4.
4.2.4 is being released, changing milestones to 4.2.5.
The conclusion on DR#341 was that this should indeed be accepted; I'll fix this.
Subject: Bug 29129 Author: jsm28 Date: Wed Feb 4 00:59:21 2009 New Revision: 143918 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143918 Log: PR c/29129 * c-decl.c (grokdeclarator): Mark [*] arrays in field declarators as having variable size. Do not give an error for unnamed parameters with [*] declarators. Give a warning for type names with [*] declarators and mark them as variable size. * c-parser.c (c_parser_sizeof_expression): Do not give an error for sizeof applied to [*] type names. testsuite: * c90-arraydecl-1.c: Do not expect error for [*] in abstract declarator. * vla-6.c: Likewise. Expect warning not error for [*] lexically inside function prototype but not part of parameter declarator. * vla-11.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vla-11.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c trunk/gcc/c-parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/c90-arraydecl-1.c trunk/gcc/testsuite/gcc.dg/vla-6.c
Fixed in 4.4 and it's safest not to apply the fix to release branches.
I tried the latest gcc, but it rejects the sample code: <source>:1:23: error: expected primary-expression before ']' token 1 | void f(unsigned int [*]); | ^ Compiler returned: 1 Is this a regression? Or, the idea is changed, and this code shall be rejected?
You need to change godbolt.org to compile C not C++. Please stop adding completely useless comments to bugzilla or I will block your account.