GCC Parse Bug?
-
This produces a parse error:
if (YES)
NSString *myString = @"hello";
But this is fine:
if (YES) {
NSString *myString = @"hello";
}
Also fine:
if (YES)
NSBeep();
Is this normal behavior for gcc 3.3?
- Scott -
I'd say that's normal behavior for any C compiler. ;) In standard C,
you can't just declare new variables anywhere. Only at the start of a
new block, hence why the second case works.
-Ken
On Monday, July 14, 2003, at 12:54 PM, Scott Stevenson wrote:> This produces a parse error:
>
> if (YES)
> NSString *myString = @"hello";
>
> But this is fine:
>
> if (YES) {
> NSString *myString = @"hello";
> }
>
> Also fine:
>
> if (YES)
> NSBeep();
>
>
> Is this normal behavior for gcc 3.3?
>
>
> - Scott -
On Monday, Jul 14, 2003, at 16:20 US/Eastern, Kenneth C. Dyke wrote:> I'd say that's normal behavior for any C compiler. ;) In standard C,
> you can't just declare new variables anywhere. Only at the start of a
> new block, hence why the second case works.
Actually that is not totally true. It is true with C89 or C94 but with
C99, you can
almost declare them any where, there are some rules which are described
below.>
> -Ken
>
> On Monday, July 14, 2003, at 12:54 PM, Scott Stevenson wrote:
>
>> This produces a parse error:
>>
>> if (YES)
>> NSString *myString = @"hello";
You have to have a block (can be any where in the block though) so this
is invalid code.>>
>> But this is fine:
>>
>> if (YES) {
>> NSString *myString = @"hello";
>> }
>>
>> Also fine:
>>
>> if (YES)
>> NSBeep();
>>
>>
>> Is this normal behavior for gcc 3.3?
Also this is fine in C99 but not in C89 or C94 (which is
C89+extensions):
if (YES) {
NSBeep();
NSString *myString = @"hello";
}
Yes because of the C99 standard.
Thanks,
Andrew Pinski -
On Monday, July 14, 2003, at 01:20 PM, Kenneth C. Dyke wrote:> I'd say that's normal behavior for any C compiler. ;) In standard C,
> you can't just declare new variables anywhere. Only at the start of a
> new block, hence why the second case works.
Apple's has shipped gcc with C99 stuff since the Jaguar tools (or was
it the December update?), which allows you to declare variables in
places other than the beginning of the function.
I was just surprised that the single-liner without the curly brace
syntax wasn't treated the same as one with.
- Scott -
Is C99 on by default, though? I was under the impression that it was
not.
-Ken
On Monday, July 14, 2003, at 2:24 PM, Scott Stevenson wrote:>
> On Monday, July 14, 2003, at 01:20 PM, Kenneth C. Dyke wrote:
>
>> I'd say that's normal behavior for any C compiler. ;) In standard C,
>> you can't just declare new variables anywhere. Only at the start of
>> a new block, hence why the second case works.
>
> Apple's has shipped gcc with C99 stuff since the Jaguar tools (or was
> it the December update?), which allows you to declare variables in
> places other than the beginning of the function.
>
> I was just surprised that the single-liner without the curly brace
> syntax wasn't treated the same as one with.
>
> - Scott
>
> _______________________________________________
> MacOSX-dev mailing list
> <MacOSX-dev...>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
> -
On Monday, July 14, 2003, at 02:38 PM, Kenneth C. Dyke wrote:> Is C99 on by default, though? I was under the impression that it was
> not.
I didn't have to turn it on, though that may not apply to all
situations.
- Scott -
On Monday, Jul 14, 2003, at 17:38 US/Eastern, Kenneth C. Dyke wrote:> Is C99 on by default, though? I was under the impression that it was
> not.
Actually G89 is turned on by default which is C94 (C89+wchar_t) and GNU
extensions, some are
included in C99, like long long and the one which what this thread is
taking about.
Thanks,
Andrew Pinski -
After I had upgraded to December version, it was no longer turn on by
default. And I don't know how to turn it on manually. So it made me rewrite
my codes.
Jeff> From: Andrew Pinski <pinskia...>
> Date: Mon, 14 Jul 2003 19:11:55 -0400
> To: "Kenneth C. Dyke" <kdyke...>
> Cc: Andrew Pinski <pinskia...>, Scott Stevenson
> <sstevenson...>, MacOS Dev <macosx-dev...>
> Subject: Re: GCC Parse Bug?
>
> On Monday, Jul 14, 2003, at 17:38 US/Eastern, Kenneth C. Dyke wrote:
>> Is C99 on by default, though? I was under the impression that it was
>> not.
>
> Actually G89 is turned on by default which is C94 (C89+wchar_t) and GNU
> extensions, some are
> included in C99, like long long and the one which what this thread is
> taking about.
>
>
>
> Thanks,
> Andrew Pinski
>
> _______________________________________________
> MacOSX-dev mailing list
> <MacOSX-dev...>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev -
Are you sure you are using 3.3 instead of 2.95.2, because sometimes PBX
wants to use 2.95.2.
If you want back to 3.1, use `gcc_select 3.1'.
Thanks,
Andrew Pinski
On Monday, Jul 14, 2003, at 21:11 US/Eastern, Jeff Ye wrote:> After I had upgraded to December version, it was no longer turn on by
> default. And I don't know how to turn it on manually. So it made me
> rewrite
> my codes.
>
> Jeff -
Thanks Andrew, I think you have pointed me to the right direction!
Within Compiler setting of PB, I can only choose GCC v3.1 or GCC v2.95.2.
And I found that there are 3 versions of gcc within my machine:
/usr/bin/gcc version 3.3 build 1435
/usr/bin/gcc3 version 3.1 prerelease
/usr/bin/gcc2 vesion 2.95.2
Why the most recent version was missed in PB? Any suggest is appriciated.
Thanks,
Jeff> From: Andrew Pinski <pinskia...>
> Date: Mon, 14 Jul 2003 21:17:00 -0400
> To: Jeff Ye <jeff_yecn...>
> Cc: Andrew Pinski <pinskia...>, Macosx-dev
> <macosx-dev...>
> Subject: Re: GCC Parse Bug?
>
> Are you sure you are using 3.3 instead of 2.95.2, because sometimes PBX
> wants to use 2.95.2.
>
> If you want back to 3.1, use `gcc_select 3.1'.
>
> Thanks,
> Andrew Pinski
>
>
> On Monday, Jul 14, 2003, at 21:11 US/Eastern, Jeff Ye wrote:
>
>> After I had upgraded to December version, it was no longer turn on by
>> default. And I don't know how to turn it on manually. So it made me
>> rewrite
>> my codes.
>>
>> Jeff
>
> _______________________________________________
> MacOSX-dev mailing list
> <MacOSX-dev...>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev -
I believe this was by design in the update.
It's my understanding that the next update to PB and/or Xcode will
support it.....
-Cameron Wilhelm
On Monday, July 14, 2003, at 08:52 PM, Jeff Ye wrote:> Thanks Andrew, I think you have pointed me to the right direction!
>
> Within Compiler setting of PB, I can only choose GCC v3.1 or GCC
> v2.95.2.
>
> And I found that there are 3 versions of gcc within my machine:
>
> /usr/bin/gcc version 3.3 build 1435
>
> /usr/bin/gcc3 version 3.1 prerelease
>
> /usr/bin/gcc2 vesion 2.95.2
>
> Why the most recent version was missed in PB? Any suggest is
> appriciated.
>
> Thanks,
> Jeff
>
>> From: Andrew Pinski <pinskia...>
>> Date: Mon, 14 Jul 2003 21:17:00 -0400
>> To: Jeff Ye <jeff_yecn...>
>> Cc: Andrew Pinski <pinskia...>, Macosx-dev
>> <macosx-dev...>
>> Subject: Re: GCC Parse Bug?
>>
>> Are you sure you are using 3.3 instead of 2.95.2, because sometimes
>> PBX
>> wants to use 2.95.2.
>>
>> If you want back to 3.1, use `gcc_select 3.1'.
>>
>> Thanks,
>> Andrew Pinski
>>
>>
>> On Monday, Jul 14, 2003, at 21:11 US/Eastern, Jeff Ye wrote:
>>
>>> After I had upgraded to December version, it was no longer turn on by
>>> default. And I don't know how to turn it on manually. So it made me
>>> rewrite
>>> my codes.
>>>
>>> Jeff
>>
>> _______________________________________________
>> MacOSX-dev mailing list
>> <MacOSX-dev...>
>> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>
> _______________________________________________
> MacOSX-dev mailing list
> <MacOSX-dev...>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
> -
On Monday, July 14, 2003, at 09:24 PM, Scott Stevenson wrote:> I was just surprised that the single-liner without the curly brace
> syntax wasn't treated the same as one with.
But if you think about it,
if(foo) NSString* s = blah();
has different implications than
if(foo) {NSString* s = blah();}
and they're not especially pleasant implications from a language
sanity standpoint.
G
