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: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Community Input for the Maintenance and Revision of the Ada
 Programming Language
Date: Tue, 3 Oct 2017 15:24:49 -0500
Organization: JSA Research & Innovation
Message-ID: <or0rmh$9cp$1@franka.jacob-sparre.dk>
References: <oludae$seh$1@franka.jacob-sparre.dk>
 <915874b5-52c0-4aa8-9023-82fddedb816f@googlegroups.com>
 <op6odj$elu$1@gioia.aioe.org>
 <d5f3c820-1e9c-4a7d-9e2b-1981647180e5@googlegroups.com>
 <e3074266-6ebc-4eab-b0de-7fc1a4b5c7c4@googlegroups.com>
 <67345f73-530c-400b-9eb4-63eeb440154c@googlegroups.com>
 <b21832af-972a-4746-b9b1-9ea4a48bd196@googlegroups.com>
 <op868s$s5i$1@gioia.aioe.org>
 <9a6338d9-83be-4e45-b8b7-edc56e33537f@googlegroups.com>
 <op8cgh$183k$1@gioia.aioe.org>
 <2deb28e2-f7e8-4461-b8b8-c2c6cf2784aa@googlegroups.com>
 <op8iqd$1kg9$1@gioia.aioe.org>
 <5de470d2-aa3d-4c02-ae2b-266c33a289fe@googlegroups.com>
 <op8mio$1scc$1@gioia.aioe.org> <oqu5cf$vjv$1@franka.jacob-sparre.dk>
 <lywp4c7jur.fsf@pushface.org> <oqvlie$lh9$1@dont-email.me>
 <oqvnnn$19se$1@gioia.aioe.org>
Injection-Date: Tue, 3 Oct 2017 20:24:50 -0000 (UTC)
Injection-Info: franka.jacob-sparre.dk;
 posting-host="rrsoftware.com:24.196.82.226";
	logging-data="9625"; mail-complaints-to="news@jacob-sparre.dk"
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246
Xref: news.eternal-september.org comp.lang.ada:48326
Date: 2017-10-03T15:24:49-05:00
List-Id: <comp.lang.ada>

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:oqvnnn$19se$1@gioia.aioe.org...
> On 2017-10-03 11:34, G.B. wrote:
>
>> (But, still, predefined string types from the Ada library
>> depend on types Positive and Natural with their implementation
>> defined ranges. I understand that the 'Size of these types
>> is 16 in Janus/Ada?)
>
> I don't see this as a big problem so long you physically could not create 
> larger String objects, e.g. because of the memory architecture.

You can, however.

> It is not much different from Stream_Element_Array using 
> Stream_Element_Offset.
>
> Some time ago GNAT changed Stream_Element_Offset from 32 to 64 bits on 
> 32-bit machines. Same can be done for Integer.

There is no real problem in doing that, but it would make virtually all 
binary files (Sequential_IO, Direct_IO, and streams) incompatible. That's 
the main reason that we've never changed it.

> Anyway it brings back the argument of bounded-length strings design. The 
> size of Integer is not an issue for String because it acts as a 
> *constraint*, not as a type property. This does not make any program 
> illegal. So long you don't *actually* try to exceed the constraint, 
> nothing bad happens. It is not very likely you would actually use strings 
> larger than 32K.

I have, unintentionally in the spam filter. Spammers try to do everything 
possible in spam to break spam filters, and that includes sending messages 
without any line breaks. That has occassionally resulted in messages that 
exceeded the capacity of an Unbounded_String. (I used Unbounded_Strings to 
hold lines as an experiment; I consider the experiment failed, but changing 
the code is more work than it is worth.)

                              Randy.