[m-dev.] for review: enforce namespace restrictions

Fergus Henderson fjh at cs.mu.OZ.AU
Tue Dec 5 14:16:22 AEDT 2000


On 05-Dec-2000, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> On 05-Dec-2000, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > +#define do_redo				MR_do_redo
> > +#define do_fail				MR_do_fail
> > +#define do_reset_hp_fail		MR_do_reset_hp_fail
> > +#define do_reset_framevar0_fail		MR_do_reset_framevar0_fail
> > +#define do_succeed			MR_do_succeed
> > +#define do_not_reached			MR_do_not_reached
> > +#define exception_handler_do_fail	MR_exception_handler_do_fail
> 
> Putting MR_ prefixes in front of label names is a bad idea, because the name
> that must be prefixed with MR is not the user visible name, e.g. do_redo,
> but the machine visible name, in this case _entry_do_redo. All your change
> did was to make the machine visible name _entry_MR_do_redo.

I'm afraid those names do invade the user's namespace, in ways that I
think you are unaware of, and hence they do need to be prefixed.

They invade the user's namespace in several ways.  Firstly, in grades
such as `none.*' and `reg.*', these names are user visible, because
they are defined as external symbols ("machine visible names") with no
`_entry_' prefix.  If the user were to define a symbol of the same
name, this could result in a link error or could prevent the Mercury
runtime version being linked in.  My change automatically checks for
these kinds of problems, and I happened to run a bootcheck in one of
the grades affected, which is how I managed to find the problem.

Secondly, in all grades, they are also declared in the header files as
global functions with no `_entry_' prefix.  If the user were to define
an entity with the same name in file that includes the Mercury header
files, then this would cause a compile error.  For example, including

	:- pragma c_code("
	int do_fail;
	").

in a Mercury module results in

	$ mmc nmtest.m
	nmtest.m: At top level:
	nmtest.m:14: `do_fail' redeclared as different kind of symbol
	/home/hg/public/mercury-latest/i686-pc-linux-gnu/lib/mercury/inc/mercury_engine.h:327: previous declaration of `do_fail'
	Error: system command returned non-zero exit status.
	Error: problem compiling C file.

Unfortunately my change doesn't automatically check for these kinds of
problems; I don't think there's any easy way to do that.  However, in
most cases these kinds of problems will be detected by the check on
externally visible symbols.

Note that my change treats `_entry' as one of the reserved prefixes
(along with `MR_', `ML_', `mercury_', `MERCURY_', and `GC_').

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------



More information about the developers mailing list