Greenwashing: best practices

Paul Backus snarwin at gmail.com
Sat May 30 22:00:27 UTC 2020


On Saturday, 30 May 2020 at 21:31:11 UTC, Johannes T wrote:
> Verified C functions require @trusted declaration when used in 
> safe code. It's a slight antipattern, similar to a bad comment:
> // implementation looks safe
> ssize_t recv(void*, size_t);
>
> Yes, @trusted is parsed and can be searched, that's not the 
> point. It's too far from the source code. What version was 
> vetted? Are we linking against an older one that leaked? Hard 
> to say without checking.

Realistically, if you're writing portable code, the version 
that's vetted is the version described by the documentation or 
standard that describes the interface you're programming to. So 
in this case, you'd refer to the POSIX standard's page on `recv`:

https://pubs.opengroup.org/onlinepubs/9699919799/functions/recv.html

If a particular version of a particular implementation on a 
particular platform has a bug, well, that's the implementation's 
problem, not yours. You can't possibly vet every version of 
`recv` that your code could ever be linked with (especially 
because some of those versions may not even exist at the time you 
do the vetting!).

> Declarations should reside in .di files and not be scattered 
> throughout D code. It allows us to keep .di closer to the 
> library and version it separately. If the version changes, 
> there is no need to search for affected D sources.
>
> Many bindings already do that. I wasn't aware of it and just 
> used extern(C) as needed.

As far as I know there's no advantage to using a .di file over a 
regular .d file for C bindings. It *is* a good idea to put 
translated C headers in their own files, rather than sprinkling 
declarations around willy-nilly, for the same reason it's good to 
put your C declarations in .h files, rather than sprinkling them 
around willy-nilly.


> To force unchecked functions to compile, the corresponding 
> declarations should be surrounded by @trusted { } block. The 
> block suggests it was rubber-stamped without audit. It's also 
> the path of least resistance for multiple functions. @trusted 
> should only be added to a single declaration if it was verified.
>
> I imagine being a C++ programmer trying out D and don't see 
> much inconvenience following this. More importantly, when the 
> program crashes, I would remember adding @trusted { } and can't 
> blame D's safety annotation.

Sure, I guess you could do this if you wanted to prototype 
something quickly and didn't care much about making sure it was 
100% memory-safe.

On the other hand, you could *also* just write the whole thing as 
@system, and leave migrating to @safe for later--at which point 
the compiler will bug you about your C function calls, and you 
can take the time to fix them *properly*. This has the advantage 
that you never give yourself a false sense of security by 
pretending code is @safe when it actually isn't.


More information about the Digitalmars-d mailing list