[test] [iostreams] 1.47.0 VC++ 10.0 warnings
A build of 1.47.0 using VC++10.0 is producing warnings from only a few libraries. It would be great if these were cleared so that this popular compiler builds Boost without warnings at the default settings. Thanks, --Beman boost\test\impl\execution_monitor.ipp(1078) : warning C4702: unreachable code boost\test\impl\execution_monitor.ipp(1082) : warning C4702: unreachable code boost\test\utils\named_params.hpp(74) : warning C4702: unreachable code boost\test\utils\named_params.hpp(78) : warning C4702: unreachable code boost\test\utils\named_params.hpp(86) : warning C4702: unreachable code libs\iostreams\src\file_descriptor.cpp(241) : warning C4800: 'int' : forcing value to bool 'true' or 'false' (performance warning) libs\iostreams\src\file_descriptor.cpp(265) : warning C4244: 'argument' : conversion from 'std::streamsize' to 'DWORD', possible loss of data libs\iostreams\src\file_descriptor.cpp(281) : warning C4244: 'argument' : conversion from 'std::streamsize' to 'DWORD', possible loss of data libs\iostreams\src\mapped_file.cpp(325) : warning C4244: 'argument' : conversion from 'boost::iostreams::stream_offset' to 'SIZE_T', possible loss of data libs\iostreams\src\mapped_file.cpp(59) : warning C4244: 'return' : conversion from 'const boost::iostreams::stream_offset' to 'size_t', possible loss of data
On 11 July 2011 16:48, Beman Dawes <bdawes@acm.org> wrote:
A build of 1.47.0 using VC++10.0 is producing warnings from only a few libraries. It would be great if these were cleared so that this popular compiler builds Boost without warnings at the default settings.
Since iostreams is unmaintained, the easiest solution would be to build it with a lower warning level. A handful of warnings are the least of its problems.
On 11 July 2011 18:19, Daniel James <dnljms@gmail.com> wrote:
Since iostreams is unmaintained, the easiest solution would be to build it with a lower warning level. A handful of warnings are the least of its problems.
On second thoughts, it'd probably be better to only include it in the build if it's explicitly asked for.
[Beman Dawes]
A build of 1.47.0 using VC++10.0 is producing warnings from only a few libraries. It would be great if these were cleared so that this popular compiler builds Boost without warnings at the default settings.
libs\iostreams\src\file_descriptor.cpp(265) : warning C4244: 'argument' : conversion from 'std::streamsize' to 'DWORD', possible loss of data libs\iostreams\src\file_descriptor.cpp(281) : warning C4244: 'argument' : conversion from 'std::streamsize' to 'DWORD', possible loss of data
These warnings are being emitted by VC10 because std::streamsize is now unconditionally 64-bit, for large file support. (Inevitably, we missed one tiny thing in VC10 so large files aren't supported perfectly everywhere - but it's much better than VC9 and already fixed in VC11.) Stephan T. Lavavej Visual C++ Libraries Developer
Hi Stephan,
These warnings are being emitted by VC10 because std::streamsize is now unconditionally 64-bit, for large file support. (Inevitably, we missed one tiny thing in VC10 so large files aren't supported perfectly everywhere - but it's much better than VC9 and already fixed in VC11.)
Out of interest would you mind providing a reference to the "one tiny thing"? I rely quite heavily on huge file support and have so far got away with switching off _all_ my VC8/VC9 workarounds for VC10! Also, by any chance, has https://connect.microsoft.com/VisualStudio/feedback/details/677738/ifstream-... come your way yet? ;-) Many thanks, Gareth ************************************************************************ The information contained in this message or any of its attachments may be confidential and is intended for the exclusive use of the addressee(s). Any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited without the express permission of the sender. The views expressed in this email are those of the individual and not necessarily those of Sony or Sony affiliated companies. Sony email is for business use only. This email and any response may be monitored by Sony to be in compliance with Sony's global policies and standards
[STL]
These warnings are being emitted by VC10 because std::streamsize is now unconditionally 64-bit, for large file support. (Inevitably, we missed one tiny thing in VC10 so large files aren't supported perfectly everywhere - but it's much better than VC9 and already fixed in VC11.)
[Gareth Sylvester-Bradley]
Out of interest would you mind providing a reference to the "one tiny thing"? I rely quite heavily on huge file support and have so far got away with switching off _all_ my VC8/VC9 workarounds for VC10!
http://connect.microsoft.com/VisualStudio/feedback/details/627639/std-fstrea... (internally DevDiv#90908). The offending macro was _FPOSOFF, used in basic_filebuf::seekpos() and fpos::operator streamoff(). I joined VC at the end of VC9's release cycle - when I learned that large files weren't unconditionally supported, I was horrified and baffled as to why nobody was screaming in agony. I really thought we had squashed it in VC10, then this macro reared its ugly head. This time, for sure, I think we've got it - but I'd appreciate it if people like you who rely on large file support would test the first public release of VC11 (whenever that will be). There's no way I want to mess with this again in VC12.
Also, by any chance, has https://connect.microsoft.com/VisualStudio/feedback/details/677738/ifstream-... come your way yet? ;-)
Yes, it's assigned to me (internally DevDiv#231211), as all C++ Standard Library bugs go through me. It looks like it might be a real bug (text mode isn't involved, the usual way people get into trouble), but I'm not a fluent speaker of iostreams Standardese. I'll send this to Dinkumware for analysis, once we get through our current batch of work. STL
Thanks for the quick response. [STL]
These warnings are being emitted by VC10 because std::streamsize is now unconditionally 64-bit, for large file support. (Inevitably, we missed one tiny thing in VC10 so large files aren't supported perfectly everywhere - but it's much better than VC9 and already fixed in VC11.)
[Gareth Sylvester-Bradley]
Out of interest would you mind providing a reference to the "one tiny thing"? I rely quite heavily on huge file support and have so far got away with switching off _all_ my VC8/VC9 workarounds for VC10!
[STL]
http://connect.microsoft.com/VisualStudio/feedback/details/627639/std-fstrea... (internally DevDiv#90908). The offending macro was _FPOSOFF, used in basic_filebuf::seekpos() and fpos::operator streamoff().
OK, so when I said _all_ my workarounds, actually I've been continuing to use boost::iostreams::position_to_offset() with VC10, which probably still solves the fpos::operator streamoff() mess... and the code in (VC10) basic_filebuf::seekpos() looks like it's trying to do the same thing as position_to_offset() so perhaps isn't broken? http://www.boost.org/doc/libs/1_46_1/boost/iostreams/positioning.hpp [STL]
I'd appreciate it if people like you who rely on large file support would test the first public release of VC11 (whenever that will be). There's no way I want to mess with this again in VC12.
Sure thing. :-) [Gareth SB]
Also, by any chance, has https://connect.microsoft.com/VisualStudio/feedback/details/677738/ifstream-... come your way yet? ;-)
[STL]
Yes, it's assigned to me (internally DevDiv#231211), as all C++ Standard Library bugs go through me. It looks like it might be a real bug (text mode isn't involved, the usual way people get into trouble), but I'm not a fluent speaker of iostreams Standardese. I'll send this to Dinkumware for analysis, once we get through our current batch of work.
Thanks! Gareth ************************************************************************ The information contained in this message or any of its attachments may be confidential and is intended for the exclusive use of the addressee(s). Any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited without the express permission of the sender. The views expressed in this email are those of the individual and not necessarily those of Sony or Sony affiliated companies. Sony email is for business use only. This email and any response may be monitored by Sony to be in compliance with Sony's global policies and standards
participants (4)
-
Beman Dawes -
Daniel James -
Stephan T. Lavavej -
Sylvester-Bradley, Gareth