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.)
next prev parent 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