September 07, 2012 Re: pointers, functions, and uniform call syntax | ||||
---|---|---|---|---|
| ||||
Posted in reply to Artur Skawina | On Thursday, 6 September 2012 at 21:58:43 UTC, Artur Skawina wrote:
> This program won't assert
> and would segfault if 'i' was accessed by 'func'.
So it seems. The way I read it says it dereferences it first. Regardless that you are forcibly referencing a pointer which is low-level trickery; which I'm sure is undefined behavior.
Course if you have to check/treat it as a pointer, adding @safe suddenly refuses to compile (Won't let you get the address); But if you leave it out (without @trusted either) and make main @safe, suddenly that doesn't compile either. (Because I'm sure quite a few functions you'd want to share will end up being @safe and pure).
auto func(ref int i) @safe {
assert(!&i); //won't compile as @safe
debug { //ignore that writeln is system
writeln("Address:", &i); //here too
writeln("Value:", i);
}
return i;
}
void main() @safe {
int v = 100; func(v);
int* i; func(*i);
}
As I commented before: Would you really want to blindly put @trusted on everything? In order for the above to work, either neither is @safe, or func is @trusted.
Course you can always leave @safe out, assuming you aren't making anything you intend to share or will never be called by anything that's @safe.
|
September 07, 2012 Re: pointers, functions, and uniform call syntax | ||||
---|---|---|---|---|
| ||||
Posted in reply to Era Scarecrow | On Friday, 7 September 2012 at 00:51:42 UTC, Era Scarecrow wrote:
> So it seems. The way I read it says it dereferences it first. Regardless that you are forcibly referencing a pointer which is low-level trickery; which I'm sure is undefined behavior.
*Technically*, I think it is only undefined behavior once you *read* the dereferenced value... and passing by reference doesn't do that.
|
September 07, 2012 Re: pointers, functions, and uniform call syntax | ||||
---|---|---|---|---|
| ||||
Posted in reply to Era Scarecrow | On 09/07/12 02:52, Era Scarecrow wrote: > On Thursday, 6 September 2012 at 21:58:43 UTC, Artur Skawina wrote: >> This program won't assert >> and would segfault if 'i' was accessed by 'func'. > > So it seems. The way I read it says it dereferences it first. Regardless that you are forcibly referencing a pointer which is low-level trickery; which I'm sure is undefined behavior. There's nothing undefined about passing args by reference; i know the '*s' looks misleading, but what happens when such an expression is used as a ref arg is basically '&*s' and then the compiler will let you access the result via the function parameter; it's essentially syntax sugar (with a few extra usage restrictions). > Course if you have to check/treat it as a pointer, adding @safe suddenly refuses to compile (Won't let you get the address); But if you leave it out (without @trusted either) and make main @safe, suddenly that doesn't compile either. (Because I'm sure quite a few functions you'd want to share will end up being @safe and pure). '&ref_arg' not being allowed in @safe mode is indeed a @safe-problem. But it's not easily fixable right now, because scope enforcement isn't done - so it would be too easy to leak a reference (pointer). Until it works with @safe, you can do @safe: auto func(ref int i) { @trusted check() { assert(!&i); } check(); /*rest of safe code*/ } void main() { int* i; func(*i); } which at least keeps the @trusted part to a minimum. Yeah, it should be possible to do just '@trusted assert(!&i);', ie have trusted scopes, not just functions; see http://www.digitalmars.com/d/archives/digitalmars/D/trusted_considered_harmful_173515.html . artur |
Copyright © 1999-2021 by the D Language Foundation