Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix Issue 16589 - Taking address of stack variables in @safe code is … #6172

Merged
merged 1 commit into from Oct 7, 2016

Conversation

WalterBright
Copy link
Member

…allowed in some cases

@dlang-bot
Copy link
Contributor

Fix Bugzilla Description
16589 Taking address of stack variables in @safe code is allowed in some cases

@mathias-lang-sociomantic
Copy link
Contributor

Should it be part of -transition=safe ?

@WalterBright WalterBright force-pushed the fix16589 branch 3 times, most recently from 099677b to d91a93e Compare October 4, 2016 10:36
@WalterBright
Copy link
Member Author

Unfortunately, yes, as it is tripping in Phobos.

@mihails-strasuns
Copy link

Isn't it unnecessarily limiting though to implement this separately from DIP1000? It is perfectly valid to take address of the field and pass it to some function (expecting pointer) for processing, I would be very surprised if there isn't plenty of such code in the wild. Thus if it gets merged alone, it would break some legit use cases without a tool to make it work again (== scope).

@WalterBright
Copy link
Member Author

WalterBright commented Oct 4, 2016

It's been an error for years to take the address of a local in @safe code. It does not make sense to allow taking the address of a field of a local. This was not checked for, and that's what this PR does. It is not part of DIP1000.

It does break at least one Phobos function (the autotester quits at the first error), which is why I amended it to only check if -transition=safe, but the code is incorrect. Allowing this in @safe code breaks the whole point of ref.

If the user needs to & a local, the way to do it is by ref instead, or make it @trusted.

BTW, this rule nicely resolves the ambiguity of what return refers to with a parameter marked as return ref scope. If the function returns by ref, the return applies to the ref.

Copy link
Member

@andralex andralex left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Few nits to improve the lot of readers and reduce LOC.

@@ -10581,6 +10581,28 @@ extern (C++) final class AddrExp : UnaExp

type = e1.type.pointerTo();

bool checkAddressVar(VarDeclaration v)
{
if (v)
Copy link
Member

@andralex andralex Oct 6, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if (!v)
    return true; // nuttin' to do
... rest of the code ...

}
if (sc.func && !sc.intypeof && !v.isDataseg())
{
if (sc.func.setUnsafe())
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if + if = &&

if (sc.func && !sc.intypeof && !v.isDataseg() && sc.func.setUnsafe())
{
    ...
}

VarDeclaration v = ve.var.isVarDeclaration();
if (v)
{
if (!checkAddressVar(v))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if (v && !checkAddressVar(v))
    return new ErrorExp();

VarDeclaration v = ve.var.isVarDeclaration();
if (v && v.storage_class & STCref)
{
if (!checkAddressVar(v))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if (v && v.storage_class & STCref) && !checkAddressVar(v))
    return new ErrorExp();

VarDeclaration v = ve.var.isVarDeclaration();
if (v)
{
if (!checkAddressVar(v))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if (v && !checkAddressVar(v))
    return new ErrorExp();

@WalterBright
Copy link
Member Author

Auto-merge toggled on

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
5 participants