[Issue 10763] (&x)[0 .. 1] doesn't work in CTFE

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=10763



--- Comment #8 from Don <clugdbug at yahoo.com.au> 2013-08-19 04:48:39 PDT ---
(In reply to comment #7)
> (In reply to comment #3)
> > It's basically the same as issue 10266.
> > The corner cases arise if you still disallow &x + 1. My guess is that you're
> > allowing it in your implementation?
> > 
> > The problem with allowing it is that we're departing from C. And there's
> > annoying things like:
> > 
> > // global scope
> > int x;
> > int *p = &x + 1; // points to junk! - must not compile
> > 
> > 
> > Is there really a use case for this unsafe behaviour?
> 
> Only one would be in std.math if we want to make the elementary functions
> CTFE-able (we've discussed this before).

That's why my proposed solution for that is to allow only the complete
expression, where the pointer is instantly dereferenced:

(cast(ulong *)cast(void *)&f)[0];

and it really only needs to be allowed for 80-bit reals, since casting
float<->int and double<->long is already supported.

The minimal operations are:
- significand  <-> ulong
- sign  + exponent <-> ushort

That would give us four special-case hacks which are x87 specific. Effectively
they are intrinsics with ugly syntax.

The existing code could be modified slightly to only use those four operations,
with no performance penalty. 

> But yes, I think that it is right to disallow it, as there is no clean way to
> slice up basic types into an array and guarantee ie: format or endian
> correctness at compile time (cross-compilers, for instance).

It's an ugly area.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------