Re: Patch for having internal macros as functions, take 2

[Jeffrey A Law <law at cygnus dot com>]

  In message <Pine.BSF.4.10.10001012135050.12220-101000@dair.pair.com>you write
:
  >   This message is in MIME format.  The first part should be readable text,
  >   while the remaining parts are likely unreadable without MIME-aware tools.
  >   Send mail to mime@docserver.cac.washington.edu for more info.
  > 
  > --0-1015364592-946780998=:12220
  > Content-Type: TEXT/PLAIN; charset=US-ASCII
  > 
 > Here's how it works:
  > 
  > Markers are added in header files with interesting macros.  For
  > example:
  >    PROVIDE_MACRO_FUNCTION (XEXP, rtx, (rtx, int))
  > belonging in rtl.h, and:
  >    PROVIDE_MACRO_VALUE (PROP_DEATH_NOTES, int)
  > belonging in basic-block.h.
  >  The marks stay close to the macro definition, so when macros
  > are modified, any necessary change to the corresponding 
  > P_M_F/P_M_V mark is spotted right away, instead of at
  > compilation time.
  > 
  > The difference between P_M_F and P_M_V is that P_M_F takes
  > parameters, while P_M_V does not.
  > 
  > These marks are picked up by a script, which generates a C file
  > from a list of header files containing these marks.  For the
  > above examples, the generated code will look like:
This seems *way* more complex than it needs to be.  We just sit down and
write a handful of functions for the most common accessor macros that we
need.  parsing header files, generating C files from them, etc etc for
this seems like major overkill in terms of complexity/maintainability vs
usefulness.

I'd rather just have a file with the interesting debugging functions for
the accessor macros in it.  They need not be declared inline.  They
should follow GNU coding shardards :-)