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,5eeb9329d556031f X-Google-Attributes: gid103376,public From: "Theodore E. Dennison" Subject: Re: help - bit twiddling anomoly Date: 1996/05/11 Message-ID: <3195036A.2781E494@escmail.orl.mmc.com>#1/1 X-Deja-AN: 154985598 references: <3193C6C3.7FEC@ccgate.hac.com> content-type: text/plain; charset=us-ascii organization: Lockheed Martin Information Systems mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3_U1 sun4m) Date: 1996-05-11T00:00:00+00:00 List-Id: Dave Wright wrote: > > Any ideas why the following code behaves strangely (other than the > fact that its SUN SPARCworks Ada 2.1.1 running on a SPARC5 with > Solaris 2.4)? The only difference between the working version and the > broken version is 8 bits of storage (string(1..2) versus character) in > the unused object wdw. ... > with unchecked_conversion; > with v_i_bits; ... > brec.bit1 := inttobit(v_i_bits.bit_sll(int,(integer'size-onebit'size))); Since you are using a routine from the VADS internals (That's what the "v_i" stands for), perhaps you should be asking this question to the Rational technical support folks at mailto:support@rational.com Now if you are just looking for ideas, I'm guessing that you are having a byte-ordering problem. If the LSByte for your machine were to be somewhere other than the lowest address in the integer, then the unchecked conversion from integer to a one-byte type will put the LSByte somewhere off in never-never land. I'm also finding it curious that you are trying to declare a one bit integer. Ada 83 Integers weren't really meant to do that. That's the reason Boolean'size is 1. What I'd typically do is declare a packed array type of booleans. "AND" and "OR" work in bitwise fashion automaticly on such arrays. You still have endian issues to deal with, though (plus now you have to worry about how your compiler chose to order the bits). I'm sure you had good reasons for doing this, but it seems quite awkward in your little example. -- T.E.D. | Work - mailto:dennison@escmail.orl.mmc.com | | Home - mailto:dennison@iag.net | | URL - http://www.iag.net/~dennison |