Re: [boost] [1.35.0] Intel compiler - does anyone care?

From: Beman Dawes (bdawes_at_[hidden])
Date: 2008-01-04 16:16:41

Peter Dimov wrote:
> Beman Dawes:
> 
>> Since we probably want to apply a fix that works with current compilers
>> in the field, we probably want to do something like this:
>>
>> #if defined(BOOST_INTEL) && defined(BOOST_DINKUMWARE_STDLIB)
>> # define _SECURE_SCL 0
>> #endif
>>
>> This should be applied to test programs, not to headers files. If it
>> were applied to header files (or added to the bjam toolset for Intel),
>> it would affect user code. Some users might actually want the Microsoft
>> mandated checking for their own code.
>>
>> Comments?
> 
> I don't agree. In principle, the tests should be a faithful representation 
> of reality; if a certain snippet of user code fails, so should the 
> corresponding test.
> 
> We can declare that we only support _SECURE_SCL=0, and run the tests with 
> that defined, but we should *not* hack the tests to pass under _SECURE_SCL=1 
> with the full knowledge that user code will fail under the same conditions.

I'm on the fence, but am willing to try that approach. It is simpler 
that anything that involves modifying each library.

> (Our other option is to patch the libraries for EDG == 3 && _SECURE_SCL.) 

Patch the standard library? That doesn't sound attractive.

Patch the Boost libraries? Bill Plauger suggested that as a possibility 
in a private email:

> 3) Avoid the problem by making the first two arguments
> the same type, as in std::copy(a + 0, a + 10, b), or by
> making the third argument a non-array type, as in
> std::copy(a, a + 10, &b[0]).

That seems pretty messy.

Let's go with the <define>_SECURE_SCL=0 approach, at least for now. I'll 
change the toolset, or get someone else to do it if I can't figure out how.

Thanks,

--Beman