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=unavailable autolearn_force=no version=3.4.4
Path: 
 border1.nntp.dca3.giganews.com!backlog3.nntp.dca3.giganews.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!goblin2!goblin.stu.neva.ru!ecngs!feeder2.ecngs.de!newsfeed.freenet.ag!takemy.news.telefonica.de!telefonica.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Mon, 18 Nov 2013 16:51:50 +0100
From: "G.B." <rm-dash-bau-haus@dash.futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: strange behaviour of utf-8 files
References: <73e0853b-454a-467f-9dc7-84ca5b9c29b2@googlegroups.com>
 <1ghx537y5gbfq.17oazom68d4n6.dlg@40tude.net>
 <9d00683c-949c-4e88-a161-ebd78b350d39@googlegroups.com>
 <1w23uq33ul2i8$.wzjpp3evot36.dlg@40tude.net>
 <5288c584$0$6639$9b4e6d93@newsspool2.arcor-online.net>
 <k4o32tkp8lu4.1fuul1c08z90n$.dlg@40tude.net>
 <52891372$0$6636$9b4e6d93@newsspool2.arcor-online.net>
 <10ec0vuld83fy.1t7bduzwsrfe.dlg@40tude.net>
 <5289d34e$0$6637$9b4e6d93@newsspool2.arcor-online.net>
 <th9m0f0l1bgl$.1cx73kba9l2ks.dlg@40tude.net>
 <528a10a9$0$6564$9b4e6d93@newsspool4.arcor-online.net>
 <cqqsvt47bw75.1p0m0ibjkwyrz$.dlg@40tude.net>
In-Reply-To: <cqqsvt47bw75.1p0m0ibjkwyrz$.dlg@40tude.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <528a3796$0$6635$9b4e6d93@newsspool2.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 18 Nov 2013 16:51:50 CET
NNTP-Posting-Host: 966f1881.newsspool2.arcor-online.net
X-Trace: DXC=VVG7YFm35i]HigV@eW57PQA9EHlD;
 3YcR4Fo<]lROoRQ8kF<OcfhCO[<A`J>alo?o_nc\616M64>ZLh>_cHTX3j]3=ag\G^dXLS
X-Complaints-To: usenet-abuse@arcor.de
X-Original-Bytes: 3265
Xref: number.nntp.dca.giganews.com comp.lang.ada:183926
Date: 2013-11-18T16:51:50+01:00
List-Id: <comp.lang.ada>

On 18.11.13 16:25, Dmitry A. Kazakov wrote:
> Compare:
>
> 123 is a literal of Integer, mod 341, Unsigned_16, ... types

Compare

   type My_Int is range 1 .. 10
     with Size => 16;

to

   type My_Int is range 1 .. 10
     with Size => 32;


Now

   type My_Char is range 'A' .. 'Z'
     with size => 31;

to

   type My_Char is range 'A' .. 'Z'
     with size => 15;


And

   type My_Float is digits 6 range 0.0 .. 1_000.0
     with Mode => Round_To_Nearest_Even;

These are representation issues. They direct the compiler
to choose (a) a number of bits and (b) a set of operations.
"+" will be affected by 'Size, though not at the level of
abstract operations.

I guess there is a view that says rounding is a type? So what:

An encoding aspect would just be a means that allows programmers
to say what they mean. It may not be as useful as -gnatW*, it may even
be confusing, but it may finally kick the * of compiler makers and
project leads, and make them sort out this encoding nonsense once
and forever. Without rhetoric. And *then* they can say that
specifying aspects is fundamentally wrong.

After all, this is about interpreting a bit pattern at compile
time, and supplying information about the bits explicitly should
help. It should help fixing C's underlying char* issues, too.

Even when using 7bit ASCII, there is *no* information in the
source that explicitly states what is meant in a given ASCII
String literal. So, saying that ASCII works is just accidentally
right. A good argument in a C camp.