(no subject)

[Bryan Wagstaff]

--- It seems like everyone is talking about ---
>1) ftpfs.c: conn->hook is cast to a (unsigned)(uintptr_t), would it
not be
>easier just to print conn-hook as a pointer using %p?
>
>2) cthreads.c: RESULT is cast to (int)(long), aren't int supposed to
be the
>same size as longs?  If so, why would RESULT need to be cast twice?
>
....
>It's not a pointer that's being printed, so %p format is not what we
want.
>It's an integer that's stored in the void * member.


I'm not a HURD hacker, just a wanna-be lurker who reads sources.  :)

If you are casting values of potentially different sizes, shouldn't
you have functions or macros elsewhere to do this safely?  Obviously
converting long to int might lose significant bits, but if all you
want is the low 32 bits, shouldn't there be a way to extract them? 
Similarly, assuming a pointer is a certain size will always cause
portability problems.  Is there ever a GOOD reason to store a
non-pointer in a pointer type (other than poor design, which we are
trying to avoid) ?

That's something that's always bugged me about the C and C++
standards.  There should be more built-in conversion functions.

Perhaps something similar to the (dare I say it) Windows macros HIWORD
and LOWORD?

bryanw.


From roland@frob.com Wed May 08 18:28:31 2002
Received: from h00d0b71b83ad.ne.client2.attbi.com ([65.96.132.240] 
helo=perdition.linnaean.org)
        by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian))
        id 175ZvC-00029g-00
        for <bug-hurd@gnu.org>; Wed, 08 May 2002 18:28:31 -0400
Received: by perdition.linnaean.org (Postfix, from userid 5281)
        id C896E1BA15; Wed,  8 May 2002 18:28:29 -0400 (EDT)
From: Roland McGrath <roland@frob.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Jeff Bailey <jbailey@nisa.net>
Cc: bug-hurd@gnu.org
Subject: Re: Weak symbols in libresolv?
In-Reply-To: Jeff Bailey's message of  Wed, 8 May 2002 15:03:50 -0700 
<20020508220350.GD9605@nisa.net>
X-Antipastobozoticataclysm: 
   When George Bush projectile vomits antipasto on the Japanese.
Message-Id: <20020508222829.C896E1BA15@perdition.linnaean.org>
Date: Wed,  8 May 2002 18:28:29 -0400 (EDT)
Sender: bug-hurd-admin@gnu.org
Errors-To: bug-hurd-admin@gnu.org
X-BeenThere: bug-hurd@gnu.org
X-Mailman-Version: 2.0.9
Precedence: bulk
List-Help: <mailto:bug-hurd-request@gnu.org?subject=help>
List-Post: <mailto:bug-hurd@gnu.org>
List-Subscribe: <http://mail.gnu.org/mailman/listinfo/bug-hurd>,
        <mailto:bug-hurd-request@gnu.org?subject=subscribe>
List-Id: Bug reports for the GNU Hurd <bug-hurd.gnu.org>
List-Unsubscribe: <http://mail.gnu.org/mailman/listinfo/bug-hurd>,
        <mailto:bug-hurd-request@gnu.org?subject=unsubscribe>
List-Archive: <http://mail.gnu.org/pipermail/bug-hurd/>

That seems to be an intentional situation in the source.  That is, the weak
aliases in resolv/res_data.c are made only if GLIBC_2_0 compatibility is
required, which has been the case before and is not the case for
libc.so.0.3.  resolv.h #define's those symbols to the __ names, so anything
compiled with the current resolv.h ought to use the __ names directly.  If
the code you're dealing with did #undef's of symbols in libc headers that
are not standardized (i.e. resolv.h), then it will probably be the one blamed.