Re: buffer caching patch

From: Angus Mezick (
Date: 07/23/01

George Greer wrote:
> So as judge, jury, and executioner, I say good riddance:
> (~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.

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()
      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!

   | FAQ: |
   | Archives: |

This archive was generated by hypermail 2b30 : 12/06/01 PST