[M3commit] CVS Update: cm3
Tony Hosking
hosking at cs.purdue.edu
Mon Feb 8 17:14:34 CET 2010
I am working on these issues right now. Stay tuned... It will be much cleaner than what Jay proposes.
Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484
On 8 Feb 2010, at 11:02, Rodney M. Bates wrote:
>
>
> Jay K wrote:
>> I wonder if we need
>> TInt8, TInt16, TInt32, TInt64, TInt, TLong
>> TWord8, TWord16, TWord32, TWord64, TWord, TLongWord
>> that accurately implement ints/words of the exact specified size,
>> with TInt/TWord/TLong/TLongWord depending on the target.
>> I wouldn't mind trying to remove this word "Word".
>> And replace it with UInt or such.
>> TInt, TUInt, TLong, TULong?
>> TSignedInt, TUnsignedInt, TSignedLong, TUnsignedLong?
>> TInt, TUnsignedInt, TLong, TUnsignedLong?
>> TInt.Zero is just always 8 bytes.
>> The size is I believe meant to be fairly opaque to the user.
>> This is the first I've noticed it being visible, such that TInt.EQ is true for values with "quite different" behavior. I would have "thunk" (thought without much thought) that anything TInt.EQ is more equivalent than they actually are.
>>
>
> Hmm. I recall in a discussion a while back that the arithmetic on
> target ints was not coded to handle operands with mixed values of
> n. Could this have something to do with this?
>
>> - Jay
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20100208/45793b4f/attachment-0002.html>
More information about the M3commit
mailing list