This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: GDB CVS won't build on OSF4.0's cc


Eli Zaretskii <eliz@is.elta.co.il> writes:

>> From: Alexandre Oliva <aoliva@redhat.com>
>> On Jun 10, 2001, Eli Zaretskii <eliz@is.elta.co.il> wrote:

>> >> -  memset ((PTR) objfile->sym_stab_info, 0, sizeof (struct dbx_symfile_info)); 
>> >> +  memset ((void *) objfile->sym_stab_info, 0,
>> >> +         sizeof (struct dbx_symfile_info));

>>> Do we _really_ have compilers which require to cast the first argument of
>>> memset to (void *)?

>> Dunno.  I was just dumbly replacing PTR with void*, as requested.

> Does anyone know?

> IMHO, excess casting is evil, as it can mask programmatic errors.
> However, if GDB standards don't frown on this, it's fine by me.

If memset is prototyped as taking a void *, this cast is unnecessary; the
C standard requires that the argument be converted appropriately due to
the prototype.  If memset is prototyped as taking a char *, this cast
neither hurts nor helps; the pointer has to be converted into a char *
anyway and that would be done by the prototype.

If memset isn't prototyped or has a K&R-style prototype without argument
types, then this could arguably help if pointers to different types of
objects were represented differently internally.  I'm a little skeptical
whether gdb supports such systems without proper function prototypes, and
I'd argue that this case is so insanely rare as to not bother worrying
about, particularly since gdb is now requiring ANSI C.

I've been systematically ripping those sorts of casts out of INN for a
while now.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]