STL: Destructor of Bugs

re: STL: Destructor of Bugs

Simon C — Fri, 29 Jun 2007 14:34:30 GMT

(Apologies for the gaps in my knowledge of the STL and its inner workings but...)

If my solution uses a mixture of 3rd-party LIBs and/or OBJs which may well have been built with different values for _SECURE_SCL, how am I to workaround this mixture of _SECURE_SCL=0 and _SECURE_SCL=1?? Do I need to wrap all 3rd-party objects in DLLs?

re: STL: Destructor of Bugs (std::deque)

Stephen Hewitt — Wed, 02 May 2007 05:13:48 GMT

QUOTE:

First, I should mention that the swap bug has now been fixed in Orcas! The fix applies to all Standard containers except std::string. Additionally, std::deque was broken even when _SECURE_SCL was disabled; it has also been fixed.

END QUOTE

Regarding Orcas:

I have to like with 2005. Can I gets fixed for that compiler?

Regarding deques:

You say the deque is broken even when _SECURE_SCL=0. Can you elaborate on this? Are you saying the deque is not usable if swap is called?

Regarding Service Packs:

Are any of there issues resolved by SPs? I've got SP1.

re: STL: Destructor of Bugs

michael henson — Sat, 07 Apr 2007 00:41:11 GMT

Stephan - I noted your blog post regarding stl bugs, specifically _SECURE_SCL. This note is more regarding your comment regarding compiling boost with _SECURE_SCL off. I figured out how to do this since I was having the same compatability issues myself. You can _SECURE_SCL off through editing this header:

\boost_1_33_1\boost\config\compiler\visualc.hpp

I just added the following to the start of the header.

#ifdef _SECURE_SCL

#undef _SECURE_SCL

#endif

#ifdef _HAS_ITERATOR_DEBUGGING

#undef _HAS_ITERATOR_DEBUGGING

#endif

#define _SECURE_SCL 0

#define _HAS_ITERATOR_DEBUGGING 0

This suits my purpose, though I did get a few build errors in a few libraries that I'm not using. Hope this was helpful. Keep up the informative blogging!

Michael Henson

re: STL: Destructor of Bugs

Stephan T. Lavavej — Sat, 10 Mar 2007 03:01:37 GMT

Yes, there are workarounds for the swap bug other than avoiding swapping or disabling _SECURE_SCL.

(First, I should mention that the swap bug has now been fixed in Orcas! The fix applies to all Standard containers except std::string. Additionally, std::deque was broken even when _SECURE_SCL was disabled; it has also been fixed.)

References and pointers don't trigger the problem, so using them is a workaround.

Another workaround is translating iterators to indices and back (for the random-access sequences). That is, if you have an iterator into a vector or deque, figure out what index it points to (index = iter - cont.begin()), swap the containers, and then get an iterator from the index (iter = other.begin() + index).

If you have further questions, feel free to E-mail me at stl@microsoft.com .

Thanks!

Stephan T. Lavavej

Visual C++ Libraries Developer

re: STL: Destructor of Bugs

Michel — Tue, 06 Mar 2007 12:44:11 GMT

Is there are work around to the _SECURE_SCL swap bug in release mode not involving recompiling the codebase including boost etc using _SECURE_SCL=0, and not rewriting your code not to swap containers?

/Michel

VC++ Roundup

RSS It All — Sat, 03 Mar 2007 08:13:32 GMT

Lots of VC++ happening recently (in no particular order): ATL Server is now shared source Marina Polishchuk

VC++ Roundup

ronpih's weblog — Sat, 03 Mar 2007 07:33:11 GMT

Lots of VC++ happening recently (in no particular order): ATL Server is now shared source Marina Polishchuk

re: STL: Destructor of Bugs

James Burgess — Wed, 28 Feb 2007 08:07:28 GMT

Stephan,

I would assume the linker just looks at the info in the .obj file (that the compiler flag /Zl controls) to determine which CRT's were specified at compile time. I'm going to take a wild guess that this mechanism isn't going to be extendable in any meanful way to solving the ODR problem. Too bad, seems like that was a special case of a set of ODR-like problems.

Don't worry, I wasn't holding my breath for a fix :-) We'll be dealing with this for years.

Too late now, but I would have preferred having yet another set of C++ runtimes to link against that would enforce (through undefined symbols) this flag one way or the other. That doesn't scale but nor does the notion of having switches that are quite this jagged and dangerous.

Cheers,

- James

The One Definition Rule

Stephan T. Lavavej — Wed, 28 Feb 2007 00:05:19 GMT

James,

That's not exactly a bug, but it certainly is a very sharp, jagged edge that you can cut yourself on.

The general problem is that the linker does not diagnose all One Definition Rule (ODR) violations. Although not impossible, this is a difficult problem to solve, which is why the Standard specifically permits certain ODR violations to go undiagnosed.

I would certainly love for the compiler and linker to have a special mode that would catch all ODR violations at build time, but I recognize that that would be difficult to achieve (and would consume resources that could perhaps be put to even better use, like more conformance). In any event, ODR violations can be avoided without extreme effort by properly structuring your code, so we as programmers can cope with this lack of linker checking.

However, macros that change the functionality of code by being switched on and off are flirting dangerously with the ODR, and the specific problem is that _SECURE_SCL and _HAS_ITERATOR_DEBUGGING both do exactly this. At first glance, this might not seem so bad, since you should already have control over which macros are defined project-wide in your build system. However, separately compiled libraries complicate things - if you've built (for example) Boost with _SECURE_SCL on, which is the default, your project must not turn _SECURE_SCL off. If you're intent on turning _SECURE_SCL off in your project, now you have to re-build Boost accordingly. And depending on the separately compiled library in question, that might be difficult (with Boost, according to my understanding, it can be done, I've just never figured out how).

What can we learn from this, other than (a) always remember the ODR, and (b) macros are evil (to quote the C++ FAQ Lite)? Well, I've observed something interesting: you are not supposed to mix object files compiled with different /MD, /MDd, /MT, /MTd options. But if you do, you get a LNK4098 warning! The linker has somehow been made to recognize this badness (since at least VC7.1, according to MSDN documentation). A casual glance at the source hasn't shown to me how this works, but it works somehow.

To be clear, I cannot promise (and you should not expect) that anything will change here. However, I will think about how we trigger this LNK4098 warning, and whether something like that might also be applied to _SECURE_SCL and _HAS_ITERATOR_DEBUGGING, so that it would be harder for silent badness to occur.

Thanks!

Stephan T. Lavavej

Visual C++ Libraries Developer

re: STL: Destructor of Bugs

James Burgess — Tue, 27 Feb 2007 22:23:59 GMT

Stephan,

Great that you are working on this. Speaking of catching errors early, one more "bug" I think the _SECURE_SCL code has is that it allows you to link an invalid set of compilation units together. That is you can link files compiled with and without _SECURE_SCL turned on. It would be nice if the linker forceably stopped you from making this mistake. The worst part is I have demonstrated it is possible the code that passes iterators between such units might run.