Message-ID: <36970016.E5F90ED9@idirect.com> Date: Sat, 09 Jan 1999 07:07:02 +0000 From: Karl Waclawek X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.beta Subject: Re: How to do low level stuff References: <368B8A70.CF9934FF@thestar.ca> <36950D20.2FAD4D18@thestar.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit NNTP-Posting-Host: oshawappp74.idirect.com X-Trace: 9 Jan 1999 02:07:35 +0500, oshawappp74.idirect.com Organization: via Internet Direct Lines: 54 Path: news.cs.au.dk!news.net.uni-c.dk!uninett.no!howland.erols.net!newsfeed.cwix.com!207.136.66.98!cyclone.news.idirect.com!island.idirect.com!relay.news.idirect.com!nemo.idirect.com!oshawappp74.idirect.com Xref: news.cs.au.dk comp.lang.beta:11780 Morten Grouleff wrote: > > Karl Waclawek writes: > > [...] > > > I thought BETA did not make specific assumptions about the size and > > the byte ordering of the basic types. From what your code shows, > > however, it seems that one can assume that char is stored in one Byte > > and that Integer is stored in 4 Bytes. > > Another comment on that one. It is not safe to make any assumptions on > the byte ordering of the basic types in memory. But as that is not > relevant for the CRC example, it works anyway. It would, however, be nice if there were conversion functions such that one could specify a memory layout for storing standard data types in an array of bytes. I am currently working on some DCOM based application where datasets are transferred from the server to the client using byte arrays. On the client I simply define the same type of record as on the server and typecast the byte array. This works because both machines run Windows (NT and 95) on Intel CPUs. If I went cross platform, I could only make it work if I had some control over how the different record fields were laid out in memory. > For the moments, an integer is 32 bits, but that may change, and when it > does, the CRC example will not work unchanged. > > In the next release of the Mjolner System, some new basic types are > introduced. These include signed and unsigned integers of sizes > 8,16,32,64 bits. There will also be a 16 bit wchar which is intended to > hold unicode chars. Excellent. Will those new types (or rather their byte sizes) be a feature of the Mjolner implementation or a part of the BETA standard itself? (I would prefer the latter). > In the long run char may change from 8 bits to 16 bits, so starting with > the next release, the 8-bit unsigned integer should be used rather than > the char type to represent a Byte. > > So in the short term, use integers as 32 bit entities and and char for > your 8 bit entities. Be prepared to change them into the specific > types when the next release arrives. When will that be? Karl ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Waclawek KD Soft Inc. * Phone: (905) 579-3443 * E-Mail: waclawek@idirect.com