[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