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.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,d778a4f52acd9d43
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.205.139.10 with SMTP id iu10mr452076bkc.4.1325278590926;
        Fri, 30 Dec 2011 12:56:30 -0800 (PST)
Path: 
 cj8ni5028bkb.0!nntp.google.com!news2.google.com!news4.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Representation clauses for base-64 encoding
Date: Fri, 30 Dec 2011 22:56:29 +0200
Organization: Tidorum Ltd
Message-ID: <9m6mrtFgtjU1@mid.individual.net>
References: <slrnjf5uol.1lme.lithiumcat@sigil.instinctive.eu>
 <4ef31672$0$6574$9b4e6d93@newsspool3.arcor-online.net>
 <9lgls6FticU1@mid.individual.net>
 <4ef34839$0$7623$9b4e6d93@newsspool1.arcor-online.net>
 <slrnjf6kup.1lme.lithiumcat@sigil.instinctive.eu>
 <4ef3acd0$0$6642$9b4e6d93@newsspool2.arcor-online.net>
 <9lobhaF9adU1@mid.individual.net>
 <4ef9aaad$0$6643$9b4e6d93@newsspool2.arcor-online.net>
 <9lul3qFmgaU1@mid.individual.net> <wccmxadbv0f.fsf@shell01.TheWorld.com>
 <9lv3nvF57cU1@mid.individual.net> <wcclipwcian.fsf@shell01.TheWorld.com>
Mime-Version: 1.0
X-Trace: individual.net FvKo2Xn3W7xGP7DpWh/31wg/9a3eh6SsxMYmqs5vtjkcKRCnxP
Cancel-Lock: sha1:mIBOvnmZZ5yYZf9h2DblMmVv1oE=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:9.0) Gecko/20111222 Thunderbird/9.0.1
In-Reply-To: <wcclipwcian.fsf@shell01.TheWorld.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Date: 2011-12-30T22:56:29+02:00
List-Id: <comp.lang.ada>

On 11-12-29 02:50 , Robert A Duff wrote:
> Niklas Holsti<niklas.holsti@tidorum.invalid>  writes:
>
>> Yes, a compiler cannot claim to support annex C (Systems Programming)
>> unless it implements chapter 13 as recommended, so that all the
>> "shoulds" are implemented. But this is only an argument for "probable"
>> portability, since supporting annex C is optional.
>
> Right.
>
> But of course supporting the Ada standard is optional, too.  ;-)

Yes, but we are talking about Ada programming, which to me means using 
an Ada compiler that follows the standard. For me, the issue is what 
level of portability the standard provides; the actual current 
implementations are secondary.

> It's easy to forget that standards don't actually _require_ anybody
> to do anything.  So, unfortunately, the best you can be sure of is
> "probable" portability.

I hope you would agree that Standard.Integer "certainly" has at least 16 
bits in a conforming Ada implementation, so that is one point of 
"certain" portability. The portability of representation clauses is less 
certain, since conformance is optional. In contrast, package Interfaces 
and its shift operations are in the core of the language (RM 1.1.2(5)), 
to which all imoplementations shall conform (RM 1.1.2(17)).

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .