id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc 6429,Wrong range checks in compiler/visualc.hpp,Ulrich Eckhardt ,John Maddock,"There is a problem with the range checks, in particular they don't recognize the MIPS cross-compiler of VC8 correctly. This problem is present in the trunk but also in older released versions. I found the issue ininially in 1.48. The problem there is caused by checks like _MSC_VER==1400 or _MSC_VER>1400. For the mentioned compiler, _MSC_VER is 1401 and it is bug-to-bug compatible with other 140x versions. Still, above checks fail to recognize it as such. The tests should be changed to _MSC_VER<1400 or _MSC_VER>=1400, with the assumption that all 14xx versions are compatible. Some more notes: * This doesn't only affect version 140x, but also others, see e.g. the code for versions 1200, 1201 and 1202. * I think this file merits a list of known _MSC_VER values and the according systems, or a pointer to it, and a note why _MSC_VER==1400 is bad. * Near the bottom, there is a check that tests <1200 to reject those pre-VC6 compilers right away. I'd move that up to the top, because it is required context to fully understand the rest of the file. * There is a #pragma that disables a warning ""..before we #include anything"", but this file doesn't include anything. I'm wondering if that couldn't simply be removed or at least moved. * There are a few cases where preprocessor code isn't indented. * There is a comment ""disable min/max macro defines on vc6:"" but no code associated with that. I guess the code was rendered obsolete, at least I don't see any NOMINMAX define there. * There is a macro BOOST_MSVC_FULL_VER, but that macro is not used there. Unless this is unused, I'd add a comment or reference to the according documentation. * There is one check that BOOST_MSVC == 1202. Why does that use BOOST_MSVC instead of _MSC_VER? I'd also comment that, I think this was due to some fault in the ARM cross-compiler for CE5, but I also seem to remember that there was a workaround. I'll try to see if I can recover the exact case from STLport's history/documentation, where I think the workaround originated. ",Bugs,closed,To Be Determined,config,Boost Development Trunk,Problem,fixed,wince,