[M3devel] INTEGER

[Jay K]

Randy, This is correct.

 

Are we subtly suggesting that LONGINT be 128 bits on 64 bit systems, to avoid the creeping assumption that it is 64 bits? Seems ok, though it'd be some work in the compiler -- but maybe, again, a library based implementation, like how atomic is structured and possibly implemented.

 

Would anyone use this type? Or there'd be m3core/unix/32bit/types.i3 off_t = LONGINT, m3core/unix/64bit/types.i3 off_t = INTEGER?

 

And everywhere else anyone wanted a 64 bit type?

 

Or we would say off_t = BITS 64 FOR [(-?)16_800000000000L..16_7FFFFFFFFFFFL]? That is preferable since it avoids forking a file..though it might be incorrect. 16_800000000000L is positive if 128bits, and -16_800000000000L is correct for 128bits but overflows for 64 bits. I think maybe.

 

 - Jay
 
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Tue, 20 Apr 2010 15:56:26 -0400
> Subject: Re: [M3devel] INTEGER
> 
> >-----Original Message-----
> >From: Mika Nystrom [mailto:mika at async.async.caltech.edu]
> >Sent: Tuesday, April 20, 2010 1:13 PM
> >
> >5. Finally, is it the intention that LONGINT be fixed at 64 bits
> >forevermore? (See point 2.) This seems to completely fly in the face
> >of M3's philosophy. (See Hendrik's arguments.)
> > Mika
> 
> My "understanding" was that LONGINT would be a MINimum of 64-bits, but could be larger on certain platforms. For those platforms where the native integer size is already 64-bits, it could be possible that BITSIZE of INTEGER and LONGINT are indeed the same, 64-bits. It could also be that on some platforms we could have 64-bit INTEGER and maybe 128-bit LONGINT. Thus, the BITSIZE of LONGINT is both platform and implementation-dependent, but constrained to have a lower-bound of 64-bits. If I'm not understanding this correctly, someone please enlighten me.
> --Randy
> 
> 
> 
> 
> 
> CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.
> 
> EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements.
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100420/60243609/attachment-0002.html>