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:
- Has to be marked @system or unmarked
- Has to call C functions that are unmarked
- 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