How unchecked conversion works?

How unchecked conversion works?

[None]

HI! I'd like to know what the compiler do for represent a simple float 
for example 34,4 delta 0.1 into an integer type for example range 1..10 
using an unchecked_conversion. Thanks!

Re: How unchecked conversion works?

[Frank J. Lhota]

You would not use Unchecked_Conversion to convert a float to an integer. 
Basically, Unchecked_Conversion takes an object S of type Source and pretend 
it is an object of type Target, simply by assuming that an object of type 
Target resides at the same address as S. In other words, if we define

    function Convert is new Ada.Unchecked_Conversion( Source, Target );

    S : Source;

then the Ada call

    Convert( S )

does basically the same thing as the following C code:

    *( (Target *) &S )

Needless to say, the result of unchecked conversion depends heavily on the 
internal representation of the Source and Target types. This type of 
conversion is inherently risky in either C or Ada, which is why Ada makes it 
difficult to do unchecked conversions.

You almost certainly do not want to do an unchecked conversion to change a 
float into an integer. The integer resulting from such a conversion would 
have little to do with the original floating point number. Most likely you 
want to do a straighforward type conversion. For example:

    type My_Float is digits 6;
    type My_Integer is range 1 .. 10;

    S : My_Float;

Then we can convert S into a My_Integer value by writing

    My_Integer( S )

That's it!

Re: How unchecked conversion works?

[Keith Thompson]

None <none@none.it> writes:
> HI! I'd like to know what the compiler do for represent a simple float
> for example 34,4 delta 0.1 into an integer type for example range
> 1..10 using an Unchecked_Conversion. Thanks!

I'm not quite sure what you mean.  For one thing, a type declared with
"delta" is fixed-point, not floating-point.

Doing an Unchecked_Conversion from floating-point to integer is
unlikely to be useful.  An Unchecked_Conversion from fixed-point to
integer, on the other hand, might be; a fixed-point value is basically
a scaled integer, and Unchecked_Conversion might make sense if you
want to ignore the scaling.  (Nevertheless, you should spend some time
thinking about what problem you're trying to solve, and perhaps come
up with a cleaner way to do it.)

An Unchecked_Conversion call takes an operand of one type and pretends
that it's a value of another type.  This will typically be implemented
in machine code simply by doing nothing.  For example, if Conv is an
instance of Unchecked_Conversion, and X and Y are of appropriate types,
then this:

    X := Conv(Y);

will probably just copy the value of Y into X, just as

    X := Y;

would do if it were allowed.  (Presumably it isn't allowed because X
and Y are of incompatible types; otherwise you wouldn't need to use
Unchecked_Conversion.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.

Re: How unchecked conversion works?

[Larry Kilgallen]

In article <lnwtuhdkwc.fsf@nuthaus.mib.org>, Keith Thompson <kst-u@mib.org> writes:

> Doing an Unchecked_Conversion from floating-point to integer is
> unlikely to be useful.

Not in Ada, but within the innards of VMS there is (or was, I am not
sure) a place where this was done to get an efficient nonlinear
representation of an operating system value.

Re: How unchecked conversion works?

[None]

well, I try to explain. I have those types for example

type fixed is delta 0.03 range -90.0..90.0
for fixed'size use 16

and

type inte is range -32768..32767
for inte'size use 16


and a new function that renames unchecked_conversion to come from fixed 
to inte (probably an inefficient way, but I have to do this way), so I'd 
like to predict on paper which value of inte type corresponds to 89.09 
for example: what kind of calculus should I do? This depends on 
something else? Thanks again!

Re: How unchecked conversion works?

[Marius Amado Alves]

As others have said, don't use unchecked_conversion for this.
And yes, the result value if of course predictable, namely as per 
section 3.4 of the RM, enigmatically entitled "Type Conversions":

"If the target type is an integer type and the operand type is real, the 
result is rounded to the nearest integer (away from zero if exactly 
halfway between two integers)" (33)

Re: How unchecked conversion works?

[Mark H Johnson]

None wrote:

> well, I try to explain. I have those types for example
> 
> type fixed is delta 0.03 range -90.0..90.0
> for fixed'size use 16
> 
> and
> 
> type inte is range -32768..32767
> for inte'size use 16
> 
> 
> and a new function that renames unchecked_conversion to come from fixed 
> to inte (probably an inefficient way, but I have to do this way), so I'd 
> like to predict on paper which value of inte type corresponds to 89.09 
> for example: what kind of calculus should I do? This depends on 
> something else? Thanks again!

The specific answer will likely be compiler specific so you may need to 
write a test application to verify the result. Let me see if I can 
explain why...

One choice - the compiler chooses to represent value as 1 == your delta 
value (0.03) and scale everything appropriately. Then 90.0 is 
represented by 3000 (decimal) since
   3000 * 0.03 == 90.0
So you have a range of values +/- 3000 when you do the unchecked 
conversion. Pretty straight forward implementation for your problem.

Another choice - the compiler chooses to make 'Small of your datatype 
not equal to 'Delta of your data type (this IS allowed in ARM 3.5.9). 
Since you did not request a decimal fixed point value, 'Small will be a 
power of two smaller than 'Delta. If my arithmetic is correct, that 
could be something like 1/64 (0.015625) or even smaller (e.g., 1/256). 
In this case, the value could be mapped as follows:
  Siiiiiiiffffffff
where S is  the sign bit, iiiiiii is the 7 bit integer value and 
ffffffff is the 8 bit fraction. I assume you can do the appropriate 
arithmetic to interpret this form of fixed point value.

To some extent this gets back to how fixed point values were represented 
"long ago". You could either represent them as:
  - values right adjusted into a register / storage location
OR
  - values left adjusted into a register / storage location
Each method has definite advantages and disadvantages when doing 
arithmetic - especially when considering multiplication and division. 
Both methods were used in the past and the Ada reference manual 
basically allows either to be used in this case.

Your compiler should define this "implementation detail" in sufficient 
detail to figure out which method is used. Note however, that whatever 
code you use to process this will NOT be very portable between Ada 
compilers and target systems.

   --Mark

Re: How unchecked conversion works?

[Keith Thompson]

Mark H Johnson <mark_h_johnson@raytheon.com> writes:
> None wrote:
>
>> well, I try to explain. I have those types for example
>> type fixed is delta 0.03 range -90.0..90.0
>> for fixed'size use 16
>> and
>> type inte is range -32768..32767
>> for inte'size use 16
>> and a new function that renames unchecked_conversion to come from
>> fixed to inte (probably an inefficient way, but I have to do this
>> way), so I'd like to predict on paper which value of inte type
>> corresponds to 89.09 for example: what kind of calculus should I do?
>> This depends on something else? Thanks again!

There's no reason to expect that Unchecked_Conversion would be
inefficient.  It's generally implemented as a no-op that overrides
type checking.

> The specific answer will likely be compiler specific so you may need
> to write a test application to verify the result. Let me see if I can
> explain why...
>
> One choice - the compiler chooses to represent value as 1 == your
> delta value (0.03) and scale everything appropriately. Then 90.0 is
> represented by 3000 (decimal) since
>    3000 * 0.03 == 90.0
> So you have a range of values +/- 3000 when you do the unchecked
> conversion. Pretty straight forward implementation for your problem.
>
> Another choice - the compiler chooses to make 'Small of your datatype
> not equal to 'Delta of your data type (this IS allowed in ARM
> 3.5.9). Since you did not request a decimal fixed point value, 'Small
> will be a power of two smaller than 'Delta. If my arithmetic is
> correct, that could be something like 1/64 (0.015625) or even smaller
> (e.g., 1/256). In this case, the value could be mapped as follows:
>   Siiiiiiiffffffff
> where S is  the sign bit, iiiiiii is the 7 bit integer value and
> ffffffff is the 8 bit fraction. I assume you can do the appropriate
> arithmetic to interpret this form of fixed point value.

Actually, the language specifies that the "small" value for type fixed
will *not* be 0.03.  RM95 3.5.9p8 (with underscores to denote italics)
says:

    The set of values of a fixed point type comprise the integral
    multiples of a number called the _small_ of the type. For a type
    defined by an ordinary_fixed_point_definition (an _ordinary_ fixed
    point type), the _small_ may be specified by an
    attribute_definition_clause (see 13.3); if so specified, it shall
    be no greater than the _delta_ of the type. If not specified, the
    _small_ of an ordinary fixed point type is an
    implementation-defined power of two less than or equal to the
    _delta_.

So Fixed'Small is guaranteed to be a power of two no larger than 0.03.
The most likely value is probably 1.0/64.0 (0.015625) (since 1.0/32.0
is too large).

The "delta" is the precision you ask for; the "small" is the precision
you get.

You can find out what the actual "small" is by printing the value of
Fixed'Small.

If you really want Fixed'Small to be 0.03, you can specify it:

    for Fixed'Small use 0.03;

Assuming Fixed'Small = 1.0/64.0, the value 89.09 can't be represented
exactly.  You'll get either 89.078125 (5701.0/64.0) or 89.093750
(5702.0/64.0).  Doing an Unchecked_Conversion of that value to Inte
should give you either 5701 or 5702.

You may be able to achieve the same affect by dividing by Fixed'Small:

    F : constant Fixed := 89.09;
    I : constant Inte  := Inte(F / Fixed'Small);

A quick experiment shows that this works, but I'm not sure that it's
guaranteed.  There may be some rounding and/or overflow issues.  (It's
been a while; I don't remember the details.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.

Re: How unchecked conversion works?

[Keith Thompson]

Marius Amado Alves <amado.alves@netcabo.pt> writes:
> As others have said, don't use unchecked_conversion for this.
> And yes, the result value if of course predictable, namely as per
> section 3.4 of the RM, enigmatically entitled "Type Conversions":

Don't use unchecked_conversion for what?  I think the original poster
was specifically asking about the semantics of an unchecked_conversion
from fixed to integer, not about a type conversion.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.

Re: How unchecked conversion works?

[Stephen Leake]

None <none@none.it> writes:

> well, I try to explain. I have those types for example
> 
> type fixed is delta 0.03 range -90.0..90.0
> for fixed'size use 16
> 
> and
> 
> type inte is range -32768..32767
> for inte'size use 16
> 
> 
> and a new function that renames unchecked_conversion to come from
> fixed to inte (probably an inefficient way, but I have to do this
> way), so I'd like to predict on paper which value of inte type
> corresponds to 89.09 for example: what kind of calculus should I do?
> This depends on something else? Thanks again!

If you are trying to control the exact representation of the fixed
point type, you need to specify the 'Small for the type:

for fixed'small use 0.03;

Then the least significant bit of 'fixed' represents a value of 0.03;
89.09 / 0.03 is 2970, so that is the result of the unchecked
conversion you are discussing.

This is explained in sections 3.5.9 and 3.5.10 of the Ada Reference
Manual, but it is somewhat obscure.

-- 
-- Stephe

Re: How unchecked conversion works?

[Marius Amado Alves]

> Don't use unchecked_conversion for what?

For converting an real to an integer.

> I think the original poster
> was specifically asking about the semantics of an unchecked_conversion
> from fixed to integer, not about a type conversion.

Does the ARM specify the internal representation of numerical values? 
Only that would give the sought predictability.

Re: How unchecked conversion works?

[Keith Thompson]

Marius Amado Alves <amado.alves@netcabo.pt> writes:
>> Don't use unchecked_conversion for what?
>
> For converting an real to an integer.
>
>> I think the original poster
>> was specifically asking about the semantics of an unchecked_conversion
>> from fixed to integer, not about a type conversion.
>
> Does the ARM specify the internal representation of numerical values?
> Only that would give the sought predictability.

I don't think it *quite* specifies the internal representation, but
the requirements on the representable values strongly imply that
they're represented as scaled integers.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.

Re: How unchecked conversion works?

[Larry Kilgallen]

In article <mailman.57.1105744501.527.comp.lang.ada@ada-france.org>, Marius Amado Alves <amado.alves@netcabo.pt> writes:
>> Don't use unchecked_conversion for what?
> 
> For converting an real to an integer.
> 
>> I think the original poster
>> was specifically asking about the semantics of an unchecked_conversion
>> from fixed to integer, not about a type conversion.
> 
> Does the ARM specify the internal representation of numerical values? 

I think it is safe to assume that a given compiler version
on a given architecture would be consistent in this regard.

> Only that would give the sought predictability.

Was there any statement that predictability across environments
was a goal ?

Re: How unchecked conversion works?

[Marius Amado Alves]

> Was there any statement that predictability across environments
> was a goal ?

No environment, compiler, or operating system was identified. This 
indicates a portable solution was sought.

Re: How unchecked conversion works?

[Larry Kilgallen]

In article <mailman.58.1105784680.527.comp.lang.ada@ada-france.org>, Marius Amado Alves <amado.alves@netcabo.pt> writes:
>> Was there any statement that predictability across environments
>> was a goal ?
> 
> No environment, compiler, or operating system was identified. This 
> indicates a portable solution was sought.

No security environment was specified, so I shall presume something
that can be evaluated at the current equivalent of "A1" is required.
Furthermore, I will presume this has to run on Microsoft Windows.

Can you see how making such assumptions is flawed ?

Re: How unchecked conversion works?

[Nick Roberts]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote:

> No security environment was specified, so I shall presume something that
> can be evaluated at the current equivalent of "A1" is required.

As I understand it, ther is no system in existence certified to A1. I have
heard rumours that there are ultra-secret computers in the bowels of the CIA
HQ (VA), but I think it's all apocryphal!

> Furthermore, I will presume this has to run on Microsoft Windows.

Errr ... E9? ;-)

-- 
Nick Roberts

Re: How unchecked conversion works?

[Jeffrey Carter]

Marius Amado Alves wrote:

> No environment, compiler, or operating system was identified. This 
> indicates a portable solution was sought.

Plenty of people forget to, or in the case of newcomers, don't know that 
they should specify these things.

-- 
Jeff Carter
"Alms for an ex-leper!"
Monty Python's Life of Brian
75

Re: How unchecked conversion works?

[Larry Kilgallen]

In article <gemini.iadaz7002y97g02bc.nick.roberts@acm.org>, Nick Roberts <nick.roberts@acm.org> writes:
> Kilgallen@SpamCop.net (Larry Kilgallen) wrote:
> 
>> No security environment was specified, so I shall presume something that
>> can be evaluated at the current equivalent of "A1" is required.
> 
> As I understand it, ther is no system in existence certified to A1.

I remember that the Honeywell SCOMP was evaluated at the A1 level.

I presume your requirement was not that it also be a system that
is still sold, or made a profit when it was being sold :-)

But http://www.dynamoo.com/orange/summary.htm lists two others.

Re: How unchecked conversion works?

[Jeffrey Carter]

Larry Kilgallen wrote:

> I remember that the Honeywell SCOMP was evaluated at the A1 level.

I attended a presentation at a conference in the late 1980's by a 
researcher whose project was to create an A1 OS. Basically he was 
reimplementing UNIX into an A1 level OS. This allowed him to reuse some 
of the UNIX source code. This was funded by the US govt.

He had achieved everything except there was one small covert channel 
available. A trusted user could set up a program that created a lot of 
processes when it wanted to transmit a one, and no processes to transmit 
a zero. The untrusted recipient would create a process from time to time 
and see how many processes had been created, since process IDs were 
sequential.

This created a noisy channel with a bandwidth of about 1 bps.

The researcher tried to plug this hole by using a PRNG to generate IDs 
without replacement, but since the algorithm used by the PRNG would be 
known or easily determined, that just made the recipient's program a 
little more complicated, and the channel a little more noisy.

Since the researcher couldn't include a true RNG in his SW, the project 
was a failure.

It seems to me that this system was a success. Nothing stops the trusted 
person from memorizing a block of data, going out of the secure area, 
writing it down, and giving it to the recipient. That would have less 
noise and a much higher bandwidth than this covert channel. The only 
channels worth worrying about should be those that are better than 
humans can achieve without using the computer. Trying to plug this kind 
of hole is a waste of time.

-- 
Jeff Carter
"Every sperm is sacred."
Monty Python's the Meaning of Life
55

TCSEC security levels [was: How unchecked conversion works?]

[Nick Roberts]

Jeffrey Carter <spam@spam.com> wrote:

> Larry Kilgallen wrote:
> 
> > I remember that the Honeywell SCOMP was evaluated at the A1 level.
> 
> I attended a presentation at a conference in the late 1980's by a
> researcher whose project was to create an A1 OS.
> ...
> He had achieved everything except there was one small covert channel
> available. 
> ...
> It seems to me that this system was a success. ... Trying to plug this
> kind of hole is a waste of time.

I couldn't agree more, and I assume this part of the reason why the TCSEC
security levels never really took hold (in the evaluation criteria of major
computer systems). In response, the Common Criteria were developed, which
don't give the impression of making any greater a mark, yet.

-- 
Nick Roberts

Re: How unchecked conversion works?

[Larry Kilgallen]

In article <8PwGd.8282$pZ4.6177@newsread1.news.pas.earthlink.net>, Jeffrey Carter <spam@spam.com> writes:

> He had achieved everything except there was one small covert channel 
> available. A trusted user could set up a program that created a lot of 
> processes when it wanted to transmit a one, and no processes to transmit 
> a zero. The untrusted recipient would create a process from time to time 
> and see how many processes had been created, since process IDs were 
> sequential.

Analysis of such covert storage channels is actually required for
any assurance level above B1, not just for A1.

http://www.atis.org/tg2k/_covert_storage_channel.html

> It seems to me that this system was a success. Nothing stops the trusted 
> person from memorizing a block of data, going out of the secure area, 
> writing it down, and giving it to the recipient.

But the person doing that would know they were doing that.  No computer
system can prevent a human from releasing information they know, even if
they have to carry one bit a day out of the workplace based on which of
their pockets they use to store their wallet.

A trusted system (at the proper evaluation level) will prevent the person
from _inadvertantly_ releasing information, such as by running a trojan
horse spreadsheet program that performed the modulation you describe.

Re: How unchecked conversion works?

[Jeffrey Carter]

Larry Kilgallen wrote:

> A trusted system (at the proper evaluation level) will prevent the person
> from _inadvertantly_ releasing information, such as by running a trojan
> horse spreadsheet program that performed the modulation you describe.

Since users shouldn't be installing SW on such a system, I have to 
assume such a channel is only used with both parties' knowledge. But I 
hardly claim to be an expert on secure OSes. Insecure OSes in secure 
locations with secured communications seem to work better.

-- 
Jeff Carter
"Every sperm is sacred."
Monty Python's the Meaning of Life
55

Re: How unchecked conversion works?

[Larry Kilgallen]

In article <5yEGd.9533$Ii4.6708@newsread3.news.pas.earthlink.net>, Jeffrey Carter <spam@spam.com> writes:
> Larry Kilgallen wrote:
> 
>> A trusted system (at the proper evaluation level) will prevent the person
>> from _inadvertantly_ releasing information, such as by running a trojan
>> horse spreadsheet program that performed the modulation you describe.
> 
> Since users shouldn't be installing SW on such a system, I have to 
> assume such a channel is only used with both parties' knowledge.

Conceivably the system manager could be deceived by a counterfeit
distribution kit for a well-known product.  Or even the real kit
for a well-known product that has a secret back door to make it
behave in a trojan horse fashion.

It is easier (but not truly easy) to evaluate operating systems
than to evaluate all the applications that run on them.

Re: TCSEC security levels [was: How unchecked conversion works?]

[Larry Kilgallen]

In article <gemini.iafgmt002e35g03tw.nick.roberts@acm.org>, Nick Roberts <nick.roberts@acm.org> writes:
> Jeffrey Carter <spam@spam.com> wrote:

>> It seems to me that this system was a success. ... Trying to plug this
>> kind of hole is a waste of time.
> 
> I couldn't agree more, and I assume this part of the reason why the TCSEC
> security levels never really took hold (in the evaluation criteria of major
> computer systems).

Whereas I believe multi-level secure systems have not taken hold because
it is easier to buy separate small systems (and systems are getting to be
smaller.

As for successors, the idea (even at the equivalent of non-MLS C2 levels)
of international efforts is to make them less US-centric.