[m-dev.] for review: subdivision of mercury_trace.c
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
> 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