Visual C++ "Debug Assertion Failed"

Question

I had compiled a code using Visual Studio 2010, then I tried to run it, unfortunately during testing sometimes I had errors "Debug Assertion Failed!"....Expression (unsingned)(c+1)<=256

Then I tried the same scenario but using gcc and it ran without any problem. any idea how about this problem?

Can be anything - actual code would be helpful to identify the problem. — sharptooth, Jan 16 '12 at 08:41
When you get a debug assertion, you usually get an alternative to enter the debugger. If you do that you might see what the problem is. — Some programmer dude, Jan 16 '12 at 08:43

score 6 · Answer 1 · answered Jan 16 '12 at 10:05

6

You're calling a function like isalpha() or isdigit() with an integer whose value is not a single byte 0-255.

answered Jan 16 '12 at 10:05

librik

3,738
1
19
20

Thank you all. I found that I use a function such as isalpha with an unicode character. – fattah.safa Jul 24 '12 at 21:02

score 3 · Answer 2 · answered Jan 16 '12 at 08:48

3

There is a piece of code that says "at this point, we expect the expression (unsigned)(c + 1) <= 256 to be true; if it isn't, please stop execution at this point and break into the debugger".

The method to break into the debugger is platform dependent and probably not implemented correctly for gcc. I'd look for this piece of code in the project and then try to find out why c is supposed to be less or equal to 255, and what makes it go out of range; letting the program run to the point where the assertion is triggered gives you an implicit breakpoint on the error condition, start with that.

answered Jan 16 '12 at 08:48

Simon Richter

28,572
1
42
64

Thanks a lot... your explanation makes sense..but what makes me confused is that I am working on a text file that has only character 0-255.. also why doesn't the same scenario with same files produce a problem with gcc ? – fattah.safa Jan 17 '12 at 06:32
There may be a problem, but you don't see it because the test is disabled. – Simon Richter Jan 17 '12 at 09:23
Actually, `glibc` implements the `` functions in a way that's designed to behave as it's commonly expected (though not required by the standard)... `-fsanitize=undefined` might change things, as this is a common UB issue, but you can find `glibc`s implementat of `toupper` [here](https://sourceware.org/git/?p=glibc.git;a=blob;f=ctype/ctype.c;h=6cb800077113a0bf8a58aff0c77df9bc7c0195f6;hb=HEAD#l50), where you see it just accesses an array using the value as an index... – autistic Aug 16 '18 at 07:28

score 2 · Answer 3 · edited Jan 30 '12 at 06:59

I found that the problem cause is that how each compiler declare character. In Visual Studio, the default is Signed char. So each character is signed unless you explicitly precede its declaration with unsigned word. So in VS the range of the character is -128 to 127, and if the read char has an ASCII greater than 128, it will have a negative code in VS. And since this case is not handled in the functions isalpha, isdigit, etc. the function will failed. In gcc, the used methodology to set char to sign or unsigned is something like dynamic pre-processor.

score 1 · Answer 4 · answered Feb 09 '16 at 11:24

You have fallen victim of undefined behaviour with regards to unexpected input of the <ctype.h> functions. According to section 7.4, paragraph 1 of the C11 standard:

In all cases the argument is an int, the value of which shall be representable as an unsigned char or shall equal the value of the macro EOF. If the argument has any other value, the behavior is undefined.

In other words, if x isn't in the range of [0..UCHAR_MAX] or EOF, you must not pass it to any of the <ctype.h> functions. The assertion being thrown is a rather courteous way of letting you know you've violated this rule; most would just let horrible things happen (e.g. I can imagine heartbleedish bugs).

Visual C++ "Debug Assertion Failed"

4 Answers4

Linked