Email List: Xaustin-group-lX
[All Lists]

Re: BUG in XSHd3 getaddrinfo

To: austin-group-l@xxxxxxxxxxxxx
Subject: Re: BUG in XSHd3 getaddrinfo
From: Vincent Lefevre <vincent-opgr@xxxxxxxxxx>
Date: Fri, 27 Jul 2007 17:12:17 +0200
Mail-followup-to: austin-group-l@xxxxxx
References: <20070724084254.83930@xxxxxx> <20070724100336.GA8578@xxxxxx> <1185405650.18130.93.camel@amstaff2.msbit.com> <20070726130304.GB83988@finch-staff-1.thus.net> <20070726155227.GM6654@xxxxxx> <20070727082219.GD61231@finch-staff-1.thus.net> <46a9d434.mlK2GaCN1szsrmok%Joerg.Schilling@xxxxxx> <20070727113036.GY61231@finch-staff-1.thus.net>
On 2007-07-27 12:30:36 +0100, Clive D.W. Feather wrote:
> However, the following does *NOT* set p to a null pointer:
> 
>     intptr_t i = (3 + (int) 17.4 - 400 % 38);
>     int *p = (int *) i;

Well, the C standard does not require to set p to a null pointer
(with some loose interpretation, because the C standard uses the
word "conversion" with different meanings), but an implementation
is allowed to set p to a null pointer (but of course, i mustn't
represent a valid pointer), as integer->pointer conversions are
implementation-defined.

> The generated code for a conversion from integer to pointer is *not*
> required to treat 0 specially; it can be a straightforward bit copy.
                   ^^^ non-constant

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

<Prev in Thread] Current Thread [Next in Thread>