[m-dev.] constant strings

[Zoltan Somogyi]

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. 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. 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.

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 (although it shouldn't;
it should include just the files it needs).

The simplest solution would be for the high level C backend to use the same
representation for strings as the low level C backend, to make mercury.h
include mercury_string.h, 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,
and using a new header file for the first part. Is there a reason why you
didn't do one of these two in the first place, Fergus?

Zoltan.

[1] These include library__version as well as some predicates in
deconstruct, rtti_implementation, type_desc.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------