James Kanze <james.kanze@[EMAIL PROTECTED]
> wrote in news:b1725b32-e4b6-43d1-
8be1-33277dd1279a@[EMAIL PROTECTED]
> On May 13, 1:35 am, Paavo Helde <nob...@[EMAIL PROTECTED]
> wrote:
>> James Kanze <james.ka...@[EMAIL PROTECTED]
> wrote
>> innews:af6d7bb2-944e-4e8d-87eb-a74731b9f7ad@[EMAIL PROTECTED]
>
>> > On 12 mai, 08:15, Paavo Helde <nob...@[EMAIL PROTECTED]
> wrote:
>
>> > [concerning the _SECURE_SCL option in VC++...]
>
[...]
>> VC++ on XP crashes the application with the message "test.exe
>> has encountered a problem and needs to close. We are sorry
>> for the inconvenience.". If _SECURE_SCL is defined to 0, the
>> program runs nicely and produces the expected results.
>
> By shear chance, maybe. It's definitly something that you
> shouldn't be doing.
>
>> Example 2:
>
>> #include <vector>
>> #include <iostream>
>> #include <ostream>
>
>> double summate(const double* arr, size_t n) {
>> double sum=0.0;
>> for(size_t i=0; i<n; ++i) {
>> sum += arr[i];
>> }
>> return sum;
>> }
>
>> int main() {
>> std::vector<double> v;
>> // ...
>> std::cout << summate(&v[0], v.size()) << "\n";
>> }
>
>> This fails in the similar fa****on, but only on an im****tant
>> customer demo, where the size of array happens to be zero.
>
> And? It's undefined behavior, and there's no reason to expect
> it to work.
>
>> It appears that VC++ is warning me against potential problems
>> which might happen on exotic hardware (or on common hardware
>> in exotic modes), but does this on the most unpleasant way,
>> cra****ng on run-time the application which would have run
>> nicely otherwise.
>
> Or not. It certainly wasn't guaranteed to run nicely.
Programming is kind of engineering. In engineering you have to make
trade-offs in order to achieve your goals. Here, in this case I have a
large application which may contain UB similar to above cases. I have
tried hard to find and fix all UB, but one never can be sure. The UB of
the above sort does arise only if the size of vector is zero, which
usually does not happen. The code is complex and I'm not sure all corner
cases are correctly covered by unit tests. In other words, I believe that
the code is correct, but I am not 100% sure.
Now I have to deliver the final application (Release mode) to the
customer. The question is whether to keep the checked iterators feature
on or not. I have the following choices:
a) Keep the checked iterators on: this makes the program somewhat slower,
and if a corner case of this UB is encountered, the probability of a
customer sup****t problem appearing is 100%.
b) Switch them off: the code is faster, and if this corner case of UB is
encountered, the probability to have a customer sup****t problem is below
100% (0% by empiric evidence, but I will not stress that). The
probability of producing slightly wrong results is somewhat higher than
0, but also close to zero by my estimation, as the operation involved in
UB case most probably does not write anything to memory.
Of course, the decision also depends on the application domain. In a
safety-critical work you cannot live on probabilities. In our case my
favorite is clearly b).
>
>> Cite fromhttp://msdn.microsoft.com/en-us/library/aa985965.aspx
>>
>> "Checked iterators apply to release builds and debug builds.
>> ...
>
> Maybe, but I manage to turn them off or on at will. (I
> currently have them turned on in both release and debug builds,
> at least at present, but I rather suspect that I'll change this
> policy in the long. Basically, I use a common build for both
> release and debug, and offer an "optimized" build for the
> special cases where performance is an issue. And it does make
> sense to turn them off in the optimized build.)
Of course they can be turned off. In an earlier message in this thread
you said: "Any code which does anything with them
(_GLIBCXX_DEBUG and _SECURE_SCL) is invoking undefined behavior." Or do
you want to claim it is not UB if specified on command-line?
>
>> The default value for _SECURE_SCL is 1, meaning checked
>> iterators are enabled by default."
>
> The default value is only used if _SECURE_SCL hasn't been
> previously defined. If I invoke VC++ with -D_SECURE_SCL=0,
> there's no checking.
>
Yep, that's what the word "default" means.
[...]
>> And no, this is not simpler. For starters, VC++ wizards
>> generate code (can be deleted of course) to redefine the "new"
>> keyword in Debug builds, which would cause link errors when
>> attempting to link to the Release-build run-time library.
>
> In other words, no one in his right mind uses the wizards.
> Because the last thing you want is funny things happening with
> your keywords.
Agreed.
>> All modules exchanging dynamically allocated objects should
>> better be linked to the same run-time library - if the choice
>> is not the default one it is very hard to achieve. And by
>> abandoning the debug library one abandons also the debugging
>> features it offers.
>
> But all objects will be linked to the same run-time library,
> since you only link once. I think you're confusing issues
I have about 20-30 different DLL-s, which are all first linked once when
they are built, and loaded in the running application dynamically when
needed, thus completing the linking process. Different DLL-s may well
happen to be linked to different runtime libraries (as is the case for
static libs as well, but this can be controlled much better).
> somewhat: what you mean, I think, is that all of the modules
> must be compiled with the same options (at least with regards to
> those which can affect binary compatibility), and that the
> application must then be linked with a run-time library which
> was also compiled with those options.
Yes, that's easy, but this goes only for a single DLL.
>
>> Compared with the simplicity and flexibility of the Linux/ELF
>> dynamic linking process (cf. libefence) it's a shame. I know
>> your answer - use static linking and monolithic applications.
>> Unfortunately this is not always an option.
>
> Not always, I know. And when it's not, I've run into exactly
> the same problem under Linux, with g++. For that matter, I've
> run into it when statically linking as well---the problem is
> really independent of whether you link statically or
> dynamically. If sizeof( std::vector<double> ) is 12 in the
> calling function, and 28 in the library routine which receives a
> reference to it, problems will ensue.
Right.
> At any rate, I've just verified: /D_SECURE_SCL=0 in the command
> line does the trick. But you very definitely must be sure that
> all of the code using your library is compiled with this option.
> If you're selling a library to outside customers, this could be
> considered a very constraining requirement.
>
We are selling a complete application containing many libraries. In
principle the customer can develop and add their own libraries. OTOH,
they can also create custom applications using our libraries. Yes, it
might be appropriate to offer different versions. However, as you can see
we have hard times sometimes even to get the single version consistent...
Regards
Paavo
|
