[Rd] typeof(getOption("warn")) is "integer" instead of "double" in R unstable (2019-09-27 r77229)? Reproducible?

[Tomas Kalibera]

On 9/29/19 6:12 PM, nospam using altfeld-im.de wrote:
> Thanks a lot for pointing out the reason
> (and yes, I am testing quite to stringent in this case - it's my old testing disease ;-)

Please note that it is not a good practice to test for these things in 
unit tests. Every system has some specified (or "documented" - in R) 
behavior, and then some unspecified. Programs must not depend on the 
unspecified behavior. If your programs do, then they should be fixed not 
to do so. If they do not, then there is no point in testing whether the 
unspecified behavior changed or seems to have changed. Also the 
existence of these tests often wastes time of the people who find out 
when these tests start failing (can be your time, but also CRAN, RCore 
or anyone else's). It is of course a good thing to check inputs in 
functions, e.g. in the actual code that uses an "option", to the point 
that is needed for correct execution of the code, but that neither that 
check nor the code should expect more than what is specified.

Best
Tomas

>
> For other readers:
>
> The R-devel NEWS is a good source to find possible change reasons:
>
> https://stat.ethz.ch/R-manual/R-devel/doc/html/NEWS.html
>
>
> On Sun, 2019-09-29 at 08:33 -0400, Duncan Murdoch wrote:
>> On 29/09/2019 7:55 a.m., nospam using altfeld-im.de wrote:
>>> Hi,
>>>
>>> I have a failing unit test in my package tryCatchLog on the CRAN build infrastructure
>>> (https://cran.r-project.org/web/checks/check_results_tryCatchLog.html)
>>> with "R Under development (unstable) (2019-09-27 r77229)"
>>> and the unit tests just ensures consistent behaviour of R (not of my package) as a precondition:
>>>
>>> The failing unit test is caused by
>>>> typeof(getOption("warn"))
>>>> [1] "integer"
>>> but it should be
>>>> [1] "double"
>> This is related to this bug fix:
>>
>> CHANGES IN R 3.6.1 patched BUG FIXES
>>
>>       ‘options(warn=1e11)’ is an error now, instead of later leading to C
>> stack overflow because of infinite recursion.
>>
>> which occurred in rev 77226.  It explicitly coerces the warn value to
>> integer.
>>
>>
>>> I have no build infrastructure for dev and want to find out if this is caused by
>>> - my mistake
>>> - changes in the R dev version
>>> - the new C compilers used (correlates with the failing unit test)
>> It is changes in the dev and patched versions, and also your mistake:
>> your test shouldn't be so stringent.  The docs don't say that the value
>> has to be a double; in fact, they suggest it should be a whole number
>> value (talking about 0, 1, "2 or more", not about what would happen with
>> options(warn = pi/2), for example.
>>
>> In older versions, options(warn = pi/2) is treated the same as
>> options(warn = 1), and in the new version, it is displayed as 1 as well.
>>
>> Duncan Murdoch
>>> Can somebody (having the R dev version available) please help me and answer the result of
>>>
>>>> typeof(getOption("warn"))
>>> using "R Under development (unstable) (2019-09-27 r77229)" or newer?
>>>
>>> Thanks a lot and sorry for the "noise"!
>>>
>>> Jurgen
>>>
>>> PS: These R (dev) versions did work as expected (returning "double") but were also using older C compilers:
>>> - R Under development (unstable) (2019-09-20 r77199)
>>> - R Under development (unstable) (2019-09-22 r77202)
>>> - R Under development (unstable) (2019-09-25 r77217)
>>> - R version 3.6.1 Patched (2019-09-25 r77224)
>>> - R version 3.6.1 (2019-07-05)
>>> - R version 3.6.0 beta (2019-04-15 r76395)
>>> - R version 3.5.3 (2019-03-11)
>>> - R version 3.5.2 (2018-12-20)
>>>
>>> ______________________________________________
>>> R-devel using r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel