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.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,ca7e14ee1b312f90
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2003-04-27 22:04:13 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!arclight.uoregon.edu!wn13feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!sccrnsc04.POSTED!not-for-mail
From: "Steve" <nospam_steved94@attbi.com>
Newsgroups: comp.lang.ada
References: 
 <Hrdqa.9680$io.307974@iad-read.news.verio.net><UVlqa.620033$3D1.340565@sccrnsc01><NzPqa.24413$C%4.24334@fe10.atl2.webusenet.com>
 <yDRqa.638235$3D1.352789@sccrnsc01>
 <4VWqa.39167$b9.13645@fe07.atl2.webusenet.com>
Subject: Re: Minimum Record Size?  LONG
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Message-ID: <gD2ra.650405$F1.86415@sccrnsc04>
NNTP-Posting-Host: 12.211.13.75
X-Complaints-To: abuse@attbi.com
X-Trace: sccrnsc04 1051506252 12.211.13.75 (Mon, 28 Apr 2003 05:04:12 GMT)
NNTP-Posting-Date: Mon, 28 Apr 2003 05:04:12 GMT
Organization: AT&T Broadband
Date: Mon, 28 Apr 2003 05:04:12 GMT
Xref: archiver1.google.com comp.lang.ada:36674
Date: 2003-04-28T05:04:12+00:00
List-Id: <comp.lang.ada>

Maybe I'm dense, but I just can't see why the slice approach isn't endian
independent.  I would expect the mapping to be something like:

  Sixbit(1) bit 0 => Eightbit(1) bit 0
  Sixbit(1) bit 1 => Eightbit(1) bit 1
  Sixbit(1) bit 2 => Eightbit(1) bit 2
  Sixbit(1) bit 3 => Eightbit(1) bit 3
  Sixbit(1) bit 4 => Eightbit(1) bit 4
  Sixbit(1) bit 5 => Eightbit(1) bit 5
  Sixbit(2) bit 0 => Eightbit(1) bit 6
  Sixbit(2) bit 1 => Eightbit(1) bit 7
  Sixbit(2) bit 2 => Eightbit(2) bit 0
  Sixbit(2) bit 3 => Eightbit(2) bit 1
  Sixbit(2) bit 4 => Eightbit(2) bit 2
  Sixbit(2) bit 5 => Eightbit(2) bit 3
  Sixbit(3) bit 0 => Eightbit(2) bit 4
  Sixbit(3) bit 1 => Eightbit(2) bit 5
  Sixbit(3) bit 2 => Eightbit(2) bit 6
  Sixbit(3) bit 3 => Eightbit(2) bit 7
  Sixbit(3) bit 4 => Eightbit(3) bit 0
  Sixbit(3) bit 5 => Eightbit(3) bit 1
  Sixbit(4) bit 0 => Eightbit(3) bit 2
  Sixbit(4) bit 1 => Eightbit(3) bit 3
  Sixbit(4) bit 2 => Eightbit(3) bit 4
  Sixbit(4) bit 3 => Eightbit(3) bit 5
  Sixbit(4) bit 4 => Eightbit(3) bit 6
  Sixbit(4) bit 5 => Eightbit(3) bit 7

If you want to look at which "bytes" the results fall into, yes I agree that
it is endian independant, thus my remark about re-arranging the result.  I
still think my slice solution works for both endian machines.

I also find the use of shifts an accepatable answer.  I personally don't
like using multiplciation to do shifts.  Use the operation that describes
what you're doing.  Not something that gives the same result.

Steve
(The Duck)


"David C. Hoos" <david.c.hoos.sr@ada95.com> wrote in message
news:4VWqa.39167$b9.13645@fe07.atl2.webusenet.com...
> I haven't communicated my point very well.
>
> The slice approach is not endianness-independent.
>
> The arithmetic approach given by Tom Moran which was an
> improvement on my original submission is endianness-independent
> (as was my original submission).
>
> The point is that merely re-ordering the parameters to
> your procedure will not work on a big-endian machine
> without re-coding the procedure itself.
>
> The bit orders need to be reversed, as well.
>
[snip]