[serialization] VC++ compiler warnings
A 1.47.0 VC++ 10.0 build of Boost produced a lot of stupid warnings from Serialization in the form c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\xutility(2227) : warning C4996: 'std::_Copy_impl': Function call with parameters that may be unsafe - this call relies on the caller to check that the passed values are correct. To disable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 'Checked Iterators' These can be shut off various ways, such as sticking "#include <boost/config/warning_disable.hpp>" at the start of the file being compiled. If we could get rid of these serialization warnings, that leaves only a handful of VC++ warnings from other libraries. And those look trivial to fix, so I'll pester those folks too. It would be great if Boost default build produced no warnings for this popular compiler. Thanks, --Beman
Beman Dawes wrote:
A 1.47.0 VC++ 10.0 build of Boost produced a lot of stupid warnings from Serialization in the form c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\xutility(2227) : warning C4996: 'std::_Copy_impl': Function call with parameters that may be unsafe - this call relies on the caller to check that the passed values are correct. To disable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 'Checked Iterators'
These can be shut off various ways, such as sticking "#include <boost/config/warning_disable.hpp>" at the start of the file being compiled.
Hmmm - it would seem to me the easiest and least intrusive way to deal with this is tweak the bjam build script. I build an test with MSVC 9.0 which also has this "facility" and I don't get the errors so maybe the build script already has this in it. I'll look into it. Robert Ramey
[Beman Dawes]
A 1.47.0 VC++ 10.0 build of Boost produced a lot of stupid warnings from Serialization in the form c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\xutility(2227) : warning C4996: 'std::_Copy_impl': Function call with parameters that may be unsafe - this call relies on the caller to check that the passed values are correct. To disable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 'Checked Iterators'
[Robert Ramey]
Hmmm - it would seem to me the easiest and least intrusive way to deal with this is tweak the bjam build script. I build an test with MSVC 9.0 which also has this "facility" and I don't get the errors so maybe the build script already has this in it. I'll look into it.
By the way - these warnings are noisy, but they're not completely pointless. They're triggered by calling STL algorithms with raw pointers as output iterators, or with user-defined iterators that aren't marked as "checked". In VC10+, there's a targeted way to silence these warnings: #include <iterator> and pass stdext::make_checked_array_iterator(ptr, size) or stdext::make_unchecked_array_iterator(ptr). The former actually performs checking. The latter lies to the STL by saying that it performs checking when it actually doesn't, so as to silence the warnings while retaining maximum performance. For user-defined iterators, if you want to mark them as checked (either because they actually perform checking in debug mode like STL iterators do, or because you just want to silence the warnings), explicitly or partially specialize std::_Is_checked_helper to derive from std::true_type. You can even mark iterators as "conditionally checked", see reverse_iterator. VC8-9 had a much more confusing story here - as I recall, they lacked stdext::make_unchecked_array_iterator() completely, and the machinery for marking user-defined iterators as checked was utterly incomprehensible as well as totally undocumented. Stephan T. Lavavej Visual C++ Libraries Developer
On Mon, Jul 11, 2011 at 3:22 PM, Stephan T. Lavavej <stl@exchange.microsoft.com> wrote:
[Beman Dawes]
A 1.47.0 VC++ 10.0 build of Boost produced a lot of stupid warnings from Serialization in the form c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\xutility(2227) : warning C4996: 'std::_Copy_impl': Function call with parameters that may be unsafe - this call relies on the caller to check that the passed values are correct. To disable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 'Checked Iterators'
[Robert Ramey]
Hmmm - it would seem to me the easiest and least intrusive way to deal with this is tweak the bjam build script. I build an test with MSVC 9.0 which also has this "facility" and I don't get the errors so maybe the build script already has this in it. I'll look into it.
By the way - these warnings are noisy, but they're not completely pointless. They're triggered by calling STL algorithms with raw pointers as output iterators, or with user-defined iterators that aren't marked as "checked".
I'd appreciate warnings that catch bad pointers, but getting a warning just because I'm using a pointer is silly. What is the programmer expected to do? Be more careful? This reminds me of the "Baby on board!" stickers people put on their cars: do they target the careful driver who needs extra discouragement from crashing into cars? Or perhaps the reckless driver who would happily crash into you, except if you have a baby on board? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
[Emil Dotchevski]
I'd appreciate warnings that catch bad pointers, but getting a warning just because I'm using a pointer is silly. What is the programmer expected to do? Be more careful?
I think the idea was that everyone would use make_checked_array_iterator() (or, for vector/array destinations, write to them directly instead of through pointers). During VC8, the idea was also that checking in release mode was totally cool and wouldn't be a big deal. I had... differences with that, which is why VC10 release mode performs no checking. STL
On Mon, Jul 11, 2011 at 5:55 PM, Stephan T. Lavavej <stl@exchange.microsoft.com> wrote:
[Emil Dotchevski]
I'd appreciate warnings that catch bad pointers, but getting a warning just because I'm using a pointer is silly. What is the programmer expected to do? Be more careful?
I think the idea was that everyone would use make_checked_array_iterator() (or, for vector/array destinations, write to them directly instead of through pointers).
During VC8, the idea was also that checking in release mode was totally cool and wouldn't be a big deal.
I was kind of on board with that. Checking pretty much only causes performance problems when using std::vector, and even then, typically there is no problem as long as you don't use op[] for sequential access. When performance sucks, rather than turning off checking for all of STL, you can convert individual problematic cases to using pointers -- otherwise it is premature optimization. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Mon, Jul 11, 2011 at 4:35 PM, Robert Ramey <ramey@rrsd.com> wrote:
Beman Dawes wrote:
A 1.47.0 VC++ 10.0 build of Boost produced a lot of stupid warnings from Serialization in the form c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\xutility(2227) : warning C4996: 'std::_Copy_impl': Function call with parameters that may be unsafe - this call relies on the caller to check that the passed values are correct. To disable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 'Checked Iterators'
These can be shut off various ways, such as sticking "#include <boost/config/warning_disable.hpp>" at the start of the file being compiled.
Hmmm - it would seem to me the easiest and least intrusive way to deal with this is tweak the bjam build script. I build an test with MSVC 9.0 which also has this "facility" and I don't get the errors so maybe the build script already has this in it. I'll look into it.
The problem with lowering the warning level (as Daniel James suggested WRT iostreams) or in some way tweaking the build script is (1) Some warnings may be caused by coding errors, and the only way to determine that is to look at the code. At that point we might as well just fix the code to shut off the warning, thus signalling the developer understood what was happening and with that knowledge wished to suppress the warning. (2) Not everyone builds with b2 (previously known as bjam), so these folks benefit if the source of the warning rather than just some build setting quiets the warning, and (3) some (mistaken, IMO) organizational polices requires all code compile without warnings, so these folks are happier if Boost produces no warnings. It isn't a big thing, but where we are so close to a no warnings build, it seem worthwhile to take care of the few warnings remaining. --Beman
participants (4)
-
Beman Dawes -
Emil Dotchevski -
Robert Ramey -
Stephan T. Lavavej