From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cagney <ac131313@cygnus.com>
To: Nick Duffek <nsd@redhat.com>
Cc: Dautrevaux@microprocess.com, gdb@sources.redhat.com, insight@sources.redhat.com
Subject: Re: Register group proposal
Date: Mon, 26 Feb 2001 18:21:00 -0000
Message-id: <3A9B0E90.D3D920EC@cygnus.com>
References: <17B78BDF120BD411B70100500422FC6309E214@IIS000> <200102242351.f1ONpp704661@rtl.cygnus.com>
X-SW-Source: 2001-02/msg00402.html

Nick Duffek wrote:
> But prohibiting typedefs ....

When implementing an ``object'', I'm asking that it be done in a way
that is consistent with other recent additions to gdb - that is
blah.[hc] defines an opaque ``struct blah *''.  (As a style its
advantages and disadvantages have probably now been beaten to death :-)

While it does implicitly put a restriction on the use of typedefs in
certain header files, it is not a prohibition of typedef.

If someone feels that they have concerns when defining a specific
interface then I would assume that that person will also put those
concerns forward.  In doing this they may well demonstrate a possible
need to implement their interface in a way that is different to the
above.

To give an example, consider LONGEST.  One day that type will need to be
extended beyond 64 bits (long long).  When that happens, it might be
done with something like:
	defs.h:
	  struct longest {
	    something_goes here;
	  };
	  typedef struct longest LONGEST;
Among the rationale would be the observation that LONGEST is a self
contained lightweight.  You could try to implement it as a ``struct
longest *'' but it would make memory management a nightmare while
showing very few advantages.  Being able to perform the mechanical
replacement:
	a = b + c;
  with	a = add (b, c);
would be of much greater benefit.  (See sim/common/sim-fpu.[hc].)

	Andrew