On Tuesday, 26 May 2020 at 20:38:17 UTC, Bastiaan Veelo wrote:
On Tuesday, 26 May 2020 at 16:31:57 UTC, Bruce Carneal wrote:
Currently a machine checked @safe function calling an
unannotated extern C routine will error out during
compilation. This is great as the C routine was not machine
checked, and generally can not be checked. Post 1028, IIUC,
the compilation will go through without complaint. This seems
quite clear. What am I missing?
I agree that being forced to think about a trusted interface to
that routine can contribute to safety. Not getting this is the
price if DIP 1028 as is. Doing it the other way bears a
different price.
Still, it does not change the amount of code that must be
vetted during an audit, either way.
If you pick up 100% of the code that the post 1028 compiler lied
about, then I agree. Unsafe is unsafe even if your compiler stays
mum.
If you pick up less than 100%, I disagree. In that situation the
compiler will have "helped" you to reduce the amount of code to
be audited.
And finally, were the 1028 extern!(D) default changed to @system,
I disagree. The amount of code in non-greenwashed @trusted
wrappers should be smaller. (note that I discount the one time
audit of stable @system libraries)
