Re: A prototype patch for tree.h/tree.def/calls.c

[Ian Haggard <ian@shellus.com>]

Jeffrey A Law wrote:
> 
>   In message <m0x0tpx-0004ecC@ocean.lucon.org>you write:
>   > > But regardless of what other parts of gcc are doing, using "unsigned"
>   > > in the prototype for xmalloc is wrong and such a change will not be
>   > > installed.
>   >
>   > It makes nosenses when the definion of xmalloc uses unsigned
>   > and its prototype uses size_t. It is much worse.
> Providing a prototype that is blatently wrong will not be accepted.
> There's no use argueing about this, an incorrect patch will not
> be accepted.

Actually, you are both sort-of right on this.  In some programs, the
definition of xmalloc takes a signed or unsigned int, and in some it
takes a size_t.  The mips-tfile.c is the worst offender:

Its definition of xmalloc starts like:

> 
> PTR_T
> xmalloc (size)
>      Size_t size;
> {

Earlier in mips-tfile.c, "Size_t" is defined as:

> #if defined(__OSF1__) || defined(__OSF__) || defined(__osf__)
> #define Size_t          long unsigned int
> #else
> #define Size_t          unsigned int
> #endif

Both cccp.c and protoize.c contain definitions of xmalloc with a size_t
argument.  And just for completeness, bi-arity.c, bi-lexer.c,
bi-opcode.c, and bi-opname.c also have the trivial inconsistency that
they contain definitions of xmalloc that expect an int, not an unsigned
int.  All other definitions of xmalloc do, however, take unsigned int.
-- 
Ian Haggard  ||  ian@shellus.com (work)  ||  IanHaggard@juno.com (home)
GNU/Linux -- "Oh, no, Mr Bill!" || #define employer_opinion !my_opinion