Re: Questions about GCC front end

rkrayhawk@aol.com (RKRayhawk)
17 Nov 2000 23:48:43 -0500

          From comp.compilers

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)
| List of all articles for this month |
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


Post a followup to this message

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