comp.lang.ada
 help / color / mirror / Atom feed
From: Pascal Martin <pascal.martin@iname.com.nospam>
Subject: Re: Constraint or what?
Date: 2000/02/11
Date: 2000-02-11T00:00:00+00:00	[thread overview]
Message-ID: <o7Po4.101$m35.5175@typhoon.we.mediaone.net> (raw)
In-Reply-To: 38A2A395.FD028B73@alcatel.be

IMHO, the type is not a constraint type, because of the range <>.

The fact that the subtype T_BINARY_BUFFER_SIZE is given a
limited (?) range is pointless. From your code, we cannot even be
sure that this subtype does not have the same range as NATURAL.
Anyway, NATURAL itself is a subtype with a constraint, somewhat
equivalent to:

subtype NATURAL is range 0 .. INTEGER'LAST;

In this computer world, every integer has constraints..

What is important is that the size of type T_BINARY_BUFFER is
not statically defined (because of range <>).

Some compilers can consider this type as constrained if its size stays
small (but we cannot tell from your posting), "small" being implementation
dependent. Some other compilers, such as the Alsys ones, go the extra 
mile to deal with the size at execution time. The VADS compiler has 
the reputation to be strict and to make no specific effort whatsoever.

Another well known effect is stack overflow, because the VADS
compiler tends to reserve the maximum size if a static constraint
is not used, even for local variables.

BTW, in a somewhat related topic, I have been hit a few days ago 
by the following C code:

int i;

if (i < 0) i = 0 - i;
.. assume i >= 0 ...

On most computers, this does not work for 1 value: -2**31, 
as 0 - (-2**31) is equal to -2**31 (C int is a modulo type,
only because the machine happens to be so).
 
Sometime I really wish CONSTRAINT_ERROR exists in C !

This is to remind people that all numeric types have constraints,
and that using subtype with explicit limits change little to the
nature of the type. It merely change the actual value of the limits.

Pascal.


In article <87uojc$gav$1@nnrp1.deja.com>, reason67@my-deja.com wrote:
> In article <38A2A395.FD028B73@alcatel.be>,
>   Jan.Wuyts@alcatel.be wrote:
>> Hi guys,
>>
>> We're doing a port Alsys -> VADS or whatever they are called these
>> days.  This maybe a stupid question but I'll take the risk.
>>
>> The Alsys didn't complain on the construct below but the VADS one
> does.
>> I know about the restrictions on UNCHECKED_CONVERSION and the VADS
>> documentation says the target type cannot be an unconstraint array but
> I
>> assumed it was constraint.  So, why does the VADS compiler issue an
>> error...
> 
> I have seen this warning message in VADS and Apex (Same company). It is
> only a warning and should be disregarded. It brings it up based on the
> base type which is unconstrained, not the subtype which is.
> ---
> Jeffrey Blatt
> 
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.


-- 

------------------------------------------------------------------
Pascal F. Martin.






  parent reply	other threads:[~2000-02-11  0:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-02-10  0:00 Constraint or what? Jan Wuyts
2000-02-10  0:00 ` reason67
2000-02-11  0:00 ` Pascal Martin [this message]
2000-02-13  0:00   ` Robert Dewar
2000-02-18  0:00   ` Robert Dewar
2000-02-16  0:00 ` Ian Ward
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox