dip1000 and preview in combine to cause extra safety errors

[Steven Schveighoffer]

On 6/9/22 11:07 PM, Walter Bright wrote:
> On 6/9/2022 7:51 AM, Timon Gehr wrote:
>> Your are predicting that some people will explicitly do the wrong and 
>> lazy thing,
> 
> My experience is that the vast bulk of people will do the least amount 
> of effort. It's why software is always larded up with technical debt. I 
> do it, too. Yes, sometimes I've used duct tape and baling wire. Anyone 
> who claims they haven't, I don't believe :-)

In order for safe-by-default extern(C) to actually prevent code 
breakage, their code:

1. Has to be marked @system or unmarked
2. Has to call C functions that are unmarked
3. Has to all be actually @safe code (as checked by the D compiler) that 
they didn't mark as @safe.

1, and 2, I can see being true. 3 not so much. Especially if dip1000 is 
enabled.

They aren't going to bother with @trusted:, they'll just apply @system: 
to *all their code*, not just the extern(C) functions. Which is fine. 
That's actually the correct way to mark "I don't care about safety", and 
it's not lying.

Not to mention that we have lots of C modules like this: 
https://github.com/dlang/druntime/blob/ae0724769e3808398b3efdaed4ebdb59c676100d/src/core/stdc/stdio.d#L52

So even if you make `extern(C)` safe by default most C modules are 
ALREADY MARKED WITH `@system:`!! Will they not complain when `printf` 
can't be called from their hello world program? Hey, maybe they'll just 
declare a new `printf` prototype because that will now make it @safe!

> At some point all C functions have to be trusted in some form or other 
> because the D compiler has NO way to check them, and neither does the D 
> programmer. Putting `@trusted` on the C declarations accomplishes 
> nothing, it's safety theater.

Then you don't understand what @trusted or @safe means. Marking a C 
function @safe doesn't mean it's bug free. It means that it *obeys the 
rules of D @safe*.

I trust that the libc authors implemented `free` correctly. I don't 
trust that they completely disregarded the C spec and made it valid for 
D @safe. This means extern(C) calls that takes a `char *` must only read 
at most one byte from that pointer. This means that all arrays only can 
read one value from the array (because a C array is a pointer). This 
means that memory can never be freed, because it would leave dangling 
pointers. This means that `size_t` parameters accompanying pointers 
can't be used to judge how many elements of the pointer to read. This is 
not an exhaustive list.

> In druntime, we've gone through many (certainly not all) of the C 
> declarations and appropriately added correct annotations to them. But 
> realistically, this is not scalable.

I am completely lost here. How is it not scalable to go into every libc 
module of druntime and mark them with `@system:` at the top? I can do it 
if you want, it probably will take 10 minutes. Most time will be spent 
searching for already existing @system: attributes to skip having to 
attribute that module.

-Steve