I think the larger issue would be that the same people who
understand when code would be endian-unsafe are the same ones
who would try to write endian-safe code. People who don't know
any better wouldn't know enough to mark their function unsafe.
We could mark modules or even add a dmd flag,
Just by curiosity:
What more than forbidding pointer-dribbling (casting and
arithmetic) and unions with members smaller than word size should
we require to be @portable?
On Tuesday, 25 March 2014 at 20:16:49 UTC, Nordlöw wrote:
Just by curiosity:
What more than forbidding pointer-dribbling (casting and
arithmetic) and unions with members smaller than word size
should we require to be @portable?
Your two are all that I can think of that are definitely
I have a suggestion for yet another cool feature that would be
nice to have in D...namely a *portability* attribute perhaps
called
@portable
Any functions that are marked as @portable would be forbidden to
do calculations whose result have different results on targets
with different
I think the problem here is there's too many functions that would
need to be marked it to be useful and it isn't a big enough deal
for most libs to bother.
I think the problem here is there's too many functions that
would need to be marked it to be useful and it isn't a big
enough deal for most libs to bother.
Couldn't the compiler recursively infer this property for
functions it has the complete (to the bottom) source for?
On Tuesday, 25 February 2014 at 23:12:37 UTC, Nordlöw wrote:
I think the problem here is there's too many functions that
would need to be marked it to be useful and it isn't a big
enough deal for most libs to bother.
Couldn't the compiler recursively infer this property for
functions it has
On Tuesday, 25 February 2014 at 23:06:46 UTC, Adam D. Ruppe wrote:
I think the problem here is there's too many functions that
would need to be marked it to be useful and it isn't a big
enough deal for most libs to bother.
I think the larger issue would be that the same people who
understand
