George Greer wrote:
> So as judge, jury, and executioner, I say good riddance:
> http://www.circlemud.org/~greerga/working/RIPbuffer.patch (~400kB)
> (The above is not the final version of the patch. I'm still doing other
> cleanups. The majority of the changes are how they will end up being.
> This will NOT be part of bpl19. Maybe bpl20.)
>
> Highlights of the changes:
>
> * send_to_*() functions are variable arguments and their arguments
> switched to having the string to send last.
>
> * act() is untouched.
>
> * mudlog() is variable argument and moves the string last.
>
> * 'buf, buf1, buf2, and arg' are gone. Dance on their graves.
>
> I'll probably throw a configurable switch in for people to keep the old
> buffers as a crutch but stock code will not use them. Their influence made
> many parts of the code disgusting. Part of the reason for the "Poll:
> global buffers" was to show people why the buffers were bad so they'd
> understand why the buffers were being ripped out. The more they
> understand, the less hate-mail I get. :)
>
> Other changes planned are eliminating sprintf(), strcpy(), and strcat() in
> favor of snprintf(), strncpy(), and strncat() with portability concerns
> address. I want to avoid the buffer overflow bonanza the code currently
> can be.
George,
If you are going through all this trouble, I would suggest installing your
buffer caching patch. I have had it running for a long time and most
(>99%) buffer overruns are TRIVIAL to find and fix. I would suggest that
everyone wishes to contiue to use globabl buffers stick a function like
this after every command call in interpreter.c:command_interpreter() and
throughout the heartbeat function:
int check_buffer()
{
if(buf[MAX_STRING_LENGTH+1] != MAGIC_NUMBER)
{
log("EMERGENCY REBOOT! BUFFER CORRUPTION");
close sockets/kill the mud;
return FALSE;
}
check rest of buffers;
return TRUE;
}
Yes, you should improve the logging and have to write some of the code, but
I use the buffer caching patch and it ROCKS!
--Angus
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/06/01 PST