[R-pkg-devel] question / concern regarding CRAN package policy regarding compiler warnings
Michael Gooch
goochm| @end|ng |rom gm@||@com
Tue Sep 10 19:32:29 CEST 2019
I was told to bring this issue to r-devel or r-package-devel. It appears to
me that package-devel is the more appropriate of the two for this issue.
referencing this RcppEigen issue:
https://github.com/RcppCore/RcppEigen/issues/74
I presume the line in the policy document: "Packages should not attempt to
disable compiler diagnostics, nor to remove other diagnostic information
such as symbols in shared objects." is what is driving this interpretation.
If there are other relevant policy lines I’m open to being disabused of my
errant understanding, but this one jumped out at me as a likely candidate
for what is driving this issue.
is their understanding of CRAN policy accurate? Would you really treat
wrapping directives so that they’re only used in appropriate circumstances
as if it were the equivalent to tampering with compiler diagnostics (such
as using a -Wno flag)?
to me this stance doesn't make very much sense, but I presume there had to
have been a lot of thought and reasoning put into this. I’d like to be
helped to understand this policy choice, as it applies to this specific
kind of issue (making sure that only supported preprocessor statements are
used as is generally viewed as appropriate when writing C / CXX code).
There is a difference between preventing the occurrence of an inappropriate
line of code (i.e. wrapping a pragma directive that some versions of a
compiler cannot understand or use and will issue complaints about in #if
conditionals that ensure the pragma will be understood by the compiler)
from being provided to the compiler / preprocessor / linker etc., and
merely silencing such a warning that the compiler would otherwise be
issuing (i.e. using a -Wno-warnings style flag to hide the complain, but
still leaving it fully visible in the source file, and thus not actually
addressing the error in syntax/usage for the particular compiler or
platform).
I do not think that that approach is equivalent to tampering with compiler
diagnostics, or suppressing a warning in the same way that using -Wno flags
would be, but i'm being told that CRAN will treat that as equivalent to
warning-silencing. Is this true? What is the justification for that stance?
It would seem to me that this policy choice results in bad programming
practices, such as leaving in preprocessor directives for platforms that
cannot understand them. In any other context, platform specific
preprocessor driven inclusion or exclusion of code to ensure that only
appropriate code is used for a given compiler or platform would likely not
be objected to, so why it be a problem in a case such as this?
Not providing a directive to the preprocessor when it is not appropriate
and not supported for either the platform or the compiler itself is not
tampering or disabling a diagnostic, it is making an appropriate choice so
as NOT to create an error in the code. It so happens that the compiler in
question can warn about the issue and proceed without preventing
compilation and functional use of the code, but the warning in this case is
still telling the developer that there is an inappropriate piece of code
present in the source, and that OUGHT to be something one can remedy by
detecting the compiler (and its version) and ensuring that only compilers
that support the directives are actually provided with those directives.
That doesn’t appear to be tampering, or a malicious/anti-social development
decision, that would seem to be an entirely appropriate and proper use of
the preprocessor.
Trying to silence the warning with a -Wno flag WOULD be doing that, but
wrapping the pragma in a conditional so that it only exists when it will
have a functional utility is not much different from having OS specific
implementation files optionally included or excluded from the source
dependent on the platform. It certainly WOULD have the net effect of the
warning no longer being issued, but that would be because the errant lines
are never provided to the preprocessor in the first place, which itself is
actually an error, and as such should NOT be the state of affairs that CRAN
policy demands.
it seems entirely backward from what one ought to expect the developer to
do.
If I am misguided in thinking that there is a difference between telling
the compiler to ignore/silence a warning, as opposed to preventing an
inappropriate line of code from being provided/used by the compiler in the
first place, please help me to understand, because I’m really having a hard
time seeing those as the same thing.
M. Gooch
[[alternative HTML version deleted]]
More information about the R-package-devel
mailing list