Assertion Fail error

This is a discussion on Assertion Fail error within the C Programming forums, part of the General Programming Boards category; Trying to compile a program with 2 source files and several headers, get the following error when I try to ...

1. Get rid of gets(). Never ever ever use it again. Replace it with fgets() and use that instead.
2. Get rid of void main and replace it with int main(void) and return 0 at the end of the function.
3. Get rid of conio.h and other antiquated DOS crap headers.
4. Don't cast the return value of malloc, even if you always always always make sure that stdlib.h is included.

1. Get rid of gets(). Never ever ever use it again. Replace it with fgets() and use that instead.
2. Get rid of void main and replace it with int main(void) and return 0 at the end of the function.
3. Get rid of conio.h and other antiquated DOS crap headers.
4. Don't cast the return value of malloc, even if you always always always make sure that stdlib.h is included.

> I seem to be able to compile other programs though
Yeah, that's what I would have guessed.

Is there anything peculiar about your source code?
- was it downloaded from somewhere?
- does it have any odd #pragma of __attribute__ syntax? (also check any local header files)
- what about inline assembler?

Do the objdump thing on known good .o files and .exe files, and see what formats they are.

Also compiling with the -v option allows you to see a lot more of what the compiler is doing (especially what options it passes to the linker). Compare with known good compilation runs.

> I can, but it is 650+ lines. For now I am just trying to narrow down the source of the error, looking for possible causes
So if you cut the body out of each function - except for necessary declarations for a return type/value say, would it still throw the same error?
The result would be easier to post if that were the case.

> I seem to be able to compile other programs though
Yeah, that's what I would have guessed.

Is there anything peculiar about your source code?
- was it downloaded from somewhere?
- does it have any odd #pragma of __attribute__ syntax? (also check any local header files)
- what about inline assembler?

Do the objdump thing on known good .o files and .exe files, and see what formats they are.

Doing objdump on working files shows that the files are of the same form.

But this code is in several files and does not cause a problem elsewhere.

I suspect the inline assembler is the issue. The source files were written for an m68k processor and had to be converted to be compiled for the i686. The only thing I had to change was the inline assembly in one of the files, which I may have done incorrectly. Here is the original code:

The first being that the linker is producing relocatable images, and it might be upset by an absolute address (just a guess, but download the binutils source and look at the source line of the assert to see what it is actually trying to do, and what is bad at that point).

Even if it compiled, actually calling that address at run-time would NOT do what you wanted.
Were these originally traps into the OS (or embedded RTOS) running on your m68k ?

You need to figure out what is the functional replacement for these asm inserts; not a minimal literal translation.

The first being that the linker is producing relocatable images, and it might be upset by an absolute address (just a guess, but download the binutils source and look at the source line of the assert to see what it is actually trying to do, and what is bad at that point).

Even if it compiled, actually calling that address at run-time would NOT do what you wanted.
Were these originally traps into the OS (or embedded RTOS) running on your m68k ?

You need to figure out what is the functional replacement for these asm inserts; not a minimal literal translation.