Re: #define XMALLOC(TYPE) (TYPE*) xmalloc (sizeof (TYPE))

[Andrew Cagney <ac131313 at cygnus dot com>]

Stan Shebs wrote:
> 
>    From: Andrew Cagney <ac131313@cygnus.com>
>    Date: Wed, 03 Nov 1999 20:11:30 +1100
> 
>    Here is a style question.  A convention I adopted when developing psim
>    (gdb/sim/ppc) was to use the macro:
> 
>    #define XMALLOC(TYPE) (TYPE*) xmalloc (sizeof (TYPE))
> 
> I have mixed feelings about this.  The simplification is attractive,
> but I'm cringing at the idea of introducing still more macros into
> the sources (although I notice that you introduced it into several
> files already...).  Also, this version only simplifies the singleton
> allocations, though admittedly those seem to account for about 2/3
> of the xmalloc calls.
> 
> If everybody else likes this, I'll go along.
> 
>    It's a poor persons ``new()''.  Would people react violently if this
>    definition was pushed into defs.h where it could be used more widely?
>    This is very different to making it a requirement of any coding
>    standard.
> 
> If we *do* use this, I would rather encourage its use, add a
> multiplying version (call it XMALLOC_N or some such), deprecate bare
> calls to xmalloc, and - ideally - change all the existing calls.  It's
> much more important to me to be consistent throughout the code.
> Otherwise future GDB hackers will scratch their heads and wonder
> whether they're supposed to be using xmalloc or XMALLOC.

XCALLOC(NUMBER,TYPE) comes to mind.

A gdb/testsuite/gdb.codingstandard testuite could always be added.  If
people do things like add more K&R-C the number of test failures goes up
.... :-)  (Um, I'm _not_ serious! :-)

I'm actually reluctant to go through and replace existing xmalloc's. 
There are also plenty of cases where an arbitrary sized buffer is being
created and xmalloc() is most correct.

Another possible resolution is of course for me to eliminate XMALLOC
from the sources.

	Andrew