http://d.puremagic.com/issues/show_bug.cgi?id=10763
--- Comment #8 from Don <clugd...@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: -------