[m-rev.] for (possibly post-commit) review: simplify the creation of .int files

[Peter Wang]

On Mon, 18 Feb 2019 18:42:49 +1100 (AEDT), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> 
> On Mon, 18 Feb 2019 18:23:04 +1100, Peter Wang <novalazy at gmail.com> wrote:
> > What will happen if the programmer forgets to add the attribute on a
> > foreign type that is larger than one word? Because programmers WILL
> > forget, precisely because such types are rare.
> 
> That is a valid point. Maybe we want the opposite assertion:
> something that says "definitely not bigger than a word".
> That way, if you forget the assertion when it would be valid,
> you lose some performance, but preserve correctness.

Yes, as is the case with all (most?) other foreign type/proc attributes
so far.

> 
> In theory, this is still vulnerable to users adding a new platform
> with a smaller word size that would make such assertions invalid.
> We could guard against that by making the assertion "definitely
> not bigger than an N-bit word,  for N = 32 or 64. Then we
> apply the assertion on platforms with N or more bits in a word,
> and ignore it otherwise.

We may be able to generate static assertions to help catch problems when
the C code is compiled:

    MR_STATIC_ASSERT(module, sizeof(ForeignType) <= sizeof(MR_Word));

> > Not to mention existing
> > code that is not necessarily upgraded when switching compilers
> > (and you can't always force users to update to a compiler that
> > recognises the new attribute, though this is not a concern for most
> > Mercury programs).
> 
> This I don't understand. The proposed attribute is for Mercury,
> and people *can't* switch to another Mercury compiler. Or are you
> talking about people switching to an earlier version of mmc?

Yes, I meant switching between different versions of mmc. As discussed
above, any code written prior to the introduction of the "may be bigger
than a word" assertion would be suspect as soon as someone tried it with
a newer version of the compiler. I overstated when I said you "can't"
force users to update their compiler by updating the code -- you can,
but there may be reasons why you don't want to:

e.g. I have a MUA which is distributed in source form only. The users
are not Mercury developers or programmers, so it's my preference that
the MUA can be compiled with almost any version of the compiler they
manage to install -- fewer support questions for me. Users may have
installed the compiler though their package manager (most likely a
"stable" version) or they may have built it manually but quite a while
ago. It has not been difficult for me to maintain compatility back to
11.07 (could raise that to 14.01 now).

Peter