[m-dev.] constant strings

[Fergus Henderson]

On 13-Jun-2003, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> The library contains a bunch of predicates[1] that return constant strings
> after casting away const, because MR_String is char *, not const char *.
> If the program ever tries to modify the returned strings, it will get a core
> dump: gcc places the string constant in the read-only data section, and the
> operating system traps (or should trap) writes to this section.
> 
> The obvious solution would be to copy the constant strings to the heap
> before returning them, instead of casting away const.

Hmm, that's not the obvious solution to me.  The obvious solution to me
would be to change the return type to MR_ConstString.

> Currently, this
> can't be done easily because in high level C grades, we (i.e. mercury.h)
> don't include mercury_string.h, and thus the macros defined there are not
> available.

mercury.h doesn't include mercury_string.h because the code generated
by the MLDS back-end doesn't refer to any of the entities declared or
defined in mercury_string.h.

If you want to add code in some places which explicitly refers to those
macros, then those places are the ones where mercury_string.h should be
included.

> Even the representation of string constants in C code differs
> between the low and high level C backends: in the low level backend,
> it is "MR_string_const((s), sizeof(s)-1)", while on the high level backend,
> it is just "(s)" (if s contains a C string), since MR_string_const isn't
> usually visible in hlc grades.

Although the representation used in automatically generated C
code differs, the two representations are compatible, because the
representation at runtime doesn't differ.

The difference in automatically generated C code results from a
difference in design philosophy between the MLDS and LLDS back-ends:
in the LLDS back-end, we made everything macro-ized, for greater
flexibility (e.g. allowing the same shipped C code to work in
different grades).  But in the MLDS back-end, I chose to deliberately
avoid the use of macros in the automatically generated code, to make
it more readable.  For example, in the MLDS back-end any grade-dependent
decisions should be made by the compiler front-end before generating
C code, not by #ifdefs in header files that define macros used in the
generated code.

> Actually, io.m now contains code that works only because of a long chain of
> includes. It uses macros defined in mercury_string.h without including
> mercury_string.h or mercury_imp.h (mercury_imp.h being the only header file
> in the runtime directory that includes mercury_string.h). This works
> in hlc.gc only because io.c includes deconstruct.mih, which includes
> mercury_deconstruct.h, which includes mercury_imp.h

To fix that, we should add an explicit include of mercury_string.h to io.m.

> The simplest solution would be for the high level C backend to use the same
> representation for strings as the low level C backend,

That would make the generated code less readable, and would go against
the MLDS design philosophy of (where possible) avoiding macros in the
generated code.

> to make mercury.h include mercury_string.h,

That is not necessary, since neither mercury.h nor any of the
automatically generated C code generated by the MLDS back-end
refers to entities declared or defined in mercury_string.h,
and I think it would therefore be undesirable.

> and to modify mercury_string.h to provide alternate
> definitions of the backend-specific macros for the high level C backend.
> Another solution is to draw the line somewhere in the middle of the current
> mercury_string.h, making some non-empty part of it (involving the macros
> for string constants, comparing strings and allocating/copying strings)
> backend independent while leaving the remainder LLDS-backend-specific,

Which parts of mercury_string.h are backend-specific?
AFAIK that code all works fine in MLDS grades, doesn't it?

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  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
--------------------------------------------------------------------------