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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,c689b55786a9f2bd
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news3.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!193.201.147.78.MISMATCH!feeder.news-service.com!85.214.198.2.MISMATCH!eternal-september.org!.POSTED!not-for-mail
From: Warren <ve3wwg@gmail.com>
Newsgroups: comp.lang.ada
Subject: Re: for S'Image use Func??
Date: Tue, 11 May 2010 21:08:26 +0000 (UTC)
Organization: A noiseless patient Spider
Message-ID: <Xns9D75AE5C7FB9AWarrensBlatherings@81.169.183.62>
References: <Xns9D7085FECB88EWarrensBlatherings@188.40.43.213>
 <op.vcaqajn0ule2fv@garhos> <Xns9D70A3756AAE0WarrensBlatherings@188.40.43.213>
 <wccmxwcu6kc.fsf@shell01.TheWorld.com> <op.vcaxs1h4ule2fv@garhos>
 <wcceihou455.fsf@shell01.TheWorld.com>
 <hs0jm5$vr4$1@news.eternal-september.org>
 <wcchbmjlx6a.fsf@shell01.TheWorld.com>
 <4be417b4$0$6992$9b4e6d93@newsspool4.arcor-online.net>
 <wccpr17yeji.fsf@shell01.TheWorld.com>
 <Xns9D747817630D6WarrensBlatherings@188.40.43.245>
 <zvtps4jzmo1z$.mzhapf4p7b4a.dlg@40tude.net>
 <Xns9D7482F0549D2WarrensBlatherings@188.40.43.245>
 <1qcb6z4i20dyb.1dz2hd4c0vx69.dlg@40tude.net>
 <b7b2dcd9-92d4-40f3-ab85-5c0dfdecb832@b7g2000yqk.googlegroups.com>
 <op.vcig7go1ule2fv@garhos> <Xns9D75873BB334DWarrensBlatherings@81.169.183.62>
 <op.vcj1lsgkule2fv@garhos>
Injection-Date: Tue, 11 May 2010 21:08:26 +0000 (UTC)
Injection-Info: mx01.eternal-september.org;
 posting-host="9f8M0iN5t54V+4DF/iqO8g";
	logging-data="24081"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1/60YZ/1XsiP1H9AGdK9VEZhrpjKNb2d6w="
User-Agent: Xnews/5.04.25
X-Face: 
 &6@]C2>ZS=NM|HE-^zWuryN#Z/2_.s9E|G&~DRi|sav9{E}XQJb*\_>=a5"q]\%A;5}LKP][1mA{gZ,Q!j
Cancel-Lock: sha1:V5oqDvucxjFJ4LYM3/s9A5KDLEU=
Xref: g2news2.google.com comp.lang.ada:11535
Date: 2010-05-11T21:08:26+00:00
List-Id: <comp.lang.ada>

=?utf-8?Q?Yannick_Duch=C3=AAne_=28Hibou57?= =?utf-8?Q?=29?= expounded in
news:op.vcj1lsgkule2fv@garhos: 

>> A pragma
>> won't fix the problem
> No language will fix the problem if you need a 8 bits file storage
> element  on a platform which uses something else.
> 
>> should it be different than a byte. Granted,
>> it will never likely come up on the platforms I have in mind.
> So, what' wrong ?

Why is this so difficult to understand?

POSIX systems do this all the time with the standard I/O
irregardless of what the machines "storage element"
unit is. 

What I'm suggesting is needed is a layer (pkg) that makes it
appear to the application that you can seek to byte
boundaries, get and write bunches of bytes, at arbitrary
byte lengths without a single care of whether the host
machine supports 32, 64, or even 36 bit words (I onced
did C on a Honeywell L66, with 9-bit bytes, 18-bit
half words and 36-bit words).  Yet the C I/O package
gave me the POSIX friendly FILE api to work with.

So I don't buy the "it can't be done" thinking. Move
away from Ada streams for a moment and think about 
what "could be done". 

All it requires is probably a thin layer on
top of Ada streams, except where they two are
one ;-)  The they can appear as two, but have
a common implementation.

> Ada will simply not be able to be POSIX friendly on platforms which
> are  not POSIX.

Have you tried cygwin and gnat? They work rather well in
its simulated POSIX environment. It breaks down in a few
"peculiar" places granted, but overall it's great on the 
company laptop, when the corporation sez "u must have windoze".

Warren