BNLSConnection.cpp
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\cassert(9) : fatal error C1001: INTERNAL COMPILER ERROR
(compiler file 'msc1.cpp', line 2701)
Please choose the Technical Support command on the Visual C++
Help menu, or open the Technical Support help file for more information
Does anyone know what this is?
That happens if the compiler crashes while trying to compile something. Try working backwards from your most recent changes until you can find what caused it.
Figured it out. It was an assertion I made to check for SOCKET_ERROR on WSASend, but I don't see why that would cause the compiler to crash like that. Interesting...
As I recall, an ASSERT statement is a macro. Perhaps the code you had inside of the ASSERT() macro was causing the macro's internal parameterization code to fail?
Quote from: MyndFyre on November 11, 2004, 08:18 PM
As I recall, an ASSERT statement is a macro. Perhaps the code you had inside of the ASSERT() macro was causing the macro's internal parameterization code to fail?
assert(WSASend(
_Socket,
&WSASendBuffer,
WSASendBufferCount,
&dwBytes,
dwFlags,
&OverlappedSend,
cConnect->StaticSendCompletionRoutine
) == SOCKET_ERROR);The use of overlapped send completion routines was just experimental. There was really no use for it in my program, only for overlapped recv completion routines. However, it was odd that this statement caused the error.
On a partially related note, WSASend will return 0 if the send wasn't delayed, so that's an unwise assertion to make.
Quote from: Skywing on November 11, 2004, 09:11 PM
On a partially related note, WSASend will return 0 if the send wasn't delayed, so that's an unwise assertion to make.
Hmm, I see. I thought the only thing I should be careful of when just asserting a SOCKET_ERROR was WSA_IO_PENDING. Additionally, SOCKET_ERROR is defined as:
#define SOCKET_ERROR (-1) so why would a 0 return matter in this assertion? :)
Quote from: Mephisto on November 11, 2004, 09:20 PM
Quote from: Skywing on November 11, 2004, 09:11 PM
On a partially related note, WSASend will return 0 if the send wasn't delayed, so that's an unwise assertion to make.
Hmm, I see. I thought the only thing I should be careful of when just asserting a SOCKET_ERROR was WSA_IO_PENDING. Additionally, SOCKET_ERROR is defined as: #define SOCKET_ERROR (-1) so why would a 0 return matter in this assertion? :)
Umm.. it would matter because your program would die with an assertion on a perfectly valid situation?
Quote from: Skywing on November 11, 2004, 09:27 PM
Quote from: Mephisto on November 11, 2004, 09:20 PM
Quote from: Skywing on November 11, 2004, 09:11 PM
On a partially related note, WSASend will return 0 if the send wasn't delayed, so that's an unwise assertion to make.
Hmm, I see. I thought the only thing I should be careful of when just asserting a SOCKET_ERROR was WSA_IO_PENDING. Additionally, SOCKET_ERROR is defined as: #define SOCKET_ERROR (-1) so why would a 0 return matter in this assertion? :)
Umm.. it would matter because your program would die with an assertion on a perfectly valid situation?
Note: I was just experimenting with overlapped I/O for sending data. Also, if it returned 0 it wouldn't die because SOCKET_ERROR isn't 0. Unless I'm missing something here?
Quote from: Mephisto on November 12, 2004, 12:25 AM
Note: I was just experimenting with overlapped I/O for sending data. Also, if it returned 0 it wouldn't die because SOCKET_ERROR isn't 0. Unless I'm missing something here?
ASSERT assumes that zero is an error, causing your program to die.
Quote from: Mephisto on November 12, 2004, 12:25 AM
Quote from: Skywing on November 11, 2004, 09:27 PM
Quote from: Mephisto on November 11, 2004, 09:20 PM
Quote from: Skywing on November 11, 2004, 09:11 PM
On a partially related note, WSASend will return 0 if the send wasn't delayed, so that's an unwise assertion to make.
Hmm, I see. I thought the only thing I should be careful of when just asserting a SOCKET_ERROR was WSA_IO_PENDING. Additionally, SOCKET_ERROR is defined as: #define SOCKET_ERROR (-1) so why would a 0 return matter in this assertion? :)
Umm.. it would matter because your program would die with an assertion on a perfectly valid situation?
Note: I was just experimenting with overlapped I/O for sending data. Also, if it returned 0 it wouldn't die because SOCKET_ERROR isn't 0. Unless I'm missing something here?
1,) WSASend returns something besides SOCKET_ERROR.
2.) Computer cmp's returned result to SOCKET_ERROR.
3.) Evaluation is 0.
4.) Computer jz's to the assert() function.
Quote from: Mephisto on November 11, 2004, 08:33 PM
assert(WSASend(
_Socket,
&WSASendBuffer,
WSASendBufferCount,
&dwBytes,
dwFlags,
&OverlappedSend,
cConnect->StaticSendCompletionRoutine
) == SOCKET_ERROR);
As people have pointed out, I think you meant != SOCKET_ERROR, but even so: This is a very bad way to assert something. If you compiled that in release mode it would remove the assert statement, and your WSASend along with it!
If you need to assert the return value of a function, save it in a variable and do your assertion on that -- I wouldn't do that either, though. It's far better with this kind of thing to do some proper error checking, and report the error to the user if there is one. Mostly, I use assertions just to make sure I didn't pass a NULL pointer to a function by mistake, or similar.
Thanks everyone. :)