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


Groups > comp.lang.c > #67545

Re: Labels

From Ben Bacarisse <ben.usenet@bsb.me.uk>
Newsgroups comp.lang.c
Subject Re: Labels
Date 2015-08-16 22:42 +0100
Organization A noiseless patient Spider
Message-ID <87614egbb1.fsf@bsb.me.uk> (permalink)
References (1 earlier) <mqnsnd$2c5$1@dont-email.me> <874mk0goix.fsf@bsb.me.uk> <55CFC58E.5090600@verizon.net> <87mvxsf713.fsf@bsb.me.uk> <55CFD75B.6020102@verizon.net>

Show all headers | View raw


James Kuyper <jameskuyper@verizon.net> writes:

> On 08/15/2015 07:47 PM, Ben Bacarisse wrote:
>> James Kuyper <jameskuyper@verizon.net> writes:
>> 
>>> On 08/15/2015 06:44 PM, Ben Bacarisse wrote:
>>>> Bartc <bc@freeuk.com> writes:
>>>> <snip>
>>>>> Is 'A*B' an expression, or is it declaring a variable B of type
>>>>> pointer-to-A?
>>>>>
>>>>> Is 'F(G)' a function call to G with argument G, or is it declaring a
>>>>> variable G of type F, or is it the start of function declaration, or
>>>>> the start of function definition?
>>>>>
>>>>> I think you have your work cut out!
>>>>
>>>> This makes it sound as if C is particularly hard to parse, but it isn't,
>>>> provided you know how to handle typedefs.  After reading a typedef, the
>>>> parser must mark the identifiers involved as referring to types.
>>>
>>> As earlier messages in this thread have shown, you can't always do that
>>> immediately after parsing the identifier - the identifier could be a
>>> statement label, and you have to read the next token after the
>>> identifier to rule out that possibility.
>> 
>> I'm taking about what the parse must do once it has parsed a full
>> typedef declarator.
>
> 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".]

<snip>
-- 
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