Re: A case for `void *' for pointers to arbitrary (byte) buffers

Andrew Cagney
2005-05-04T15:40:16Z

(yet again something ate my e-mail, I'm reading from the web)

Mark described the problem as:
> In many places GDB needs to pass along and pick apart blobs of memory.
> In many cases, GDB does this using `char *' pointers. Small blobs of
> memory are often allocated on the stack as `char[]' or `unsigned
> char[]'.

This is not correct. 'void *' is more applicable to arbitrary opaque
objects. Here, though, we know the object's type (a byte buffer) and
hence should use that. Daniel correctly explains it thus (from a
disconnected thread):

> These are byte-oriented buffers, so using a type where we can perform
> byte-oriented arithmetic without superfluous casts seems like a good
> choice to me. Converting to void * (and not using the GCC extension
> which allows arithmetic on void *) would be a painful process.

(And as someone that actually thought to try out the two alternatives
and determine the damage, I can tell you that void* and casts totally sux.)

Also, in support of this move away from void*, BINUTILS, several months
ago, and in response to this rumored warning, re-vamped their types
moving more strongly towards bfd_byte* (one consequence was that I had
to update some of GDB's interfaces).

As for the names bfd_byte vs gdb_byte that really is arbitrary. To
ensure that our byte buffers are compatible with BFDs we'll want to use
"typedef bfd_byte gdb_byte" anyway. Given that we're already doing
similar for LONGEST, ADDRESS, et.al., that shouldn't be contraversial.

Anyway, since the prefered name is "gdb_byte", and that was Eli's idea,
I think it is fit and proper that Eli take the honours. Can we get it
done by tomorrow? If not let me know (Hopefully I can now go back to
fixing my GCC 4 warnings).

Andrew