[m-rev.] for review: avoid C warnings

Fergus Henderson fjh at cs.mu.OZ.AU
Mon Aug 19 15:29:42 AEST 2002


On 18-Aug-2002, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> On 14-Aug-2002, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > In general, declaring fields as `const' is probably not a good idea.
> > It makes it very difficult to dynamically allocate values of that type
> > (since there would be no type-safe way to initialize the const fields).
> 
> OK, I have declared as const only the fields (in unions, not structures)
> required to get rid of warnings. The updated diff follows.

Actually, you didn't declare those fields as const, you declared that
those fields *point to* const.

> After this diff, the only warnings I get during a hlc.gc bootcheck (not
> including the tests and the usual warnings from mmake) are warnings caused by
> the MLDS backend. In particular, the timestamp module defines an abstract type
> called "typestamp" that it privately defines to be a string. The functions
> in libs.timestamp.c treat values of type "timestamp" as MR_String; the
> functions in other modules treat those same values as if they had C type
> MR_Word. According to your post in the thread about my change to
> make_port_code, this is a significant problem, but it is one for you to fix.

This is an occurrence of the "abstract equivalence types" problem
that is indeed a very significant problem for the .NET back-end,
and is a potentially significant problem for the C back-end.

This problem is documented with an XXX comment in ml_code_gen.m:

% BUGS:
%       - XXX parameter passing problem for abstract equivalence types
%         that are defined as float (or anything which doesn't map to
%         `Word')

Unfortunately this one is very difficult to fix.

But fortunately there is now a work-around: compile with intermodule
optimization enabled.  (Actually I haven't tested this, but I
believe it should work now, and should make those warnings go away.)

> runtime/mercury_type_info.h:
> 	Declare the alternatives through which we initialize the MR_TypeLayout
> 	and MR_TypeFunctor unions of type_ctor_infos as const, to avoid
> 	warnings. This should be OK even if we start creating type_ctor_infos
> 	at runtime, because any type_ctor_infos created at runtime should be
> 	initialized through one of the other (non-dummy) alternatives.

The code changes to this file are fine, but the log message is misleading --
the primary reason this is OK is because you're only declaring that they
point to const, not that they are const.  It would be fine to assign to
the `init' member of the union at runtime.  So I suggest changing the
log message to

runtime/mercury_type_info.h:
 	Declare the alternatives through which we initialize the MR_TypeLayout
 	and MR_TypeFunctor unions of type_ctor_infos as `const void *'
	instead of `void *', to avoid warnings about initializers
	discarding const.

> runtime/mercury_builtin_types.c:
> 	Declare the unify/compare preds of the builtin types defined in this
> 	module as extern, not static,

s/,/./

-- 
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-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------



More information about the reviews mailing list