[mercury-users] Circular lists

[Fergus Henderson]

On Thu, Nov 27, 1997 at 01:16:56PM +0100, Paul Massey wrote:
> 
> Fergus> Well, that's a fairly high price to pay.  If I have
> Fergus> to choose between efficiency and safety, for a
> Fergus> feature like the foreign language interface, I'd
> Fergus> rather have efficiency.
> 
> Efficiency depends on the frequency of use of the functions
> to be called. If it's called infrequently, I'd prefer to use
> a mega-safe version, but if it's very frequently I'd prefer
> the efficient version.

The other thing you have to trade off is complexity.
If the language has two different C interfaces, a safe one
and an efficient one, then things get a bit more complex.
It may be better to have a single C interface which is
reasonably efficient and moderately safe.

> Fergus> What exactly do you mean by safely here? 
> 
> Here's an example with a silly error in it:
> 
> ---------------------------------------------------------
> :- module t.
> :- interface.
> :- import_module io.
> 
> :- pred main(io__state::di, io__state::uo) is det.
> 
> :- implementation.
> :- import_module int.
> :- import_module list.
> :- import_module string.
> 
> main -->
> 	{ death(1,Out) },
> 	io__format("Do something = %d\n",[i(Out)]).
> 
> :- pred death(int::in,int::out) is det.
> :- pragma(c_code, death(I::in,O::out),"{ int sp0; sp=I; O=sp0;}").
> ---------------------------------------------------------
>
> With this I get no warnings that I'm doing something
> dangerous/stupid. My system just crashes at a later point

Ouch.  I stared at that for quite a while without figuring out what
the problem was.  That is indeed a nasty one.

The good news is that this one slippled silently by only because of a
combination of circumstances, some of which are in the process of being
fixed or have already been fixed, and others of which could be fixed
reasonably easily.

One of them is that the Mercury runtime C headers are not namespace-clean;
`sp' happens to be the name of a macro defined by the Mercury runtime.
We're in the process of fixing that at the moment, and in our
current development sources it has in fact been renamed `MR_sp',
which would be enough to catch that particular example.

Furthermore, the problem should also have been caught by the C compiler;
it should issue a warning for the use of the uninitialized variable `sp0'.
The reason that didn't happen was twofold.  Firstly, when we invoke gcc,
we turn off uninitialized variable warnings.  The reason for that
is that some of the code generated by the Mercury compiler for the
C interface causes spurious uninitialized variable warnings.
This could be fixed.  Secondly, for some unknown reason, even if you
do enable uninitialized variable warnings, gcc still doesn't warn
about that one.  I'm not yet sure why not; it might be a bug in gcc.

> (all sorts of very unhelpful messages about
> cygwin-exception-handler being called, etc, on my WinNT).

>From what I have heard on the gnu-win32 mailing list,
those unhelpful messages will be gone in the next release of gnu-win32.

> Given that the sp??? typo could be hidden in any piece of C
> code (in my code, the library or elsewhere) it could take
> alot of effort to find such a problem. So *my* programming
> efficiency drops. For me, I'd say a safe ELI means that *my*
> code being brain-dead or having typo's should not crash the
> Mercury system in a place over which I don't have any
> control.

As I noted earlier in this thread, that level of safety is
not achievable, at least not without jumping through fairly
ridiculous hoops like running all the C code in a separate
process.  If you write buggy C code that trashes random memory,
then it *will* mean that the other language your using can
crash in some unrelated part of the code.  For the Mercury C
interface to provide runtime protection against accessing
uninitialized variables would also be fairly complicated and costly. 
I think that sticking with existing static analysis tools for C
(e.g. `gcc -Wall') and/or existing dynamic analysis tools
for C (such as Purify) is a better approach.  The Mercury C
interface should do what it can to enable the use of those
tools, but it shouldn't attempt to duplicate their functionality,
IMHO.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>   WWW: <http://www.cs.mu.oz.au/~fjh>  
Note: due to some buggy software and a (probably accidental)
denial-of-service attack, any mail sent to me between
	Tue Nov 25 20:00:00 UTC (6am Wed, local time)
and	Wed Nov 26 06:00:00 UTC (4pm, local time)
may have gone into the bit-bucket.  Please re-send it.