Closed mclements closed 1 year ago
I am aware. I have no fix. I said I have no plan to edit BH manually:
edd@rob:~/git/bh(master)$ ag -c sprint inst/include/
inst/include/boost/asio/detail/impl/handler_tracking.ipp:3
inst/include/boost/asio/detail/impl/win_static_mutex.ipp:1
inst/include/boost/asio/detail/impl/socket_ops.ipp:11
inst/include/boost/asio/ip/impl/network_v4.ipp:3
inst/include/boost/asio/ip/impl/network_v6.ipp:3
inst/include/boost/asio/impl/connect_pipe.ipp:1
inst/include/boost/assert/source_location.hpp:1
inst/include/boost/lexical_cast/detail/converter_lexical_streams.hpp:6
inst/include/boost/test/utils/setcolor.hpp:2
inst/include/boost/test/impl/debug.ipp:2
inst/include/boost/test/impl/test_tools.ipp:2
inst/include/boost/compute/detail/parameter_cache.hpp:1
inst/include/boost/interprocess/detail/win32_api.hpp:1
inst/include/boost/xpressive/traits/detail/c_ctype.hpp:2
inst/include/boost/spirit/home/support/char_encoding/ascii.hpp:2
inst/include/boost/spirit/home/support/char_encoding/standard.hpp:2
inst/include/boost/spirit/home/support/char_encoding/iso8859_1.hpp:2
inst/include/boost/spirit/home/support/char_encoding/unicode.hpp:1
inst/include/boost/spirit/home/support/char_encoding/standard_wide.hpp:1
inst/include/boost/spirit/home/support/char_class.hpp:1
inst/include/boost/spirit/home/x3/support/traits/print_attribute.hpp:1
inst/include/boost/spirit/home/x3/support/traits/print_token.hpp:1
inst/include/boost/spirit/home/classic/core/primitives/impl/primitives.ipp:4
inst/include/boost/spirit/home/classic/core/primitives/primitives.hpp:1
inst/include/boost/regex/v4/c_regex_traits.hpp:1
inst/include/boost/regex/v4/regex_workaround.hpp:1
inst/include/boost/regex/v5/c_regex_traits.hpp:1
inst/include/boost/numeric/odeint/integrate/max_step_checker.hpp:2
inst/include/boost/core/lightweight_test.hpp:2
inst/include/boost/core/type_name.hpp:1
edd@rob:~/git/bh(master)$
That is from using the release candidate 1.81.0 described here: https://github.com/eddelbuettel/bh/issues/88
A closer look reveals that a few of them are in fact sprintf_s
(also safe) or preceded (in the case of Asio) by an #ifdef
for snprintf
so maybe I can get to this.
I am a little fearful of fat-fingering it but CRAN leaves me little choice I guess.
Some notes to self: Using ag
from emacs showing the matches reveals some are in comment. sprintf_s
is also fine
lexical_cast
seems gnarlier but points to a new (portable) boost::core:snprintf
in this Boost Core PR which may get combined with this PR in lexical_cast
.
Several other ones are easier.
Thanks for the gentle prodding. I created a new branch and the changeset is actually small and reasonable (apart from the issue mentioned in the previous comment, for which I found the proper treatment in that PR.
Testing this now, and with some luck this should be on CRAN soon after they reopen (and we take care of process in #88, i.e. let a small number of packages update) after which your issue will be taken care of.
Well done! (I was concerned that was going to be a much larger task.)
Thank you for this excellent package.
When including
boost/numeric/odeint.hpp
in therstpm2
package on CRAN, I get a warning "Found 'sprintf', possibly from 'sprintf' (C)" (https://cran.r-project.org/web/checks/check_results_rstpm2.html). A possible explanation is that https://github.com/eddelbuettel/bh/blob/master/inst/include/boost/numeric/odeint/integrate/max_step_checker.hpp#L72 and https://github.com/eddelbuettel/bh/blob/master/inst/include/boost/numeric/odeint/integrate/max_step_checker.hpp#L104 includestd::sprintf
calls. Is there a simple way to get around this warning? Any help with this would be appreciated.Sincerely, Mark.