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

d-bugmail at puremagic.com d-bugmail at puremagic.com
Mon Aug 19 05:29:10 PDT 2013


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



--- Comment #9 from Iain Buclaw <ibuclaw at ubuntu.com> 2013-08-19 05:29:09 PDT ---
(In reply to comment #8)
> (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.
> 

And (speaking as someone who stubbed out your implementation of float<->int and
double<->long cast) the only reason why it's supported is because the backend I
implement against can (thankfully) do re-interpreted native casts between basic
types such as integer, float, complex and vectors.

You will need to support all reals that have support in std.math. This includes
64-bit, 80-bit, 96-bit (really just 80-bit), 128-bit (likewise), and 128-bit
(quadruple).  There are only three supported formats really... (double-double
will have to keep with partial support for the time being, sorry PPC!)

> 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.
> 

I veto any new addition that is x87 specific - or, more accurately endian
specific.

Remember its:

version(BigEndian)
  short sign_exp = (cast(ushort*)&x)[0];
else
  short sign_exp = (cast(ushort*)&x)[5];

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


More information about the Digitalmars-d-bugs mailing list