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
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!peer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post02.iad.highwinds-media.com!fx26.iad.POSTED!not-for-mail
From: Shark8 <OneWingedShark@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64;
 rv:31.0) Gecko/20100101 Thunderbird/31.0a1
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Oberon and Wirthian languages
References: <1ljwj8f.1wqbhvuabsdw1N%csampson@inetworld.net>
	<51c7d6d4-e3be-44d5-a4ce-f7e875345588@googlegroups.com>
	<li9g34$9q8$1@dont-email.me>
 <%J32v.70539$kp1.45343@fx14.iad>	<lic17o$re4$1@dont-email.me>
 <8761m535e4.fsf_-_@ludovic-brenta.org> <liuc5i$tqc$1@dont-email.me>
In-Reply-To: <liuc5i$tqc$1@dont-email.me>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <VCz4v.92372$Dp4.89615@fx26.iad>
X-Complaints-To: abuse@teranews.com
NNTP-Posting-Date: Sat, 19 Apr 2014 18:53:41 UTC
Organization: TeraNews.com
Date: Sat, 19 Apr 2014 12:53:41 -0600
X-Received-Bytes: 3057
X-Received-Body-CRC: 1272888230
Xref: news.eternal-september.org comp.lang.ada:19441
Date: 2014-04-19T12:53:41-06:00
List-Id: <comp.lang.ada>

On 19-Apr-14 11:35, Jeffrey Carter wrote:
> On 04/19/2014 04:50 AM, Ludovic Brenta wrote:
>>
>> So, Oberon-14 or whatever its name is should not only reinstate
>> subranges but also allow the definition of incompatible scalar types.
>> If it did support all of the desirable features above then it would
>> effectively almost become Ada :)
>
> That would make the language unsuitable for its intended purpose of
> replacing C for S/W like OpenSSL.
>
> My experience (unfortunately on more than one example) of Ada designed
> and written by coders is that they eschew user-defined numeric types and
> numeric subtypes. They pick a few numeric types, predefined if at all
> possible, and use them for everything, just like C.

One of the problems is that specs have become dependent on C and C-ish 
terminology as an example, let us examine the basic definitions in TLS:

> 6.2.1.  Fragmentation
>
>    The record layer fragments information blocks into TLSPlaintext
>    records carrying data in chunks of 2^14 bytes or less.  Client
>    message boundaries are not preserved in the record layer (i.e.,
>    multiple client messages of the same ContentType MAY be coalesced
>    into a single TLSPlaintext record, or a single message MAY be
>    fragmented across several records).
>
>       struct {
>           uint8 major;
>           uint8 minor;
>       } ProtocolVersion;
>
>       enum {
>           change_cipher_spec(20), alert(21), handshake(22),
>           application_data(23), (255)
>       } ContentType;
>
>       struct {
>           ContentType type;
>           ProtocolVersion version;
>           uint16 length;
>           opaque fragment[TLSPlaintext.length];
>       } TLSPlaintext;

As we can see here the 'length' should not be "uint16", but instead:
	Range 0..2**14 {with a Size specification of 16 bits.}
Another illustration comes from the enumerations; for "ContentType" 
there are 4 possibilities, which means we could fit them into a 2-bit 
field -- but the size is unintuitively specified by the null-enumeration 
with a value of 255.