Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* Replace char * with something sensible
@ 2005-05-03 19:53 Eli Zaretskii
  2005-05-03 19:58 ` Daniel Jacobowitz
  0 siblings, 1 reply; 3+ messages in thread
From: Eli Zaretskii @ 2005-05-03 19:53 UTC (permalink / raw)
  To: gdb

Rumor has it that latest versions of GCC whine about mixing "char *"
and "unsigned char *".  To fix that, Andrew committed some patches
that replace these with a "bfd_byte *", but I think we should not use
BFD data types in GDB unless they refer to data structures returned by
functions from the BFD library.

Possible solutions:

 . use "void *" (suggested by Mark Kettenis).

 . define a new data type gdb_byte and use "gdb_byte *".

I think Mark's suggestion should be considered first, since it avoids
the pain of introducing yet another custom data type.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Replace char * with something sensible
  2005-05-03 19:53 Replace char * with something sensible Eli Zaretskii
@ 2005-05-03 19:58 ` Daniel Jacobowitz
  2005-05-03 20:28   ` Mark Kettenis
  0 siblings, 1 reply; 3+ messages in thread
From: Daniel Jacobowitz @ 2005-05-03 19:58 UTC (permalink / raw)
  To: gdb

On Tue, May 03, 2005 at 10:51:02PM +0300, Eli Zaretskii wrote:
> Rumor has it that latest versions of GCC whine about mixing "char *"
> and "unsigned char *".  To fix that, Andrew committed some patches
> that replace these with a "bfd_byte *", but I think we should not use
> BFD data types in GDB unless they refer to data structures returned by
> functions from the BFD library.
> 
> Possible solutions:
> 
>  . use "void *" (suggested by Mark Kettenis).
> 
>  . define a new data type gdb_byte and use "gdb_byte *".
> 
> I think Mark's suggestion should be considered first, since it avoids
> the pain of introducing yet another custom data type.

I am marginally in favor of gdb_byte.  What pain would it cause,
besides a huge sed for the existing bfd_byte cases?

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.

It's not as if non-8-bit-byte support is anywhere on our horizon.

-- 
Daniel Jacobowitz
CodeSourcery, LLC


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Replace char * with something sensible
  2005-05-03 19:58 ` Daniel Jacobowitz
@ 2005-05-03 20:28   ` Mark Kettenis
  0 siblings, 0 replies; 3+ messages in thread
From: Mark Kettenis @ 2005-05-03 20:28 UTC (permalink / raw)
  To: drow; +Cc: gdb

   Date: Tue, 3 May 2005 15:58:15 -0400
   From: Daniel Jacobowitz <drow@false.org>

   On Tue, May 03, 2005 at 10:51:02PM +0300, Eli Zaretskii wrote:
   > Rumor has it that latest versions of GCC whine about mixing "char *"
   > and "unsigned char *".  To fix that, Andrew committed some patches
   > that replace these with a "bfd_byte *", but I think we should not use
   > BFD data types in GDB unless they refer to data structures returned by
   > functions from the BFD library.
   > 
   > Possible solutions:
   > 
   >  . use "void *" (suggested by Mark Kettenis).
   > 
   >  . define a new data type gdb_byte and use "gdb_byte *".
   > 
   > I think Mark's suggestion should be considered first, since it avoids
   > the pain of introducing yet another custom data type.

   I am marginally in favor of gdb_byte.  What pain would it cause,
   besides a huge sed for the existing bfd_byte cases?

I hope my (somewhat lengthy) post can change your mind ;-).

   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.

We have -Wpointer-arith in our standard warning flags so there's no
risk in us using that darn GCC extension.

   It's not as if non-8-bit-byte support is anywhere on our horizon.

And it is probably completely irrelevant for this discussion.

Mark


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2005-05-03 20:28 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-05-03 19:53 Replace char * with something sensible Eli Zaretskii
2005-05-03 19:58 ` Daniel Jacobowitz
2005-05-03 20:28   ` Mark Kettenis

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox