Related articles |
---|
Questions about GCC front end mandayrv@nb.conexant.com (Ramanand V Mandayam) (2000-11-14) |
Re: Questions about GCC front end rkrayhawk@aol.com (2000-11-17) |
From: | rkrayhawk@aol.com (RKRayhawk) |
Newsgroups: | comp.compilers |
Date: | 17 Nov 2000 23:48:43 -0500 |
Organization: | AOL http://www.aol.com |
References: | 00-11-107 |
Keywords: | GCC |
Posted-Date: | 17 Nov 2000 23:48:43 EST |
Unless the GCC 'Front End' has become a new kind of C universe then
the sequence
typedef int INT;
...
INT myfunc_2 ( int y);
merely set up a declaration of my_func_2 as returning an int, as
though you had coded
int myfunc_2 ( int y);
Your concern to the effect
<<
According to the documentation, the conditional
(TREE_CODE (TYPE_NAME (t)) == TYPE_DECL)
where t is the node containing the type information
should fail for the parameters x and y, but it repeatedly passes.
>>
seems a little confused ... almost as though you are under the
impression that the typedefs are setting up the acceptable function
parameter pattern (known as the signature). That is not so.
Typedefs are really just a kind of preprocessor mechanism (that is a
dangerous simplification, but bear with me). Typedefs are like text
definition. INT is defined as 'int'. So in later phases of compilation
the when the machine encounters INT it must substitute 'int' and look
again at the text thus generated.
The signature of the function is actually determined by the function
declaration, such as your
INT myfunc_2 ( int y);
This tells the compiler to expect myfunc_2() to be invoked with an int
as its parameter, or a value that may be coercible to such an int.
So you would have part A in a program, ... perhaps
typedef int INT;
which does not determine anything about my_func2().
Then part B, function declarations, either in a header file or hard
coded high in the source. Such as,
int myfunc_2 ( int y);
this has effects on anything that comes later, which might be
something like this
int test_int;
char test_char;
float test_float;
char *prt_to_char;
/* smooth sailing */
result = myfunct_2(test_int);
/* coerces char silently to int (perhaps) */
result = myfunct_2(test_char);
/* most compilers will complain here */
result = myfunct_2(test_float);
/* this almost certainly is not going to work */
result = myfunct_2(prt_to_char);
The other part of your example ...
typedef union _char { char x; } *XYZ;
...
XYZ myfunc_1 ( int x);
again is just the equivalent of text substitution.
for a function declaration
union _char *myfunc_1( int );
which may or may not be a declaration of a function that returns a
pointer to a union that has a tag of _char. But for the part you are
asking about, the early typedef does not set up the signature of the
function. The function declaration, the second part ...
<whatever> *myfunc_1(int);
establishes the pattern.
I think that the representation system in the really technical
documentation you are reading has you a little confused about the 't'
being in the parens of the function declaration or invocation. Not so,
it is just a way ... and perhaps an obtuse way ... of representing the
semantics of type declarations. Don't worry about all that. Just go
back to the code and try more examples: maybe like this
typedef int INT;
.....
INT myfunc_2(int);
INT myfunc_22(int, int);
INT myfunct_cool(float, char*, double); /* look, Mom, no ints) */
/* now watch this */
double convert_this(INT);
long int convert_that(INT);
int find_bigger_one(INT, INT);
Best Wishes
Bob Rayhawk
rayhawk@alum.calberkeley.org
Return to the
comp.compilers page.
Search the
comp.compilers archives again.