Can you post the definition of _SCL_SECURE_VALIDATE_RANGE?
>> Here it is. Any comments?
Question: Is it always defined like that, or is its definition dependent on some other symbol in the way that _HAS_ITERATOR_DEBUGGING is?
On closer inspection, if _SECURE_SCL is defined to 1, _SCL_SECURE_VALIDATE_RANGE is defined as George2 has posted. Otherwise it is simply defined as _SCL_SECURE_VALIDATE_RANGE.
Nothing, in other words.
So far as I see, _SECURE_SCL is not dependant on Release/Debug and defaults to 1 if not defined. It may be defined in other headers, however. Not sure.
In Debug, operator [] throws a fit several times (ASSERTs), does not throw.
at() throws in both debug and release.
if _SECURE_SCL is not defined, then release ignores invalid subscript ranges (go figure) (release).
Debug still complains about out of range.
And lastly, iterator debugging is defined in both release/debug and _SECURE_SCL is always defined to one inside vector header.
Hi Elysia,
Three more comments,
1. What is your conclusion? operator[] can throw in release mode?
2. I do not know quite understand what do you mean in the following sentence,
--------------------
In Debug, operator [] throws a fit several times (ASSERTs), does not throw.
--------------------
3. How _SECURE_SCL is defined or not? Is it implicitly defined when some other commonly used macros are defined?
You mentioned both throws and not throw. Sorry English is not my native language, what do yo mean? :-)
regards,
George
It still seems as if you can govern whether bounds checking is done with the _SECURE_SCL symbol.
Although given Microsoft's recent attention to security and avoiding things like buffer overruns, it wouldn't be that surprising if it now defaulted to range checking in release build.
Have you looked at the Microsoft documentation? That might have better information than trying to read though the code itself.
A flag sucks because somebody has to set it, and you never know which way it was set by the person before you.
So now I have to specify a fundamental design decision (whether the operator[] does bounds checks) every time I declare a vector?vector(bool bEnableExceptions = false)
I literally barfed on that one..#define SafeVector vector(true)
I expect cars to have seven cylinders, and be built entirely of fiberglass.I would expect the operator [] and the member function at both to throw exceptions if exceptions are enabled. Otherwise if they aren't enabled, none should throw (or make out of bounds checks).
Why would I want to give up all the conveniences of a std::vector and go back to dumb arrays just because I don't want bounds checking?I understand they want to keep C compability, but then you would be using a C array and not std::vector since that wouldn't even compile under C so not C project would ever use std::vector.
Correct.
Also correct. Bounds checking is done in release, as well. It doesn't throw, but it ASSERTs, unless _SECURE_SCL is defined to 0.
Yep, there's a whole topic on the subject. I have to study it and divulged all information first before reporting back.
No. Never. It can only raise an assert.
In debug, operator [] throws several asserts, one after another.
In release, only one assert is raised.
It's defined inside the vector headers as I can see. If not defined previously, it's defined to 1 by default, meaning enabled.
You can still define it to 0 before including the header and it will remain 0.
Throw = function can/will throw (for example, member function at(), both in debug and release).
Not throw = the function will not throw (operator [] for example, it will assert but never throw in either debug or release).
And that's why there should be the option of doing bounds checking or not. There could even be a function that says if bounds checking is on or off.
Don't know about URLs since I have MSDN installed locally. Anyway, the topic subject is "Checked Iterators". So search for that on MSDN.
They use a hardware interrupt, __asm int 3 on Intel & AMD processors.2. I am wondering how assert is implemented internally? Using some soft interrupt or through by exception handling approach?
something like
<removed copyrighted code, sorry - CornedBee>Code:#undef assert #ifdef NDEBUG #define assert(exp) ((void)0) #else #ifdef __cplusplus extern "C" { #endif _CRTIMP void __cdecl _assert(void *, void *, unsigned); #ifdef __cplusplus } #endif #define assert(exp) (void)( (exp) || (_assert(#exp, __FILE__, __LINE__), 0) ) #endif /* NDEBUG */
So it is just an __crtMessageBoxA call followed by _DbgBreak to start debugging
Last edited by CornedBee; 03-02-2008 at 07:04 AM.
All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
Here's another interesting tidbit.
There's another interesting define called _SECURE_SCL_THROWS.
If defined to 1, operator [] will throw an exception is it's out of range.
It also requires _SECURE_SCL to be defined as 1.
Microsoft also provides special functions in the library. They provide checked integrators (access will be checked) and non-checked iterators (access will not be checked).
If you've defined _SECURE_SCL to 1 (meaning you want checked access), all accesses will be checked. If you call functions that do not normally perform a check, you'll get a warning and still get checked access.
However, if it's defined to 0 (meaning you don't want checked access), you won't get any access check unless you you a checked iterator (checked_iterator), which is a Microsoft extension.
Thanks Elysia,
I know int 3 will make a H/W interrupt. And then invoke the interruption handler for int 3. I am wondering how does the assert dialog opens? Visual Studio registers or Windows registers the interrupt handler, and the interrupt handler's task is to display the dialog and some debug information?
regards,
George