From: Kai Tietz <Kai.Tietz@onevision.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org, Mark Kettenis <mark.kettenis@xs4all.nl>
Subject: Re: [RFC] convert a host address to a string
Date: Thu, 08 Jan 2009 10:25:00 -0000 [thread overview]
Message-ID: <OF836D6544.FC021CA1-ONC1257538.00392594-C1257538.003940BF@onevision.de> (raw)
In-Reply-To: <20090108101911.GQ3664@adacore.com>
gdb-patches-owner@sourceware.org wrote on 08.01.2009 11:19:11:
> > Probably not, but there's a problem with %p. While it is specified by
> > C90 and almost certainly implemented in the C library of all systems
> > we care about, it is implemented how exactly the pointer will be
> > printed. On OpenBSD and Linux it is something like 0xNNNNNNNN, but
> > Solaris generates NNNNNNNN (without the initial 0x). That's
> > undesirable I think.
>
> I agree.
>
> > An option would be to use the strategy used by phex_nz() to print host
> > addresses. Or we could use PRINTF_HAS_LONG_LONG, and always use %llx
> > if it's available.
>
> Unfortunately, I don't know how this could be made to work.
> The problem is that GCC insists that the integer type that we
> use to cast the host address to must have the same size.
> At one point, hoping that GCC would kill the wrong branch,
> I even tried:
>
> if (sizeof (void *) == sizeof (long))
> printf ("0x%lx", (long) address);
> else
> printf ("0x%llx", (long long) address);
>
> But this didn't work, because GCC complained about the cast
> in the "if" branch.
>
> Actually, it's only after writing the entire email that I realized
> that we have another option. See option (3) below.
>
> > I'd really like to avoid introducing another macro dealing with
> > type-size issues if possible. I especially dislike HOST_IS_LLP64
> > since I fear its existence encourages people to write unportable code.
>
> I can see several solutions:
>
> 1. Use %p. To overcome the problem with 0x, we could use
> two alternatives:
>
> a. Import printf from gnulib. I looked at this a while ago,
> for some other issue, and I immediately stopped, as it
> looked like it might be a lot of work to do so (printf
> doesn't come alone, there's a bunch of other routines
> that printf uses which we probably want).
>
> b. Strip the leading "0x" if %p already provides it. In other
> words:
>
> fprintf (buf, "0x%p", address);
> if (buf[2] == '0' && buf[3] == 'x')
> buf = buf + 2;
> return buf;
>
> There is no memory management issue in this case, because
> the buffer we return is more or less static. It's part
> of a bunch of buffers we cycle through each time we call
> this routine. The caller never frees the memory we return.
>
> 2. Avoid the HOST_IS_LLP64 macro, but still do something similar
> inside host_address_to_string. Something like:
>
> #if defined(WIN64_)
> fprintf (buf, "0x%llx", (unsigned long long) address);
> #else
> fprintf (buf, "0x%lx", (unsigned long) address);
> #endif
>
> This eliminates the likeliness of re-using the HOST_IS_LLP64
> macro to write non-portable code.
>
> 3. Work through uintptr_t.
>
> #ifdef PRINTF_HAS_LONG_LONG
> fprintf (buf, "0x%llx", (unsigned long long) (uintptr_t)
address);
> #else
> fprintf (buf, "0x%lx", (unsigned long) (uintptr_t) address);
> #endif
>
> For completeness' sake, I also investigate the use of the PRIxPTR
> macro, but we still have the problem of casting the address to
> the right integer type: If PRIxPTR resolves to "lx", then we should
> cast to "long", otherwise, we should cas to "long long".
>
> I kinda like option 1b as being simple and avoiding the need to
> cast the address to an integer. Option (3) is my next favorite,
> but I don't like the fact that we end up doing an unnecessary
> integer promotion on the 32bit targets. Perhaps we could avoid that
> using an extra "if (sizeof (void *) != sizeof (long))" but then
> the code becomes increasingly complex. My next favorite would
> probably be option 2 because I'm lazy, but it's really not elegant.
> Option 1 looks like a fair amount of work, but would give us access
> to a predicatable printf.
>
> Thoughts?
>
> --
> Joel
>
Why not simply use stdint.h (gstdint.h) for this?
Cheers,
Kai
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
next prev parent reply other threads:[~2009-01-08 10:25 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-07 12:19 Joel Brobecker
2009-01-07 16:17 ` Mark Kettenis
2009-01-08 10:19 ` Joel Brobecker
2009-01-08 10:25 ` Kai Tietz [this message]
2009-01-08 10:48 ` Joel Brobecker
2009-01-08 11:02 ` Kai Tietz
2009-01-08 11:25 ` Joel Brobecker
2009-01-08 11:31 ` Kai Tietz
2009-01-08 12:49 ` Mark Kettenis
2009-01-08 12:54 ` Joel Brobecker
2009-01-08 13:04 ` Kai Tietz
2009-01-08 13:12 ` Mark Kettenis
2009-01-08 13:26 ` Mark Kettenis
2009-01-08 13:35 ` Kai Tietz
2009-01-08 13:42 ` Joel Brobecker
2009-01-08 14:04 ` Kai Tietz
2009-01-08 16:18 ` Mark Kettenis
2009-01-08 16:23 ` Kai Tietz
2009-01-09 9:57 ` Joel Brobecker
2009-01-09 10:05 ` Kai Tietz
2009-01-09 13:12 ` Joel Brobecker
2009-01-09 14:28 ` Kai Tietz
2009-01-10 7:12 ` Joel Brobecker
2009-01-10 13:31 ` Kai Tietz
2009-01-10 13:34 ` Kai Tietz
2009-01-10 13:58 ` Mark Kettenis
2009-01-10 14:04 ` Mark Kettenis
2009-01-10 14:15 ` Kai Tietz
2009-01-10 14:22 ` Mark Kettenis
2009-01-10 14:25 ` Kai Tietz
2009-01-11 13:31 ` Joel Brobecker
2009-01-11 13:53 ` Mark Kettenis
2009-01-13 12:09 ` Joel Brobecker
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=OF836D6544.FC021CA1-ONC1257538.00392594-C1257538.003940BF@onevision.de \
--to=kai.tietz@onevision.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=mark.kettenis@xs4all.nl \
/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