[m-dev.] Adding standard integer types

[Peter Moulder]

On Wed, Sep 17, 2008 at 02:07:50PM +1000, Peter Ross wrote:

> [I will add an existing portable stdint.h file as mercury_pstdint.h]
> and add to configure a test for stdint.h and if that doesn't exist we
> would fall back to using mercury_pstdint.h.

I suggest testing for both inttypes.h and stdint.h, as some machines have one
and not the other.  I suggest preferring stdint.h over inttypes.h when
both are present, if only because stdint.h is smaller.  I agree with the
suggestion of preferring the system one over pstdint.h, but could be
persuaded otherwise.


> Does anyone have any objections/improvements to this plan?

Only some questions:

What is the boxing behaviour?  (Or rather, what boxing behaviour would
we like (on 32-bit machines), and how can we get that?)

Do they have backwards modes (for converting from intN to Mercury int) ?

How does to_int8(260) behave?

If there's a backwards mode, then how do:
  `<int8 expression with value 4> = to_int8(X)'  and
  `<int64 expression with value 2**32 + 4> = to_int64(X)'
behave on 32-bit machines?

Any difference with unsigned versions?  (I ask just because of the C
approach where unsigned arithmetic is guaranteed to be modulo 2**n while
signed arithmetic has implementation-defined behaviour; so a C programmer
might expect to_uint8(260) to return 4 reliably even if they didn't expect
to_int8(260) to be safe to call.)

For comparison, int.m's public documentation says[*]:

   % The behaviour of a computation for which overflow occurs is undefined.
   % (In the current implementation, the predicates and functions in this
   % module do not check for overflow, and the results you get are those
   % delivered by the C compiler.  However, future implementations
   % might check for overflow.)

pjrm.


[*]: Actually I copied from just the old info file I have installed
 system-wide on this machine, but I remember it from long ago and I don't
 expect it to have changed or to change any time soon.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------