Discussion Thread: DIP 1028--Make @safe the Default--Final Review
Steven Schveighoffer
schveiguy at gmail.com
Wed Apr 8 17:01:29 UTC 2020
On 4/8/20 11:52 AM, aliak wrote:
>> If you see:
>>
>> @trusted extern(C) void memcpy(void *dest, void *src, size_t size)
>>
>> Then this is obviously wrong, and should be @system. It wouldn't be
>> any different for a @safe marking.
>
> Yes it would? If this was @safe I wouldn't need to check its usage
> sights because I'm supposed to trust that @safe can only be applied to
> functions that are mechanically checked. If it's @trusted then I know I
> need to check it's usage sights because it's not mechanically guaranteed
> to be a safe function.
There may be something you are missing. You can mark e.g. memcpy @safe,
and the compiler is fine with it. It will still link, and now be
callable inside @safe code.
The connection between the prototype and the implementation is MANUALLY
maintained for extern(C) code.
So if you saw @safe here, you should not be satisfied with it, as the
marking is probably wrong, but will still compile. You shouldn't say
"well, it's marked @safe, so memcpy must be @safe".
This is the whole problem with extern(C) prototypes -- you are allowed
to lie without consequence.
But in a lot of cases, D-implemented extern(C) code *is* @safe, so it
wouldn't be a lie.
-Steve
More information about the Digitalmars-d
mailing list