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