Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Eli Zaretskii" <eliz@gnu.org>
To: gdb-patches@sources.redhat.com
Cc: Mark Kettenis <kettenis@gnu.org>
Subject: Re: [commit] Tighten memory read/write methods
Date: Fri, 28 Jan 2005 11:43:00 -0000	[thread overview]
Message-ID: <01c5052e$Blat.v2.4$2b4f9f00@zahav.net.il> (raw)
In-Reply-To: <200501280845.j0S8jkZx000823@elgar.sibelius.xs4all.nl> (message from Mark Kettenis on Fri, 28 Jan 2005 09:45:46 +0100 (CET))

> Date: Fri, 28 Jan 2005 09:45:46 +0100 (CET)
> From: Mark Kettenis <kettenis@gnu.org>
> CC: gdb-patches@sources.redhat.com
> 
> OK, I can understand your rationale for seperating const-correctness
> from other transformations; but then why don't you seperate the
> (unsigned) char -> bfd_byte transformation too?  I'm all for
> consistent use of 'bfd_byte *' as the canonical way to point to a
> buffer interpreted as seperate bytes.  However, I think that pointers
> to generic bits of memory should be 'void *' (which specific bits of
> code might want to cast to 'bfd_byte *' if they're going to interpret
> the bytes individually).  Doing the mind-numbing conversion means that
> we'll have to re-evaluate all occurances of 'bfd_byte' again later.

I don't like the use of bfd_byte either.  I think we shouldn't use BFD
types in our sources for data types that don't have anything to do
with the BFD library.  If, for some reason, "void *" somehow doesn't
fit the bill (and I'd like to see evidence to that before I agree),
I'd suggest our own data type, like gdb_byte or some such.

P.S.  IMHO, this is one more example of a situation where a discussion
that preceded commits would be in order.  I don't know about others,
but as far as I'm concerned, when such controversial changes are
committed without discussions, it doesn't help me to feel a part of a
team.  (And please don't tell me that Andrew had a right to do this:
this is not about rights, but about using them indiscriminantly.)


  reply	other threads:[~2005-01-28 11:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-27 20:11 Andrew Cagney
2005-01-27 21:04 ` Mark Kettenis
2005-01-27 23:06   ` Andrew Cagney
2005-01-28  8:46     ` Mark Kettenis
2005-01-28 11:43       ` Eli Zaretskii [this message]
2005-01-28 18:48         ` Andrew Cagney
2005-01-28 20:21           ` Mark Kettenis
2005-01-29 10:33           ` Eli Zaretskii
2005-01-27 21:05 ` Mark Kettenis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='01c5052e$Blat.v2.4$2b4f9f00@zahav.net.il' \
    --to=eliz@gnu.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=kettenis@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox