www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Portability Function Attribute: portable

reply =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
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 endianess. The only examples I can think of right 
now is:

- Reinterpreting pointers and ranges between types with different 
word size in a way that endianness would affect result (explicit 
use)
- Using unions with same effects (implicit use)

I'm guessing this static analysis would have similarities with 
how  safe functions are checked, right?

Also, can you think any other property than endiness-dependence 
such a property would forbid a function to have.

Destroy!
Feb 25 2014
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Feb 25 2014
prev sibling next sibling parent =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
 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?
Feb 25 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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 the complete (to the bottom) source for?

Complete attribute inference was discussed ~year ago but is not on agenda right now. I don't think introduction of new attributes is feasible in practice until inference is implemented for existing ones.
Feb 25 2014
prev sibling next sibling parent "Chris Williams" <yoreanon-chrisw yahoo.co.jp> writes:
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 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.
Feb 25 2014
prev sibling next sibling parent =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
 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, say -portable, though....
Mar 25 2014
prev sibling next sibling parent =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
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?
Mar 25 2014
prev sibling parent "Chris Williams" <yoreanon-chrisw yahoo.co.jp> writes:
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 dangerous, though I would state them as "All unions with types larger than a byte and any access through a pointer where the target type is larger than a byte." You could catch a few more by considering equals/or/and/xor between a large lvalue and a byte rvalue to be non-portable. Most cases like this will either be related to deserializing byte arrays or people hashing/encrypting data. Annoying for the latter group, but valid for the former.
Mar 25 2014