Re: Generating a simple hand-coded like recursive descent parser

phaywood@alphalink.com.au (Peter \"Shaggy\" Haywood)
30 Sep 2006 17:46:10 -0400

          From comp.compilers

Related articles
[21 earlier articles]
Re: Generating a simple hand-coded like recursive descent parser chris.dollin@hp.com (Chris Dollin) (2006-09-22)
Re: Generating a simple hand-coded like recursive descent parser DrDiettrich1@aol.com (Hans-Peter Diettrich) (2006-09-25)
Re: Generating a simple hand-coded like recursive descent parser chris.dollin@hp.com (Chris Dollin) (2006-09-25)
Re: Generating a simple hand-coded like recursive descent parser DrDiettrich1@aol.com (Hans-Peter Diettrich) (2006-09-26)
Re: Generating a simple hand-coded like recursive descent parser zebedee@zebedee.net (zebedee) (2006-09-28)
Re: Generating a simple hand-coded like recursive descent parser DrDiettrich1@aol.com (Hans-Peter Diettrich) (2006-09-28)
Re: Generating a simple hand-coded like recursive descent parser phaywood@alphalink.com.au (2006-09-30)
Re: Generating a simple hand-coded like recursive descent parser DrDiettrich1@aol.com (Hans-Peter Diettrich) (2006-12-16)
Re: Generating a simple hand-coded like recursive descent parser bobduff@shell01.TheWorld.com (Robert A Duff) (2006-12-17)
Re: Generating a simple hand-coded like recursive descent parser tommy.thorn@gmail.com (Tommy Thorn) (2006-12-19)
Re: Generating a simple hand-coded like recursive descent parser gneuner2@comcast.net (George Neuner) (2006-12-19)
Re: Generating a simple hand-coded like recursive descent parser chris.dollin@hp.com (Chris Dollin) (2006-12-19)
Re: Generating a simple hand-coded like recursive descent parser ajo@andrew.cmu.edu (Arthur J. O'Dwyer) (2006-12-19)
[10 later articles]
| List of all articles for this month |
From: phaywood@alphalink.com.au (Peter \"Shaggy\" Haywood)
Newsgroups: comp.compilers
Date: 30 Sep 2006 17:46:10 -0400
Organization: Chariot netconnect - http://www.chariot.net.au
References: 06-09-02906-09-042 06-09-048 06-09-060 06-09-078 06-09-093 06-09-108 06-09-117 06-09-125 06-09-137 06-09-139
Keywords: C, standards
Posted-Date: 30 Sep 2006 17:46:10 EDT

Groovy hepcat Hans-Peter Diettrich was jivin' on 26 Sep 2006 01:04:41
-0400 in comp.compilers.
Re: Generating a simple hand-coded like recursive descent parser's a
cool scene! Dig it!


>Chris Dollin wrote:
>
>>>C99 states that type declarations are not allowed in C procedure
>>>definitions.
>>
>>
>> Interesting. The draft has no such restriction in the typedef section,
>> and an explicit example with a typedef inside a function. Could you
>> provide a cite for me?
>
>Just from the DRAFT: 2 December 1996:


    That's a very old draft. Even n869.pdf (the last draft of C99) is
dated January 1999. And there's now n1124.pdf (draft of C0x), which
contains essentially the full text of C99 with a few proposed changes.
I suggest you download it.


>7.1.3 ... [dcl.typedef]
>1. ... The typedef specifier shall not be used in a function-definition
>(8.4),


    That doesn't mean typedef can't be used within a function. It means
that you can't use typedef in the function definition itself. That is,
you can't do something like this:


typedef void somefunc(void) {puts("whatever");};


Or perhaps it's badly worded and really means you can't do something
like this:


typedef void somefunc_t(void);
somefunc_t somefunc {puts("whatever");}


    In fact, there are some instances in which a typedef declaration
must have block scope.


>Can somebody lookup this paragraph in the final spec?


    I don't have the official standard. But I have n1124.pdf. That has
examples of typedef at block scope. And it says (if I've interpreted
it correctly) that typedef for an array with unspecified size, for
example, has to be at block scope. It gives this example:


----------------------------------------------------------------------
One form of initialization that completes array types involves typedef
names. Given the declaration


                          typedef int A[]; // OK - declared with block scope


the declaration


                          A a = { 1, 2 }, b = { 3, 4, 5 };


is identical to


                          int a[] = { 1, 2 }, b[] = { 3, 4, 5 };


due to the rules for incomplete types.
----------------------------------------------------------------------


As the comment says, the typedef is OK at block scope. It also gives
this example, which shows a typedef within a function body (In fact,
this is another one that is required within block scope.):


----------------------------------------------------------------------
extern int n;
int A[n]; // invalid: file scope VLA
extern int (*p2)[n]; // invalid: file scope VM
int B[100]; // valid: file scope but not VM
void fvla(int m, int C[m][m]); // valid: VLA with prototype scope


void fvla(int m, int C[m][m]) // valid: adjusted to auto pointer to
                                                            // VLA
{
        typedef int VLA[m][m]; // valid: block scope typedef VLA
        struct tag {
                int (*y)[n]; // invalid: y not ordinary identifier
                int z[n]; // invalid: z not ordinary identifier
        };
        int D[m]; // valid: auto VLA
        static int E[m]; // invalid: static block scope VLA
        extern int F[m]; // invalid: F has linkage and is VLA
        int (*s)[m]; // valid: auto pointer to VLA
        extern int (*r)[m]; // invalid: r has linkage and points to VLA
        static int (*q)[m] = &B; // valid: q is a static block pointer to
                                                          // VLA
}
----------------------------------------------------------------------


    I can find nothing else that would ban the use of typedef within a
function body, and the text you quoted above is not there.


>(The numbers have changed!)
>
>DoDi
>[I can't find that language, but there is a lengthy footnote on page
>141 with examples that specifically say that you can typedef a
>function type and use it in declarations but not in
>definitions. -John]


    Right.



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.