buf, buf1, buf2, arg: J J & E

From: George Greer (greerga@circlemud.org)
Date: 07/21/01 

Now that we had the little "Poll: global buffers" to bat ideas around I'll
give my opinion on the global buffers:

Pro)

  1. Handy on the programmer to have instantly accessible buffer storage
     spaces for temporary strings.

  2. Reduces clutter in variable declarations.

Con)

  1. Will that function you're calling trash your buffer? Will it tomorrow?
     How about the function five levels down? Tomorrow?

  2. Variable name shadowing.  Is that variable name you just typed the one
     you meant it to be or did you write one not even used in this
     function? [1]

  3. Laziness.  Why write this loop cleaner when I can just throw it into
     the easy-access buffers available?

  4. API. If we need global buffers everywhere, we should be looking at
     _WHY_ we need the global buffers and fix that, not band-aid it by
     making them easily accessible.

and Jeremy's opinion:

"... those stupid global buffers are probably the dumbest thing I ever did.
Much more trouble than they're worth."

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 Greer
greerga@circlemud.org

[1] 4 instances of 'arg' being used instead of 'argument' in the stock code
    during the cleanup.  All indirectly due to SPECIAL() macro.

--
   +---------------------------------------------------------------+
   | 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