On 5/27/2020 3:07 AM, Johannes Loher wrote:
This is a very specific situation. There are a lot of teams / developers
that do not work in this manner. I don't know the numbers so I will make
no statement about what is more common but my personal experience is a
different one.
I've seen larger companies operate this way. Smaller ones cannot afford to.
Also what is the difference between your QA department telling you to
correctly annotate C declarations and the compiler telling you that?
> If you expect people to ignore what the compiler is telling them, why do
> you expect them to listen to the QA department?
The QA dept is motivated to not be taken in by greenwashing.
(Back in my days at Boeing, I worked in the design department. There was an
entirely separate organization call the Stress Group. Their job was to sign off
on every nitpicky detail. If they signed off on something that turned out to be
wrong, it was bad for their careers. Your designs did not move forward without
Stress signoff. If you tried to trick Stress, that was the end of your career at
Boeing.)
So yeah, there's a huge difference between tricking the compiler and tricking
the QA department.
In my opinion, the
compiler actually _is_ one of the best QA departments.
Indeed it is, and that's the whole point to @safe. My motivation here is make
suspicious code stand out. @trusted code does not stand out so much, because it
is required to exist.
Also in my opinion, a competent QA department should carefully look at
any @trusted code /declarations. Maybe it is not a "red flag" but it is
definitely something that needs to be checked with extra care.
Looking at un-annotated declarations should be the first step. If it is
annotated with @trusted, at least there's the coffee stain on the drawing
indicating that somebody looked at it.
