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,FREEMAIL_FROM,
	FREEMAIL_REPLY autolearn=no autolearn_force=no version=3.4.4
X-Received: by 10.182.216.232 with SMTP id ot8mr11663617obc.49.1432317092061;
        Fri, 22 May 2015 10:51:32 -0700 (PDT)
X-Received: by 10.140.36.232 with SMTP id p95mr97650qgp.17.1432317092035; Fri,
 22 May 2015 10:51:32 -0700 (PDT)
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!h15no7642695igd.0!news-out.google.com!k20ni44840qgd.0!nntp.google.com!z60no3249080qgd.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Fri, 22 May 2015 10:51:31 -0700 (PDT)
In-Reply-To: <mjnpkt$b6j$1@dont-email.me>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=78.27.123.114;
 posting-account=QrZwxQoAAAByl3YAWTpexAk3yBYyZMHn
NNTP-Posting-Host: 78.27.123.114
References: <mjlale$dpk$1@speranza.aioe.org>
 <127b004d-2163-477b-9209-49d30d2da5e1@googlegroups.com>
 <mjn90s$9av$1@dont-email.me>
 <f89a678a-f4a3-4a1c-91d7-d465177bbb1d@googlegroups.com>
 <mjnieh$ejn$1@dont-email.me>
 <ad8483c7-8f3c-4469-9079-a97ca3abaf27@googlegroups.com>
 <mjnpkt$b6j$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <59a4ee45-23fb-4b0e-905c-cc16ce46b5f6@googlegroups.com>
Subject: Re: Build language with weak typing, then add scaffolding later to
 strengthen it?
From: kalvin.news@gmail.com
Injection-Date: Fri, 22 May 2015 17:51:32 +0000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Xref: news.eternal-september.org comp.lang.ada:25956
Date: 2015-05-22T10:51:31-07:00
List-Id: <comp.lang.ada>

perjantai 22. toukokuuta 2015 20.40.52 UTC+3 Simon Clubley kirjoitti:
> On 2015-05-22, kalvin-nospamhere-.news@gmail.com <kalvin-nospamhere.news@=
gmail.com> wrote:
> >
> > My point here is that although an int is an int, an int in one context =
may be totally different from another int, although both entities are of ty=
pe int.
> >
> > For example, a low-level harddisk device driver might contain declarati=
ons like this:
> >
> > int cylinder =3D 1;
> > int head =3D 2;
> > int sector =3D 3;
> >
>=20
> What I would hope is that the designer uses unsigned integers for those
> variables and, in order to make the code portable across platforms, they
> used uint32_t and friends to encode within the program what the actual
> required size of those variables need to be.
>=20
> Simon.
>=20
> PS: This is _not_ a dig at you BTW but an observation on some C code
> that I have looked at. I don't like seeing see code use plain integers
> when an unsigned integer better models the problem at hand.
>=20
> --=20
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Microsoft: Bringing you 1980s technology to a 21st century world

Yes, I understand. I just wanted to make a point here, that an int should n=
ot be considered type compatible with another int if they are declared usin=
g different typedefs. Neverthless, my argument is still valid if I had used=
 unsigned int, uint16_t or uint32_t:

typedef uint16_t Cylinder;
typedef uint16_t Head;
typedef uint32_t Sector;

The variables of type Cyliner, Head and Sector should be treated by the com=
piler as incompatible and different types unless they are explicitly typeca=
sted.