Typical security issues in C++: why the GC isn't your enemy

areYouSureAboutThat areYouSureAboutThat at gmail.com
Tue Dec 13 01:16:48 UTC 2022


On Tuesday, 13 December 2022 at 00:56:12 UTC, Siarhei Siamashka 
wrote:
> On Monday, 12 December 2022 at 23:48:58 UTC, 
> areYouSureAboutThat wrote:
>> So how about a compile time, commandline switch, that (warns 
>> or fails) when @safe code is calling @trusted code?
>>
>> Basically, I'm, saying to the compiler -> "if it's not @safe, 
>> I do not 'trust' it."
>
> Then you will have this warning in pretty much every 
> application. Because any @safe code eventually ends up doing OS 
> kernel API calls to show stuff on your screen or save it to a 
> hard drive. The bridge from @safe to @system has to be crossed 
> somewhere and the code annotated as @trusted works as such 
> bridge.
>

Fair enough. But in that case, @unsafe would be a much better 
attribute than @trusted.

If you @trust code, you are presumably implicately trusting that 
it is memory safe.

Whereas, @unsafe, you're saying, look... I know it's not @safe, 
but I wanna use it anyway, even if that results in memory 
corruption.

D should move towards deprecating @trusted, and replacing it with 
@unsafe.



More information about the Digitalmars-d mailing list