home *** CD-ROM | disk | FTP | other *** search
/ Fresh Fish 7 / FreshFishVol7.bin / bbs / gnu / gcc-2.3.3-src.lha / GNU / src / amiga / gcc-2.3.3 / c-aux-info.c < prev    next >
C/C++ Source or Header  |  1994-02-06  |  22KB  |  643 lines
  1. /* Generate information regarding function declarations and definitions based
  2.    on information stored in GCC's tree structure.  This code implements the
  3.    -aux-info option.
  4.  
  5.    This code was written by Ron Guilmette (rfg@mcc.com).
  6.  
  7.    Copyright (C) 1989, 1991 Free Software Foundation, Inc.
  8.  
  9. This file is part of GNU CC.
  10.  
  11. GNU CC is free software; you can redistribute it and/or modify
  12. it under the terms of the GNU General Public License as published by
  13. the Free Software Foundation; either version 2, or (at your option)
  14. any later version.
  15.  
  16. GNU CC is distributed in the hope that it will be useful,
  17. but WITHOUT ANY WARRANTY; without even the implied warranty of
  18. MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  19. GNU General Public License for more details.
  20.  
  21. You should have received a copy of the GNU General Public License
  22. along with GNU CC; see the file COPYING.  If not, write to
  23. the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.  */
  24.  
  25. #include <stdio.h>
  26. #include "config.h"
  27. #include "flags.h"
  28. #include "tree.h"
  29. #include "c-tree.h"
  30.  
  31. extern char* xmalloc ();
  32.  
  33. enum formals_style_enum {
  34.   ansi,
  35.   k_and_r_names,
  36.   k_and_r_decls
  37. };
  38. typedef enum formals_style_enum formals_style;
  39.  
  40.  
  41. static char* data_type;
  42.  
  43. static char * concat ();
  44. static char * concat3 ();
  45. static char * gen_formal_list_for_type ();
  46. static int    deserves_ellipsis ();
  47. static char * gen_formal_list_for_func_def ();
  48. static char * gen_type ();
  49. static char * gen_decl ();
  50. void   gen_aux_info_record ();
  51.  
  52. /*  Take two strings and mash them together into a newly allocated area.  */
  53.  
  54. static char*
  55. concat (s1, s2)
  56.      char* s1;
  57.      char* s2;
  58. {
  59.   int size1, size2;
  60.   char* ret_val;
  61.  
  62.   if (!s1)
  63.     s1 = "";
  64.   if (!s2)
  65.     s2 = "";
  66.  
  67.   size1 = strlen (s1);
  68.   size2 = strlen (s2);
  69.   ret_val = xmalloc (size1 + size2 + 1);
  70.   strcpy (ret_val, s1);
  71.   strcpy (&ret_val[size1], s2);
  72.   return ret_val;
  73. }
  74.  
  75. /*  Take three strings and mash them together into a newly allocated area.  */
  76.  
  77. static char*
  78. concat3 (s1, s2, s3)
  79.      char* s1;
  80.      char* s2;
  81.      char* s3;
  82. {
  83.   int size1, size2, size3;
  84.   char* ret_val;
  85.  
  86.   if (!s1)
  87.     s1 = "";
  88.   if (!s2)
  89.     s2 = "";
  90.   if (!s3)
  91.     s3 = "";
  92.  
  93.   size1 = strlen (s1);
  94.   size2 = strlen (s2);
  95.   size3 = strlen (s3);
  96.   ret_val = xmalloc (size1 + size2 + size3 + 1);
  97.   strcpy (ret_val, s1);
  98.   strcpy (&ret_val[size1], s2);
  99.   strcpy (&ret_val[size1+size2], s3);
  100.   return ret_val;
  101. }
  102.  
  103. /* Given a string representing an entire type or an entire declaration
  104.    which only lacks the actual "data-type" specifier (at its left end),
  105.    affix the data-type specifier to the left end of the given type
  106.    specification or object declaration.
  107.  
  108.    Because of C language weirdness, the data-type specifier (which normally
  109.    goes in at the very left end) may have to be slipped in just to the
  110.    right of any leading "const" or "volatile" qualifiers (there may be more
  111.    than one).  Actually this may not be strictly necessary because it seems
  112.    that GCC (at least) accepts `<data-type> const foo;' and treats it the
  113.    same as `const <data-type> foo;' but people are accustomed to seeing
  114.    `const char *foo;' and *not* `char const *foo;' so we try to create types
  115.    that look as expected.  */
  116.  
  117. static char*
  118. affix_data_type (type_or_decl)
  119.      char *type_or_decl;
  120. {
  121.   char *p = type_or_decl;
  122.   char *qualifiers_then_data_type;
  123.   char saved;
  124.  
  125.   /* Skip as many leading const's or volatile's as there are.  */
  126.  
  127.   for (;;)
  128.     {
  129.       if (!strncmp (p, "volatile ", 9))
  130.         {
  131.           p += 9;
  132.           continue;
  133.         }
  134.       if (!strncmp (p, "const ", 6))
  135.         {
  136.           p += 6;
  137.           continue;
  138.         }
  139.       break;
  140.     }
  141.  
  142.   /* p now points to the place where we can insert the data type.  We have to
  143.      add a blank after the data-type of course.  */
  144.  
  145.   if (p == type_or_decl)
  146.     return concat3 (data_type, " ", type_or_decl);
  147.  
  148.   saved = *p;
  149.   *p = '\0';
  150.   qualifiers_then_data_type = concat (type_or_decl, data_type);
  151.   *p = saved;
  152.   return concat3 (qualifiers_then_data_type, " ", p);
  153. }
  154.  
  155. /* Given a tree node which represents some "function type", generate the
  156.    source code version of a formal parameter list (of some given style) for
  157.    this function type.  Return the whole formal parameter list (including
  158.    a pair of surrounding parens) as a string.   Note that if the style
  159.    we are currently aiming for is non-ansi, then we just return a pair
  160.    of empty parens here. */
  161.  
  162. static char*
  163. gen_formal_list_for_type (fntype, style)
  164.      tree fntype;
  165.      formals_style style;
  166. {
  167.   char* formal_list = "";
  168.   tree formal_type;
  169.  
  170.   if (style != ansi)
  171.     return "()";
  172.  
  173.   formal_type = TYPE_ARG_TYPES (fntype);
  174.   while (formal_type && TREE_VALUE (formal_type) != void_type_node)
  175.     {
  176.       char* this_type;
  177.  
  178.       if (*formal_list)
  179.         formal_list = concat (formal_list, ", ");
  180.  
  181.       this_type = gen_type ("", TREE_VALUE (formal_type), ansi);
  182.       formal_list =
  183.           (strlen (this_type))
  184.               ? concat (formal_list, affix_data_type (this_type))
  185.               : concat (formal_list, data_type);
  186.  
  187.       formal_type = TREE_CHAIN (formal_type);
  188.     }
  189.  
  190.   /* If we got to here, then we are trying to generate an ANSI style formal
  191.      parameters list.
  192.  
  193.      New style prototyped ANSI formal parameter lists should in theory always
  194.      contain some stuff between the opening and closing parens, even if it is
  195.      only "void".
  196.  
  197.      The brutal truth though is that there is lots of old K&R code out there
  198.      which contains declarations of "pointer-to-function" parameters and
  199.      these almost never have fully specified formal parameter lists associated
  200.      with them.  That is, the pointer-to-function parameters are declared
  201.      with just empty parameter lists.
  202.  
  203.      In cases such as these, protoize should really insert *something* into
  204.      the vacant parameter lists, but what?  It has no basis on which to insert
  205.      anything in particular.
  206.  
  207.      Here, we make life easy for protoize by trying to distinguish between
  208.      K&R empty parameter lists and new-style prototyped parameter lists
  209.      that actually contain "void".  In the latter case we (obviously) want
  210.      to output the "void" verbatim, and that what we do.  In the former case,
  211.      we do our best to give protoize something nice to insert.
  212.  
  213.      This "something nice" should be something that is still legal (when
  214.      re-compiled) but something that can clearly indicate to the user that
  215.      more typing information (for the parameter list) should be added (by
  216.      hand) at some convenient moment.
  217.  
  218.      The string chosen here is a comment with question marks in it.  */
  219.  
  220.   if (!*formal_list)
  221.     {
  222.       if (TYPE_ARG_TYPES (fntype))
  223.         /* assert (TREE_VALUE (TYPE_ARG_TYPES (fntype)) == void_type_node);  */
  224.         formal_list = "void";
  225.       else
  226.         formal_list = "/* ??? */";
  227.     }
  228.   else
  229.     {
  230.       /* If there were at least some parameters, and if the formals-types-list
  231.          petered out to a NULL (i.e. without being terminated by a
  232.          void_type_node) then we need to tack on an ellipsis.  */
  233.       if (!formal_type)
  234.         formal_list = concat (formal_list, ", ...");
  235.     }
  236.  
  237.   return concat3 (" (", formal_list, ")");
  238. }
  239.  
  240. /* For the generation of an ANSI prototype for a function definition, we have
  241.    to look at the formal parameter list of the function's own "type" to
  242.    determine if the function's formal parameter list should end with an
  243.    ellipsis.  Given a tree node, the following function will return non-zero
  244.    if the "function type" parameter list should end with an ellipsis.  */
  245.  
  246. static int
  247. deserves_ellipsis (fntype)
  248.      tree fntype;
  249. {
  250.   tree formal_type;
  251.  
  252.   formal_type = TYPE_ARG_TYPES (fntype);
  253.   while (formal_type && TREE_VALUE (formal_type) != void_type_node)
  254.     formal_type = TREE_CHAIN (formal_type);
  255.  
  256.   /* If there were at least some parameters, and if the formals-types-list
  257.      petered out to a NULL (i.e. without being terminated by a void_type_node)
  258.      then we need to tack on an ellipsis.  */
  259.  
  260.   return (!formal_type && TYPE_ARG_TYPES (fntype));
  261. }
  262.  
  263. /* Generate a parameter list for a function definition (in some given style).
  264.  
  265.    Note that this routine has to be separate (and different) from the