From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,17395bd9bffaca19
X-Google-Attributes: gid103376,public
From: "Marin David Condic, 561.796.8997, M/S 731-93" <condicma@PWFL.COM>
Subject: Re: Ada95/Mil-Std-1553 Problem (Long Post - Sorry About That)
Date: 1997/01/20
Message-ID: <97012012282845@psavax.pwfl.com>#1/1
X-Deja-AN: 211074818
sender: Ada programming language <INFO-ADA@LISTSERV.NODAK.EDU>
comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
x-vms-to: SMTP%"INFO-ADA@VM1.NODAK.EDU"
newsgroups: comp.lang.ada
x-vms-cc: CONDIC
Date: 1997-01-20T00:00:00+00:00
List-Id: <comp.lang.ada>


Richard Kenner <kenner@LAB.ULTRA.NYU.EDU> writes:
>This isn't portable.  There's explicit implementation permission to
>reserve a particular space in a record for the tag (but not for any
>other internal field).  So a compiler is permitted to reject such a
>rep clause (GNAT will, for example).
>
    There's an additional problem - what you want to be able to do is
    figure out how many words are in the message, then do an
    UNCHECKED_CONVERSION of the message into your raw-word output
    buffer. If the tag info is in there at all, it a) gets counted in
    the word count and b) gets transferred to the buffer. (If you can
    guarantee it falls at the end, you could at least chop it off!)

    It would seem to me that the tag ought to be treated like array
    bounds - if an implementation keeps the bounds of an array with
    the array itself, all the usual clauses (like 'ADDRESS) are
    supposed to ignore that data.

    Using Streams seems to provide some mechanism for stripping out
    the tag info, but I haven't got the OO thing down far enough just
    yet to see how I could use it to get the contents of a message
    into a raw-word array where I can manipulate it. (Working on it in
    my "spare time". If I get an answer, I'll publish an example to
    whoever would like one.) I'm not sure this isn't going to involve
    moving the data twice or that it won't lead to grossly inefficient
    operation - but it seems like an area to start.

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        561.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        561.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
    "Languages don't kill people. *Programmers* do!"

        --  Rich Stewart - Language Lawyer & Language Control Opponent.
===============================================================================