D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 15256 - Data races with arrays allowed in @safe code
Summary: Data races with arrays allowed in @safe code
Status: RESOLVED WORKSFORME
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D2
Hardware: All All
: P1 critical
Assignee: No Owner
URL:
Keywords: accepts-invalid, safe
Depends on:
Blocks:
 
Reported: 2015-10-29 09:10 UTC by anonymous4
Modified: 2022-10-13 08:00 UTC (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description anonymous4 2015-10-29 09:10:13 UTC 
@safe:
shared string s;
void f() @safe
{
	s="s";
}

A slice is stored with two mov instructions, so when the global variable is modified concurrently, it can end up with pointer from one array and length from another.
Comment 1 Jack Stouffer 2017-01-19 14:42:28 UTC 
This is more an issue with shared than with @safe. AFAIK @safe makes no guarantees when it comes to data races.
Comment 2 anonymous4 2017-01-20 12:42:18 UTC 
@safe exists to makes guarantees :)
And memory safety and data races are not shared's issues.
Comment 3 Jack Stouffer 2017-01-20 12:49:48 UTC 
(In reply to anonymous4 from comment #2)
> @safe exists to makes guarantees :)
> And memory safety and data races are not shared's issues.

Data races are absolutely shared's problem. The issue is shared has never been fully implemented. See https://issues.dlang.org/show_bug.cgi?id=14932

The only place you can see what shared is supposed to be is in Andrei's book "The D Programming Language".

@safe exists to ensure memory safety; data races do not fall under that umbrella.
Comment 4 anonymous4 2017-01-20 13:08:08 UTC 
If you corrupt memory in @safe code, then @safe fails, I think, this is specified pretty clearly, whether this happens due to sharing is unimportant. If shared should allow data races can be discussed in issue 14932.
Comment 5 RazvanN 2022-10-13 08:00:56 UTC 
If you compile with -preview=nosharedaccess than this code no longer compiles: "Error: direct access to shared `s` is not allowed, see `core.atomic`". Closing as WORKSFORME.