Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: drow@false.org
Cc: gdb@sourceware.org, cagney@gnu.org, eliz@gnu.org
Subject: Re: A case for `void *' for pointers to arbitrary (byte) buffers
Date: Tue, 03 May 2005 22:10:00 -0000	[thread overview]
Message-ID: <200505032206.j43M6QEN002791@elgar.sibelius.xs4all.nl> (raw)
In-Reply-To: <20050503211646.GB8203@nevyn.them.org> (message from Daniel Jacobowitz on Tue, 3 May 2005 17:16:46 -0400)

   Date: Tue, 3 May 2005 17:16:46 -0400
   From: Daniel Jacobowitz <drow@false.org>

   On Tue, May 03, 2005 at 11:13:24PM +0200, Mark Kettenis wrote:
   >    Date: Tue, 3 May 2005 16:23:52 -0400
   >    From: Daniel Jacobowitz <drow@false.org>
   > 
   >    > Why not use `xxx_byte *' instead of `void *'?
   >    > ---------------------------------------------
   >    > 
   >    > * It's nonstandard.  Why do we need a nonstandard type if a perfectly
   >    >   god standard type is available?
   >    > 
   >    > * It doesn't really solve the issue.  It only propagates the problem
   >    >   one level up or down.  Since `xxx_byte *' is nothing but a typedef
   >    >   for `unsigned char *', someone calling a functions with `xxx_byte *'
   >    >   as one of its arguments with a `char *' argument will suffer from
   >    >   the warning that raised this entire issue; `void *' breaks the chain
   >    >   immediately.
   > 
   >    I think that's a bad thing!  For the same reason that we use -Werror:
   >    where possible, we can let GCC enforce consistency within our source
   >    base.  Use of gdb_byte (as unsigned char) buys you the advantage that
   >    any other pointer type won't silently convert to it.
   > 
   > Ah, but these are supposed to be opaque blobs of memory.

   That's my point.  This way we can only pass "opaque blobs of memory" to
   the interfaces that want opaque blobs.  It's a question of
   categorization.  For instance, this is a bug:

     long foo;
     target_read_memory (addr, &foo, 4);

   If the second argument is "void *", a C compiler won't complain about
   this.  But for "uint8_t *", it will.

Hmm, you have a point here...

   >    If you want to use a standard type, play the necessary autoconf games
   >    to acquire stdint.h.  Use uint8_t *.
   > 
   > That's an interesting suggestion.  It might take a few iterations to
   > get that right though.

   I'm willing to do the work.

OK great!  I really like being able to use those (u)intN_t types, and
especially (u)intptr_t.  You can probably steal the autoconf checks
from GNU coreutils.  Those will have been pretty well tested I sppose.
But the base sequence should something like:

#ifdef HAVE_STDINT_H
#include <stdint.h>
#else
# ifdef HAVE_INTTYPES_H
# include <inttypes.h>
# else
typedef unsigned char uint8_t;
# endif
#endif

Mark


  reply	other threads:[~2005-05-03 22:10 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <42710E90.3030300@gnu.org>
     [not found] ` <200504281919.j3SJJKF1011501@elgar.sibelius.xs4all.nl>
     [not found]   ` <42715EE8.5070704@gnu.org>
     [not found]     ` <01c54c8a$Blat.v2.4$ffbe8140@zahav.net.il>
     [not found]       ` <42753958.70109@gnu.org>
     [not found]         ` <01c54e92$Blat.v2.4$5cf24460@zahav.net.il>
     [not found]           ` <42755FD4.8000009@gnu.org>
     [not found]             ` <01c54f4a$Blat.v2.4$a9fc8500@zahav.net.il>
     [not found]               ` <42778DE6.1080106@gnu.org>
2005-05-03 20:17                 ` Mark Kettenis
2005-05-03 20:23                   ` Daniel Jacobowitz
2005-05-03 21:14                     ` Mark Kettenis
2005-05-03 21:16                       ` Daniel Jacobowitz
2005-05-03 22:10                         ` Mark Kettenis [this message]
2005-05-03 22:28                           ` Daniel Jacobowitz
2005-05-03 22:31                             ` Joel Brobecker
2005-05-04 14:45                             ` Mark Kettenis
2005-05-04 20:36                               ` Eli Zaretskii
2005-05-04 15:40                       ` Andrew Cagney
2005-05-04 17:57                         ` Eli Zaretskii
2005-05-03 22:01                   ` Stan Shebs

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=200505032206.j43M6QEN002791@elgar.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --cc=cagney@gnu.org \
    --cc=drow@false.org \
    --cc=eliz@gnu.org \
    --cc=gdb@sourceware.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