[m-dev.] for review: subdivision of mercury_trace.c

Zoltan Somogyi zs at cs.mu.OZ.AU
Tue Apr 21 12:58:42 AEST 1998

> Hmmm.  Communication via global variables is in general bad,
> but that is how we're doing things currently.  A nicer solution
> might be to have MR_trace_event(), MR_trace_event_internal()
> and MR_trace_event_external() take a pointer to a command struct,
> rather than setting global variables.  The command could thus be
> a local static struct in MR_trace() rather than a set of global
> variables.  Then mercury_trace_cmd.h would just define a struct type
> rather than defining any global variables.

That's a nice solution, with two changes. One, MR_trace_event_external()
does not override any commands yet, so it does not need the parameteer yet.
Two, if all we are doing is defining a struct, then the typedef can go
in mercury_trace.h and we can avoid the second module altogether. Code
outisde the runtime won't be passed the struct, so it can't fool around
with it.

> Comments?  I'm happy to make this change myself if you're happy with it.

No, I will do it before checking it in.

> Sorry, I wasn't clear -- the restriction is only on .c files, not header
> files.  So you don't need to modify the header files in this way.
> I think just moving the #includes in the .c file out of the #ifdef
> is probably the simplest fix.



More information about the developers mailing list