On Fri, 20 Jul 2001, Carlos Myers wrote:
> From: "George Greer" <greerga@circlemud.org>
> > On Fri, 20 Jul 2001, Carlos Myers wrote:
> >
> > >From: "George Greer" <greerga@CIRCLEMUD.ORG>
> > >> Who thinks the global buffers (buf, buf1, buf2, arg) need to go?
> > >> Who wants to keep them?
> > >> and why?
> > >
> > >Depreciate the buffers and remove all use of them from existing
> functions.
> > >Before the final release comes out, we can completely remove them then.
> >
> > Ok, but why? That was the important part of my question.
> >
> > I have my own reasons but I'll not state them yet.
>
> How about the off chance that one function will write data to one of the
> buffers. Then calls another function which overwrites the data in the
> buffer before the first function is finished with it.
>
Actually, that's not too 'off' of a chance. it already happens in
alot of code; prime examples are some of the error message logging code
(which usually use buf2 as the default error string).
Aside from that, it will eventually cause a problem with
programmers who are not aware of the system. Realize that you have to
know, at least intuitively, which functions use which buffers so that you
will not overwrite them from the calling procedure.
One bug related to this which I still can't quite lock down seems
to do with the combination of long message posts on boards, and
multi-attack combat, but I've seen it on just about every mud around.
Well, circle muds with boards and multi-attack. (Technically, any
page_string can/will cause this behavior, just that board usage occurs
more frequently.
Another thing to consider; using global buffers for inexperienced
programmers is like having a 5 yearold play with matches while sitting on
a heap of gunpowder. Even if they don't blow themselves up, they will
learn a dangerous precedent; in the future they will prefer to do things
like this, since it's how they have always done it.
Oh... had I said I was against global buffers yet?
Global buffers cause/increase the likeliehood of:
Reuse of global names as private names - obfuscation of code
Scoping errors - assumed that out of scope functions will not affect
them
Minor speed issue - Depending on compiler, global and static variables are
treated as if you'd included the keyword 'volatile'... and will
not be optimized. Think of it like this; if you access
or operate upon a global variable within the scope of a
function, the optimizer has to assume that the called
function can/will save that variable somewhere, and that
it may be modified as a side result. Because of that,
they can't use a single register to pass the the address between
functions, this means more time spent doing save/restores
between execution frames, as the (potentially same)
address is shuffled around.
Minor speed issue take 2 - EGCS takes an extra instruction to access
global variables instead of local ones, on the i686, and perhaps
others. Even without the specific i686 instructions, most
compilers depend on the programmer to optimise his/her
code to generate the most optimised assembly; just like
what intel did with their P4 model (and what AMD didn't!).
Pain-in-the-ass issue - Many global variables need to be accessed in other
files. You can't simply place the extern define in an
included header though, as simple as that may be, without
jumping through a few macro-hoops to get your .c file with
the definition of the variable to not crap out on it.
Instead, you end up declaring it extern in every file/for
each function. Because of the way some compilers work,
if you have conflicting types, and the definition of the
variable is not declared within a header, the compiler
will generally NOT check it; Testing shows there will be
warnings on most levels though. A bad prototype is worse
than code that won't compile.
Of course, the most frequent problem with global variables is
simply that someone else unthinkinkingly made them, when the information
contained therein has no reason to be globably accessable - and thus prone
to external access and modification (+ corruption). Perhaps you can mark
this as 'poor style' or 'idelogical differences', but it just is messy.
PjD
--
+---------------------------------------------------------------+
| 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