"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
| On Wed, 10 May 2006, Andreas Schwab wrote:
|
| > Mike Stump <[EMAIL PROTECTED]> writes:
| >
| > > Speaking of typeof, should typeof (vla) follow the same rules as for
| > > sizeof (vla)? vla, evaluate, otherwise, no eval.
| >
| > How would typeof
On Wed, 10 May 2006, Andreas Schwab wrote:
> Mike Stump <[EMAIL PROTECTED]> writes:
>
> > Speaking of typeof, should typeof (vla) follow the same rules as for
> > sizeof (vla)? vla, evaluate, otherwise, no eval.
>
> How would typeof be able to eval anything?
If you have "typeof ((int (*)[f()])
Mike Stump <[EMAIL PROTECTED]> writes:
> Speaking of typeof, should typeof (vla) follow the same rules as for
> sizeof (vla)? vla, evaluate, otherwise, no eval.
How would typeof be able to eval anything?
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfel
On Wed, 10 May 2006, Mike Stump wrote:
> On May 8, 2006, at 2:30 PM, Joseph S. Myers wrote:
> > > void foo11(typeof (int (*)(int o[*])) i);
> >
> > I think that's valid gnu99.
>
> Speaking of typeof, should typeof (vla) follow the same rules as for sizeof
> (vla)? vla, evaluate, otherwise, no e
On May 8, 2006, at 2:30 PM, Joseph S. Myers wrote:
void foo11(typeof (int (*)(int o[*])) i);
I think that's valid gnu99.
Speaking of typeof, should typeof (vla) follow the same rules as for
sizeof (vla)? vla, evaluate, otherwise, no eval.
On Mon, 8 May 2006, Mike Stump wrote:
> On May 6, 2006, at 3:32 PM, Joseph S. Myers wrote:
> > Function prototype scope is defined in 6.2.1#4.
>
> I've fixed up most all the previously identified issues...
>
> In gnu99:
>
> void foo11(typeof (int (*)(int o[*])) i);
>
> valid?
I think that's v
On May 6, 2006, at 3:32 PM, Joseph S. Myers wrote:
Function prototype scope is defined in 6.2.1#4.
I've fixed up most all the previously identified issues...
In gnu99:
void foo11(typeof (int (*)(int o[*])) i);
valid?
Joseph S. Myers wrote:-
> On Sun, 7 May 2006, Neil Booth wrote:
>
> > For the composite type, 6.2.7p3 dash 1 applies, and the composite is
> > the VLA type. That VLA type is derived indirectly from an incomplete
> > type, and hence subscripting that incomplete type falls foul of the
> > contrain
On Sun, 7 May 2006, Neil Booth wrote:
> For the composite type, 6.2.7p3 dash 1 applies, and the composite is
> the VLA type. That VLA type is derived indirectly from an incomplete
> type, and hence subscripting that incomplete type falls foul of the
> contraint on the subscript operator.
>
> I b
Joseph S. Myers wrote:-
> > which seems reasonable based on my understanding of composite types
> > of VLA types: that either satisfies the requirements of, and therefore
> > can be taken to be, the composite type.
>
> I think the type's complete: the recursive application of the composite
> typ
On Sun, 7 May 2006, Neil Booth wrote:
> My front end, and Comeau's oneline compiler, both give a similar
> message:
>
> "/tmp/foo.c", line 10: error: expression must point to a complete type
> int r = (c1()
> ^
>
> which seems reasonable based on my understanding of composite types
>
Joseph S. Myers wrote:-
> for that case. To quote my message:
>
> Consider the code
>
> int a, b, c, d, e, f;
> void *p1(void), *p2(void), *p3(void);
> int c1(void), c2(void);
> int d1(void), d2(void), d3(void);
> int z1(void), z2(void), z3(void);
>
> int
>
On Sat, 6 May 2006, Mike Stump wrote:
> I'll entertain pointers to VLA/VM and [*] bugs for C, please send me pointers
> to reports in bugzilla.
>
> Thanks.
>
> I know about http://gcc.gnu.org/PR25802
Bugs 19771, 7948, 18740 (in general, look at the bugs on which bug 16989
depends). The questi
I'll entertain pointers to VLA/VM and [*] bugs for C, please send me
pointers to reports in bugzilla.
Thanks.
I know about http://gcc.gnu.org/PR25802
I also would like to know what people think the standard (c99) says
about:
void foo4(int o[*][4]) { }
void foo5(int o[4][*]) { }
void foo6(
14 matches
Mail list logo
