Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!julius.cs.uiuc.edu!wuarchive!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!pyrltd!tetrauk!rick
From: rick@tetrauk.UUCP (Rick Jones)
Newsgroups: comp.lang.eiffel
Subject: Re: Storing C pointers in Eiffel code
Message-ID: <1047@tetrauk.UUCP>
Date: 6 Dec 90 10:16:59 GMT
References: <1039@tetrauk.UUCP> <1990Dec5.171420.22935@bony1.uucp>
Reply-To: rick@tetrauk.UUCP (Rick Jones)
Organization: Tetra Ltd., Maidenhead, UK
Lines: 34

|In article <1039@tetrauk.UUCP> rick@tetrauk.UUCP I wrote:
|>
|>In another posting I show some examples of C code interfacing to Eiffel.  While
|>doing this work, I realised that there are problems of portability of Eiffel
|>code where external C addresses are involved.
|>
|n article <1990Dec5.171420.22935@bony1.uucp> richieb@bony1.UUCP (Richard Bielak) writes:
|
|What about using the BITS type to store address. Then you could have
|code like this:
|
|
|      some_address : BITS my_machines_address_size_in_bits;
|                                
|                                 ^
|                                 | this is constant of course

Nice try for a quick solution in the current language, but the trouble is it's
probably even LESS portable than using INTEGER!  The point is that I want the
same Eiffel source to compile and run on any system, ideally such that the C
package can be ported to a different architecture and still operate correctly.
This is perfectly possible if DATUM and the associated manipulations are
properly declared and used as a union in the C runtime code.

The last thing I want the Eiffel source to depend on is the ACTUAL size of any
machine's address word.

I really don't see how it can be done without a specific Eiffel datatype.

-- 
Rick Jones
Tetra Ltd.  Maidenhead, 	Was it something important?  Maybe not
Berks, UK			What was it you wanted?  Tell me again I forgot
rick@tetrauk.uucp					-- Bob Dylan


Brought to you by Super Global Mega Corp .com