comp.lang.ada
 help / color / mirror / Atom feed
From: "Marin David Condic" <mcondic.auntie.spam@acm.org>
Subject: Re: Endianness independance
Date: Mon, 3 Mar 2003 12:50:47 -0500
Date: 2003-03-03T17:52:10+00:00	[thread overview]
Message-ID: <b404oa$oim$1@slb6.atl.mindspring.net> (raw)
In-Reply-To: uu1ekigg5.fsf@nasa.gov

Well, yes, of course. Ada has excellent facilities for dealing with
representation and I did mention something about this elsewhere. My point is
that if System X programmed with Compiler X, Version X to target hardware X
thinks it is supposed to be sending a 16 bit integer to System Y programmed
with Compiler Y, Version Y to target hardware Y and Y thinks its supposed to
be receiving a 32 bit integer, you'll have a problem. Compiler X can't check
Source Code Y to make sure it got it right. The language could forbid the
very existence of 32 bit integers and solve the problem - except that Y
would then get programmed in something else. The only way to deal with the
issue is with some kind of verification external to the language. The
language definition can't fix this - except possibly by eliminating possible
representations and that only makes it useless in some contexts.

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "Going cold turkey isn't as delicious as it sounds."
        -- H. Simpson
======================================================================

Stephen Leake <Stephen.A.Leake@nasa.gov> wrote in message
news:uu1ekigg5.fsf@nasa.gov...
>
> The point is that Ada provides a _standard_, _single_ representation
> clause that works for both kinds of hardware:
>






  reply	other threads:[~2003-03-03 17:50 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-28 15:11 Endianness independance Lionel.DRAGHI
2003-02-28 16:10 ` Stephen Leake
2003-02-28 18:26 ` Marin David Condic
2003-03-01 10:48   ` Amir Yantimirov
2003-03-01 12:00     ` Simon Wright
2003-03-01 12:53       ` Jeffrey Creem
2003-03-01 17:26         ` Simon Wright
2003-03-01 12:47     ` Marin David Condic
2003-03-02  9:49       ` Amir Yantimirov
2003-03-03 13:29         ` Marin David Condic
2003-03-03 16:05       ` Stephen Leake
2003-03-03 17:50         ` Marin David Condic [this message]
2003-03-04  2:33         ` Jeffrey Carter
2003-03-04 17:50           ` Stephen Leake
2003-03-05  2:15             ` Jeffrey Carter
2003-03-05 17:37               ` Stephen Leake
  -- strict thread matches above, loose matches on Subject: below --
2003-02-28 17:21 Lionel.DRAGHI
2003-02-28 20:37 ` Randy Brukardt
2003-03-03 13:33 Lionel.DRAGHI
2003-03-03 16:11 ` Stephen Leake
2003-03-03 17:52 Lionel.DRAGHI
2003-03-03 20:29 ` Pascal Obry
     [not found] <BB06F6B19AC7D51181D10050DA725A10138C71@eoleclb.clb.tcfr.thales>
2003-03-03 18:38 ` David C. Hoos
2003-03-04 11:34 Lionel.DRAGHI
     [not found] <BB06F6B19AC7D51181D10050DA725A10138C75@eoleclb.clb.tcfr.thales>
2003-03-04 12:46 ` David C. Hoos, Sr.
2003-03-04 16:38   ` John Harbaugh
2003-03-04 21:25   ` Simon Wright
2003-03-05 17:28     ` Warren W. Gay VE3WWG
2003-03-05 20:15       ` Simon Wright
2003-03-05 21:54         ` Warren W. Gay VE3WWG
2003-03-05 17:49 David C. Hoos
2003-03-05 20:16 ` Simon Wright
2003-03-05 21:58   ` Warren W. Gay VE3WWG
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox