From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mark Kettenis <kettenis@chello.nl>
To: mec.gnu@mindspring.com
Cc: gdb-patches@sources.redhat.com, randolph@tausq.org
Subject: Re: [commited] small changes to fix hpux-cc compile
Date: Sun, 16 May 2004 10:33:00 -0000
Message-id: <200405161032.i4GAWp8q002490@elgar.kettenis.dyndns.org>
References: <20040516101223.635BF4B104@berman.michael-chastain.com>
X-SW-Source: 2004-05/msg00463.html

   Date: Sun, 16 May 2004 06:12:23 -0400 (EDT)
   From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)

   Hi Randolph,

   In this change:

     -  char dld_flags_buffer[TARGET_INT_BIT / TARGET_CHAR_BIT];
     +  char dld_flags_buffer[4];

   I just ran into the same problem with TARGET_INT_BIT so I understand
   why this needs to change.  But why 4?  What if the target configuration
   has 64-bit ints?

The question should be: will there ever be a target that uses SOM that
doesn't use 32-bit ints?  I think we can be fairly certain that there
won't be such target in the future.  HP already has abandoned SOM in
favour of ELF of 64-bit HP-UX, and even that still has 32-bit ints.
As a matter of fact, I'm not aware of any ABI that has 64-bit ints.
But in general:

   How about this instead:

     char * dld_flags_buffer = alloca(TARGET_INT_BIT/TARGET_CHAR_BIT);

This is indeed the right approach.

Mark