Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #67557

Re: Labels

Show all headers | View raw

James Kuyper <jameskuyper@verizon.net> writes:

> On 08/16/2015 05:42 PM, Ben Bacarisse wrote:
>> James Kuyper <jameskuyper@verizon.net> writes:
> ...
>>> So am I. I'm talking about a use of the typedef, not the declaration of
>>> the typedef. After parsing the full typedef declarator, if you find an
>>> identifier with the same name at the start of a new line, it could be
>>> the first token of a declaration, or the first token of a labeled
>>> statement, with a label that happens to be the same as the typedef
>>> name.
>> 
>> [I think there may be confusion used by terms here.  I've left my reply
>> as it was typed and added a bit at the end to say what I think might be
>> causing the confusion.  That was the simplest way I could think of to
>> try to unravel what might, in fact, be total agreement.
>> 
>> I originally wrote:]
>> 
>> I'm a bit confused by the reference to a new line and your use of
>> declarator.  You need to mark the identifier right after seeing the
>> declarator (even before the declaration is over) in order to parse
>> subsequent declarators in the same declaration, for example,
>> 
>>   typedef int *ip, func(ip);
>>
>>> Therefore, you can't mark it as a type until you've read the next token
>>> and determined that it's not ':'.
>> 
>> Having marked ip as a typedef name does not mean that you must ignore
>> the possibility that it might be used in other contexts (as a label
>> being one).  But I don't see how you can delay marking it as being a
>> typedef name -- and certainly not until you see it used without
>> following a ':'.
>> 
>> [Then it occurred to that you are using the word "mark" differently.  I
>> was referring to the trick of setting a flag in the symbol table to say
>> "this name has been the subject of a typedef declaration -- if you see
>> it where a type keyword makes sense, it is one".  I think you are
>> using it to mean "decide that an identifier is a typedef name".]
>
> Example code:
>
> void func(void)		// 1
> {			// 2
>     typedef int Int;	// 3
>     Int x;		// 4
>     Int:		// 5
>
> What I'm saying is that while parsing lines 4 and 5 of that example, the
> compiler cannot mark 'Int' as a type until it has read the next token.
> In line 4, that token is 'x', and Int is therefore a typedef. In the
> line 5, that token is ':', which means that Int is a label. It's
> precisely the fact that the next token has to be read, which was the
> reason for David's message that started this thread.

We are certainly using "marked" in different ways.  The compiler must
make a note that Int has been typedefed (if I can invent that verb) as
soon as it sees the declarator.  After line 5 the parser must see Int as
both a label and a typedef name -- it can take on either role.

> I gather that you've been referring the parsing of "Int" in Line 3, but
> that has nothing to do with anything David or I have been talking about.
> In particular, the message you posted with the header
> 	Date: Sat, 15 Aug 2015 23:44:38 +0100
> said "New named types simply take on the same syntactic role as type
> keywords like int." That's not true, because keywords can be marked as
> such regardless of context, while a typedef name, as shown above, needs
> some of it's following context parsed as well, in order to unambiguously
> identify it as a typedef. Also, unlike keywords, typedefs have scopes
> that need to be taken into consideration.

Yes, the phrase of mine you quote is an oversimplification.  New named
types take on the *possibility* of acting like type keywords.  They
don't always behave like them.  I should not have put it like that.  You
can use a typedefed identifier in all sorts of places -- not just as a
label:

  struct Int { ... };

of even

  Int Int = 42;

-- 
Ben.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Labels David Kleinecke <dkleinecke@gmail.com> - 2015-08-15 09:46 -0700
  Re: Labels James Kuyper <jameskuyper@verizon.net> - 2015-08-15 14:49 -0400
    Re: Labels David Kleinecke <dkleinecke@gmail.com> - 2015-08-15 18:48 -0700
  Re: Labels Bartc <bc@freeuk.com> - 2015-08-15 18:27 +0100
    Re: Labels Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-15 23:44 +0100
      Re: Labels James Kuyper <jameskuyper@verizon.net> - 2015-08-15 19:04 -0400
        Re: Labels Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-16 00:47 +0100
          Re: Labels James Kuyper <jameskuyper@verizon.net> - 2015-08-15 20:20 -0400
            Re: Labels Bartc <bc@freeuk.com> - 2015-08-16 01:56 +0100
              Re: Labels Keith Thompson <kst-u@mib.org> - 2015-08-15 19:47 -0700
                Re: Labels James Kuyper <jameskuyper@verizon.net> - 2015-08-16 11:59 -0400
            Re: Labels Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-16 22:42 +0100
              Re: Labels James Kuyper <jameskuyper@verizon.net> - 2015-08-16 20:39 -0400
                Re: Labels Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-17 03:16 +0100
        Re: Labels David Kleinecke <dkleinecke@gmail.com> - 2015-08-15 19:01 -0700
      Re: Labels Bartc <bc@freeuk.com> - 2015-08-16 01:11 +0100
        Re: Labels Keith Thompson <kst-u@mib.org> - 2015-08-15 19:13 -0700
          Re: Labels Bartc <bc@freeuk.com> - 2015-08-16 10:34 +0100
            Re: Labels Keith Thompson <kst-u@mib.org> - 2015-08-16 13:58 -0700
            Re: Labels David Kleinecke <dkleinecke@gmail.com> - 2015-08-16 20:42 -0700
              Re: Labels Keith Thompson <kst-u@mib.org> - 2015-08-16 21:24 -0700
                Re: Labels David Kleinecke <dkleinecke@gmail.com> - 2015-08-17 18:01 -0700
              Re: Labels Bartc <bc@freeuk.com> - 2015-08-17 11:04 +0100
        Re: Labels David Kleinecke <dkleinecke@gmail.com> - 2015-08-15 19:04 -0700
        Re: Labels Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-16 23:55 +0100
    Re: Labels David Kleinecke <dkleinecke@gmail.com> - 2015-08-15 19:00 -0700

csiph-web