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

Zoltan Somogyi zs at cs.mu.OZ.AU
Wed Apr 15 15:10:30 AEST 1998

> However, you could make mercury_trace_cmd.h a module of its own,
> with mercury_trace_cmd.c containing only the definitions for the
> global variables declared in mercury_trace_cmd.h.
> This might be a better approach.

MR_trace() is declared in mercury_trace.h, and those types and
variables are *used* in MR_trace() and nowhere else (although
they are *assigned to* in other places), so having another module
define them would go against my sense of style. Also, this module
would have only some global variables in it, with no code to use
those variables, which is in itself bad. Hiding the variables
and accessing them via function calls would cause unacceptable
slowdown on what can be a very frequent event (calls to MR_trace).

> ANSI C forbids source file which are empty after preprocessing.
> This is a dumb restriction, but we should probably respect it.
> I'm not sure what the best fix is -- perhaps just moving the
> #includes out of the #ifdef.

We could always declare and define the exported functions,
and then make their implementations abort if MR_USE_EXTERNAL_DEBUGGER
is not defined. This way the space overhead will be minimal.


More information about the developers mailing list