So I guess our choices are:
1. Reinstate (void) only where the warning occurs.
2. Reinstate (void) everywhere return values aren't checked. What a
nightmare.
3. Change defines such as the above to static inline functions.
Disadvantage: The inline keyword is not in the C89 standard.
I have ran the build tests and do not know of any other cases like
this. Certainly, a few more might show up but it is not an endemic
problem at the moment.
At its worst, it is only a warning.
The real problem here is not really that we may (or may not have) opened
up a bunch of new warnings. The issue here is that our QA process
sucks. We make enormous changes like this and commit it to master
without so little as verifying that the code compiles and or that it
builds without introducing new warnings. The code is just changed and
"thrown over the fence."
This is total unprofessional and must come to a stop. The way to bring
this to a stop is to complete the workflow definition and the
implementation of some nightly builld-everything step that has to happen
before any PR is committed. The fix is to improve our QA processes so
that this cannot happen.
But we have, apparently, lost interest in the workflow. Apparently,
Haitao Liu is working on something, but that is a black box. We have no
visibility of what is happening, what is being done in detail, when it
will be rolled out, or how it integrates with the unfinished workflow.
Greg
