Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3EA5B9F8.C6F193BE@phekda.freeserve.co.uk>
Date: Tue, 22 Apr 2003 22:54:00 +0100
From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: Yet another try on nan in strto{f,d,ld}
References: <200304221509 DOT RAA06409 AT lws256 DOT lu DOT erisoft DOT se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

Martin Stromberg wrote:
> 
> Richard said:
> > > I mean the plain typecasts, like this:
> > >
> > >     +    double_t n = *(double_t *)(&tmp_d);
> > >
> > > or this:
> > >
> > >     +   return *(double *)(&n);
> > [snip]
> >
> > As I understand it, restrict'ed variables are strictly aliased.
> 
> Uuhhh... "strictly aliased"?

restricted variables are strictly aliased. That doesn't mean that strictly
aliased variables are restricted. ;)

> Anyway, are you saying that tmp_d, n or *(double *)(&n) is strictly
> aliased, restrict qualified or in anyway will become so when we add
> restrict to the function's parameters? Why? Howcome? (Note that tmp_d
> and n are local variables.)

No. But if you're getting the compiler is generating warnings about strict
aliasing, then it will generate a warning for this case. Below is an extract
from gcc 3.2.2's manual, as show by "info Invoking 'Optimize Options'".

...

-fstrict-aliasing'
    Allows the compiler to assume the strictest aliasing rules
    applicable to the language being compiled.  For C (and C++), this
    activates optimizations based on the type of expressions.  In
    particular, an object of one type is assumed never to reside at
    the same address as an object of a different type, unless the
    types are almost the same.  For example, an `unsigned int' can
    alias an `int', but not a `void*' or a `double'.  A character type
    may alias any other type.