From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19317 invoked by alias); 7 Jan 2009 16:17:07 -0000 Received: (qmail 19308 invoked by uid 22791); 7 Jan 2009 16:17:06 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 07 Jan 2009 16:16:59 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id n07GGXGI025986; Wed, 7 Jan 2009 17:16:33 +0100 (CET) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id n07GGXtu029119; Wed, 7 Jan 2009 17:16:33 +0100 (CET) Date: Wed, 07 Jan 2009 16:17:00 -0000 Message-Id: <200901071616.n07GGXtu029119@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: brobecker@adacore.com CC: gdb-patches@sourceware.org In-reply-to: <20090107121908.GH1751@adacore.com> (message from Joel Brobecker on Wed, 7 Jan 2009 16:19:08 +0400) Subject: Re: [RFC] convert a host address to a string References: <20090107121908.GH1751@adacore.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-01/txt/msg00100.txt.bz2 > Date: Wed, 7 Jan 2009 16:19:08 +0400 > From: Joel Brobecker > > The host_address_to_string function converts the host address to > a string using sprintf after having converted the address to an > unsigned long. > > Unfortunately for us, on x86_64-windows, unsigned long is not big > enough to hold an address. My initial approach was to detect this case > by using a configure check which defines HOST_IS_LLP64 if sizeof (void*) > is 8 while sizeof (long) is 4. > > Mark's reaction was that we should be able to use something more elegant. > One of the things we could do, perhaps, is use %p, which is mentioned by > the comment inside the function. I checked the C90 draft, and %p is > definitely mentioned, so I suspect it's fine to use it assuming we > require C90. The problem is, are we going to break the build on some > targets if we do? 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. 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. 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.