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

[Andrew Cagney <cagney at gnu dot org>]

(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