> This is my first post, I am all excited! > I use stock code with oasisolc and the enhanced editor > when i send mail the system stops the mud process and returns a message > saying that ASSERTION FAILED: mail.c line 208 > this is the line and the preceeding one: > 207: assert(sizeof(header_block_type) == sizeof(data_block_type)); > 208: assert(sizeof(header_block_type) == BLOCK_SIZE); > > i simply commented 208 and the problem is fixed!! (mail can be sent) > Now my question is: > Anyone has a clue about the consequences? I'd like to know what assert > does but you don't have to answer that. > Thanks > > Mehdi Keddache from NYC Assertions are a good way to make sure that code you release to the world doesn't break. For example, if I write an entire program assuming that n = 4, and release the code, someday someone somewhere can change n to 5 causing my code to fail. assert(n == 4) will make the program stop if n is not 4. The mail system is pretty hard to understand. It's from the summer of 1992 -- the first major piece of MUD code I ever wrote. It was part of the original CircleMUD 1.0 (i.e. when Circle was actually a MUD, not a code base). The mail system has its own mini "file system" so that all the mail sent of varying lengths can be stored somewhat efficiently in a single file. Remember, this code was written in '92 when 1.5 megs of disk space was all I could run a MUD in, so keeping disk usage down was a very high priority. These days, disks are cheap and brain cycles are expensive.. so if I was rewriting mail today, I would probably just keep the mail in plain text format, probably one file per receipient, the same way that UNIX stores mail in mail spools. I'm not going to get into a detailed description of the way the mail "filesystem" works, but suffice it to say that the mail file is broken down into 100-byte chunks, and each chunk can either be a "data block" or "header block". A piece of mail consists of exactly 1 header block followed by 0 or more data blocks. The blocks can appear in any order in the file; each block has a link to the next one. This works just like the DOS FAT scheme except that the next-block link is stored along with the data itself instead of in a seperate FAT as it is in DOS. To read a piece of mail one must first find its header block, then follow what can be thought of as a linked list of data blocks, with each block containing a pointer to the next. (The "pointer" is actually a file offset.) If you're still with me, it should be clear at this point that this scheme depends heavily on being able to do random access in the file to any block, and for this each block must be exactly the same length. The assertions in mail.c make sure that the definitions of the header and data blocks were not screwed with, because for header and data blocks to be different lengths would be fatal. You should never see this assertion fail in your code unless you've screwed with mail.c or mail.h. Jeremy
This archive was generated by hypermail 2b30 : 12/18/00 PST