Alternate to Unchecked_Conversion - Portable?

Alternate to Unchecked_Conversion - Portable?

[Steve Doiel]

I discovered a technique for performing a similar function to
Unchecked_Conversion.  Locating two data structures at the same address by
defining the first normally and then using an address clause to locate the
second at the same address as the first (as shown in the following sample):


WITH Ada.Text_Io;
WITH Interfaces;
 USE Interfaces;
PROCEDURE TestAlias IS
  PACKAGE Text_Io RENAMES Ada.Text_Io;

  TYPE aRec IS
    RECORD
      f1 : Integer_32;
      f2 : Integer_32;
    END RECORD;

  TYPE Integer_16_Array IS ARRAY( Positive RANGE <> ) OF Integer_16;

  v1 : aRec;
  v2 : Integer_16_Array( 1..4 );
  FOR v2'ADDRESS USE v1'ADDRESS;    -- This causes v1 and v2 to occupy the
same memory

BEGIN
  v1.f1 := 1;
  v1.f2 := 2;
  FOR ii IN v2'RANGE LOOP
    Text_Io.Put( Integer_16'IMAGE( v2( ii ) ) );
  END LOOP;
  Text_Io.New_Line;
END TestAlias;


My question is: is this portable?

I expect that record layouts will be dependent on different endian machines,
and I know that this technique is inherently unsafe, but it makes things
very simple.

SteveD

Re: Alternate to Unchecked_Conversion - Portable?

[Steve Quinlan]

At a minimum, you'd want to make first object aliased I'd think. I'm not sure
whether without that, you'd be guaranteed that some optimization techniques
wouldn't mess you up (register optimizations, etc.). Aliased at least lets the
compiler know that the object might be accessed via some alternate path, so it
will know not to do anything naughty to the object which might cause problems
with access via an alias. Maybe one of the compiler internals experts will weigh
in on this one.

Re: Alternate to Unchecked_Conversion - Portable?

[Matthew Heaney]

"Steve Doiel" <nospam_steved@pacifier.com> writes:

> I discovered a technique for performing a similar function to
> Unchecked_Conversion.  Locating two data structures at the same address by
> defining the first normally and then using an address clause to locate the
> second at the same address as the first (as shown in the following sample):

<example snipped>

> My question is: is this portable?
> 
> I expect that record layouts will be dependent on different endian machines,
> and I know that this technique is inherently unsafe, but it makes things
> very simple.

Don't use address overlays unless you have a compelling reason to do
so.  Use Unchecked_Conversion, which is also "very simple."

Re: Alternate to Unchecked_Conversion - Portable?

[Christopher Green]

On Sun, 21 Feb 1999 11:33:54 -0800, "Steve Doiel"
<nospam_steved@pacifier.com> wrote:

>I discovered a technique for performing a similar function to
>Unchecked_Conversion.  Locating two data structures at the same address by
>defining the first normally and then using an address clause to locate the
>second at the same address as the first (as shown in the following sample):
>
>
>WITH Ada.Text_Io;
>WITH Interfaces;
> USE Interfaces;
>PROCEDURE TestAlias IS
>  PACKAGE Text_Io RENAMES Ada.Text_Io;
>
>  TYPE aRec IS
>    RECORD
>      f1 : Integer_32;
>      f2 : Integer_32;
>    END RECORD;
>
>  TYPE Integer_16_Array IS ARRAY( Positive RANGE <> ) OF Integer_16;
>
>  v1 : aRec;
>  v2 : Integer_16_Array( 1..4 );
>  FOR v2'ADDRESS USE v1'ADDRESS;    -- This causes v1 and v2 to occupy the
>same memory
>
>BEGIN
>  v1.f1 := 1;
>  v1.f2 := 2;
>  FOR ii IN v2'RANGE LOOP
>    Text_Io.Put( Integer_16'IMAGE( v2( ii ) ) );
>  END LOOP;
>  Text_Io.New_Line;
>END TestAlias;
>
>
>My question is: is this portable?
>
>I expect that record layouts will be dependent on different endian machines,
>and I know that this technique is inherently unsafe, but it makes things
>very simple.
>
>SteveD
>
>

It is primarily useful in situations in which alternative
implementations end up causing a bitwise copy.  If
the object to be converted is large, or the conversion
must be done many times, this can be a win.

Other than problems with data representation mis-
matches, a source of significant portability problems
is default initializations. For example, certain compilers
will apply default initializations to arrays of derived types
of System.Address, zeroing out the contents of the
array you were trying to convert.

Unless there are overriding reasons to do otherwise;
for example, a need to preserve backward com-
patibility with Ada 83, or a big performance difference
in a particular implementation, it is safer and usually
more efficient to use packages intended for this
purpose, such as Interfaces.C.Pointers.

Re: Alternate to Unchecked_Conversion - Portable?

[Tom Moran]

>a similar function to
>Unchecked_Conversion.  Locating two data structures at the same address by
>defining the first normally and then using an address clause to locate the
>second at the same address as the first
>...
>My question is: is this portable?
  You have similar record layout worries with address overlay and
Unchecked_Conversion.  If you use a representation clause to control
all the parts of the layout, then the two layouts should be the same -
if you don't, then two compilers would be free to make them different.
It seems unlikely two compilers would choose different endian-ness for
multi-byte entities on the same machine, but clearly they might on
different machines, so IO is a worry.  If you're careful and thorough,
you should be able to make something portable, but you ought to check
the compilers you're using (and again when you get a newer version of
either compiler).. 
  With Unchecked_Conversion, at least the compiler can warn you if the
two things aren't the same size, which of course it can't if they
merely have the same address.  If some later change modifies the
layout or adds to the size of one of the two things, the compiler
can't give you any warnings.
  With Unchecked_Conversion, the only time you transform one object
into another is when you call the instantiated Unchecked_Conversion
function.  With the address overlay, you've got aliasing and possibly
multitasking to worry about - any change to either object is instantly
reflected in the other, and any change to a temporary compiler
generated copy (in registers, say) of one object fails to be reflected
in the other.
  With Unchecked_Conversion, it's easy to use your editor to find any
occurrences, and then occurrences of the instantiated conversion.
With address overlay, you can find the rep clauses, and then the
objects, but following them through their aliases (as one is passed to
a procedure either by reference or by copy in/out, say) will get real
tedious and error prone.
  With Unchecked_Conversion, you have a function able to transform
*any* object of the one type to the other.  With address overlay, you
have a single specific object transformed implicitly to another single
specific object.
  That said, yes there do exist times when address overlay is the
best, or only, thing to do.
  
 

Re: Alternate to Unchecked_Conversion - Portable?

[robert_dewar]

In article <36d05e39.0@news.pacifier.com>,
  "Steve Doiel" <nospam_steved@pacifier.com> wrote:
> I discovered a technique for performing a similar
> function to Unchecked_Conversion.  Locating two data
> structures at the same address by defining the first
> normally and then using an address clause to locate the
> second at the same address as the first (as shown in the
> following sample):
>
> My question is: is this portable?

Answer: this technique is standard and well known in Ada
95, though it was always wrong (erroneous) in Ada 83. It
is definitely NOT portable, and in particular, and
optimizer may get confused by the implicit aliasing, and
you cannot complain if it does!

> I expect that record layouts will be dependent on
> different endian machines, and I know that this technique
> is inherently unsafe, but it makes things very simple.

It is usually just as simple (from a reader's point of
view, and I sure hope that this is what you mean by simple)
to use unchecked conversion of pointers, and much better
defined, and likely to be more portable.

In general the use of overlays of this type should be
deprecated and used only if there is some very specific
reason to prefer this to the more standard unchecked
conversion approach.

P.S. the reason Ada 95 made this implementation dependent
rather than erroneous is that many (non-portable) Ada 83
programs used this technique, and it seemed pointless to
proscribe it as erroneous. However, it is ENTIRELY up to
the implementation to decide whether this is valid or not,
and an implementation that rejects it is indeed within its
rights. Unchecked conversion is likely to be far more
portable in practice.


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Alternate to Unchecked_Conversion - Portable?

[robert_dewar]

In article <36D06C1B.14FE920C@lmco.com>,
  Steve Quinlan <steven.quinlan@lmco.com> wrote:
> At a minimum, you'd want to make first object aliased I'd
> think. I'm not sure whether without that, you'd be
> guaranteed that some optimization techniques wouldn't
> mess you up (register optimizations, etc.). Aliased at
> least lets the compiler know that the object might be
> accessed via some alternate path, so it will know not to
> do anything naughty to the object which might cause
> problems with access via an alias. Maybe one of the
> compiler internals experts will weigh in on this one.

Well using aliased may help here in practice, but it is
no guarantee that the compiler will do the "right thing".
Since this construct of overlaying is completely
implementation dependent, nothing a programmer can do
will guarantee that this will work portably.

In the "shot in the dark" mode, it will help perhaps to
make both objects volatile, so that all references are to
memory.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Alternate to Unchecked_Conversion - Portable?

[Samuel Mize]

Just a couple of further points, I'm not disagreeing with Robert.

robert_dewar@my-dejanews.com wrote:
> In article <36d05e39.0@news.pacifier.com>,
>   "Steve Doiel" <nospam_steved@pacifier.com> wrote:
>> I discovered a technique for performing a similar
>> function to Unchecked_Conversion.  Locating two data
>> structures at the same address by defining the first
>> normally and then using an address clause to locate the
>> second at the same address as the first (as shown in the
>> following sample):
>>
>> My question is: is this portable?
> 
> Answer: this technique is standard and well known in Ada
> 95, though it was always wrong (erroneous) in Ada 83. It
> is definitely NOT portable, and in particular, and
> optimizer may get confused by the implicit aliasing, and
> you cannot complain if it does!

There are some architectures on which it's not even meaningful.
For instance, I don't expect this would be useful on a LISP
machine.

It does work on most compilers, especially if you use pragma
Volatile.

<language sniping on>

This seems to be the definition that is used by some advocates
of a language that shall remain nameless (but its initial is C).
Since several compilers support feature X, it's a "standard,
portable" idiom in that language.

<language sniping off>

And, in all fairness, that's sometimes a useful way to look at
such questions.


> It is usually just as simple (from a reader's point of
> view, and I sure hope that this is what you mean by simple)
> to use unchecked conversion of pointers, and much better
> defined, and likely to be more portable.

But be careful.  For example, if the pointed-at object is an
array of an unconstrained type, the access object is likely
to be TWO pointers: one to a "dope vector," and one to the
array data itself.  As another example, an access to an
object from a storage pool may not be a pointer at all, but
an offset address into the pool.  Robert knows all this, of
course, and his statement is a generalization -- all of which
have exceptions.

My point is that, if you're trying to look at one piece of
memory with two mappings, you have to know what this specific
specific compiler does on this specific architecture, in this
specific case.

It is an *extremely* non-portable idiom in the general case,
although specific instances may be fairly portable (in the
informal sense of the word).  I believe that this statement
is true in both C and Ada, although the C culture relies on
this particular idiom much more commonly.

Best,
Sam Mize

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam

Re: Alternate to Unchecked_Conversion - Portable?

[Christopher Green]

On Wed, 24 Feb 1999 02:52:52 GMT, robert_dewar@my-dejanews.com wrote:

>In article <36d2638e.6427631@nntp.concentric.net>,
>  cjrgreen@concentric.net (Christopher Green) wrote:
>> It is primarily useful in situations in which alternative
>> implementations end up causing a bitwise copy.  If
>> the object to be converted is large, or the conversion
>> must be done many times, this can be a win.
>
>This seems bogus to me. If you replace this by unchecked
>conversion of *pointers* (i.e. access values), NOT the
>items themselves, then there is no bit copying, and no
>inefficiency at all in the access.
>
>-----------== Posted via Deja News, The Discussion Network ==----------
>http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

The situations I'm thinking of involve conversion of
arrays of integers or pointers, large record objects,
and the like. You are surely right in that there is no
inherent reason why Unchecked_Conversion on
scalars and pointers should be inefficient.

For example, in X Window System programming, 
there are many C functions that return arrays of
indefinite size (the size must be obtained through
another argument or another function call).  In
this case, it is natural enough, though not fully
portable, to declare an Ada array of the actual
size and map it onto the C array with an address
clause.

In Ada 95, the package Interfaces.C.Pointers is
a better solution to this kind of problem.

-- 
Chris Green
Advanced Technology Center
Laguna Hills, California

Re: Alternate to Unchecked_Conversion - Portable?

[Christopher Green]

On Wed, 24 Feb 1999 02:52:52 GMT, robert_dewar@my-dejanews.com wrote:

>In article <36d2638e.6427631@nntp.concentric.net>,
>  cjrgreen@concentric.net (Christopher Green) wrote:
>> It is primarily useful in situations in which alternative
>> implementations end up causing a bitwise copy.  If
>> the object to be converted is large, or the conversion
>> must be done many times, this can be a win.
>
>This seems bogus to me. If you replace this by unchecked
>conversion of *pointers* (i.e. access values), NOT the
>items themselves, then there is no bit copying, and no
>inefficiency at all in the access.
>
>-----------== Posted via Deja News, The Discussion Network ==----------
>http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Unchecked conversion of C pointers to Ada access values
is, in my experience, no more portable than using address
clauses to alias structured types.  When the desired Ada
object is an instance of an unconstrained type, converting
a pointer is completely nonportable and usually impractical.

-- 
Chris Green
Advanced Technology Center
Laguna Hills, California

Re: Alternate to Unchecked_Conversion - Portable?

[Matthew Heaney]

cjrgreen@concentric.net (Christopher Green) writes:

> It is primarily useful in situations in which alternative
> implementations end up causing a bitwise copy.  If
> the object to be converted is large, or the conversion
> must be done many times, this can be a win.

A copy doesn't necessarily occur.  If I use a constant declaration:

procedure Op (O : T) is

  OO : constant TT := UC (O);
begin


then (I assume) there isn't any copy of the source object.

Re: Alternate to Unchecked_Conversion - Portable?

[Samuel Mize]

Matthew Heaney <matthew_heaney@acm.org> wrote:
> A copy doesn't necessarily occur.  If I use a constant declaration:
> 
> procedure Op (O : T) is
> 
>   OO : constant TT := UC (O);
> begin
> 
> 
> then (I assume) there isn't any copy of the source object.

This is an example of where the Ada programmer expects the
compiler to do intelligent things.  On the other hand, programmers
accustomed to other languages see a function call, and by golly they
expect there to be a function call!

This is one source of the erroneous "common wisdom" that Ada is
inherently slow.

I've had people argue against creating new subtypes because they
don't want to incur the run-time overhead of the type conversion:

       type New_Int is new Integer;
       Freem: Integer := Get_Value;
       New_Freem: New_Int;
    begin

       New_Freem := New_Int (Freem);
       -- Oh no!  It looks like a function call, so it must have
       -- the same run-time overhead as a function call!

Best,
Sam Mize

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam

Re: Alternate to Unchecked_Conversion - Portable?

[Christopher Green]

On Thu, 25 Feb 1999 04:57:04 GMT, robert_dewar@my-dejanews.com wrote:

>In article <36d3ba85.713118@nntp.concentric.net>,
>  cjrgreen@concentric.net (Christopher Green) wrote:
>> In
>> this case, it is natural enough, though not fully
>> portable, to declare an Ada array of the actual
>> size and map it onto the C array with an address
>> clause.
>
>In Ada 83, this is ALWAYS an incorrect approach, because
>it is erroneous, which means the compiler need make no
>attempt at all (e.g. in suppressing optimziation) to
>make this "work".

Such compilers (there are a few still in use) are, for reasons
like this, virtually useless for the sort of programming in which
address clauses, Unchecked_Conversion, or equivalence
between C pointer types and Ada access types is important.

Theoretical correctness and actual correct operation are
different things.  There are many compilers on which the
address clause mapping does work as it "should".

>> In Ada 95, the package Interfaces.C.Pointers is
>> a better solution to this kind of problem.
>
>If you look at the implementation of this package, it
>will almost certainly use unchecked conversion on pointers!

True; however, the level of abstraction in using
Interfaces.C.Pointers is higher, and the reduction
in programming effort and improvement in port-
ability may be worth any trade in efficiency.

Furthermore, if the Unchecked_Conversions
internal to the Interfaces.C.Pointers package
don't do the right thing, you can at least blame
the compiler vendor.  If you code Unchecked_
Conversions on your own and they don't do the
right thing on the platforms you must support,
you're stuck.

>-----------== Posted via Deja News, The Discussion Network ==----------
>http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

-- 
Chris Green
Advanced Technology Center
Laguna Hills, California

Re: Alternate to Unchecked_Conversion - Portable?

[Christopher Green]

On Thu, 25 Feb 1999 05:01:23 GMT, robert_dewar@my-dejanews.com wrote:

>In article <36d3bf1f.1891152@nntp.concentric.net>,
>  cjrgreen@concentric.net (Christopher Green) wrote:
>> Unchecked conversion of C pointers to Ada access values
>> is, in my experience, no more portable than using address
>> clauses to alias structured types.  When the desired Ada
>> object is an instance of an unconstrained type,
>> converting a pointer is completely nonportable and
>> usually impractical.
>
>and also completely meaningless!

[snip]

Not quite meaningless; if you can construct the compiler-
dependent dope associated with the access value, it
most definitely works.  The result is quite nonportable,
so it is appropriate only where the effort is worthwhile.

This is at best a counterproductive nuisance when
unconstrained array types are involved.  It can often
be made to work when the target of the access type
is a record type with a discriminant, and the discrim-
inant can be located with a record rep spec.

The best example I have involves the X Window
System event type, which is a C union type, but
it has a field that serves as a discriminant.  Code
that handles event types is generally in an inner
loop with tight performance requirements.  The
Ada access type should be to the unconstrained
event record type, not to a constrained subtype.
And copying the event object is incorrect, for some
domain-dependent reasons.

In this case, the best alternative is to construct the
correct access value, using a procedure that may
have to be modified to support different compilers.

-- 
Chris Green
Advanced Technology Center
Laguna Hills, California

Re: Alternate to Unchecked_Conversion - Portable?

[robert_dewar]

In article <36d2638e.6427631@nntp.concentric.net>,
  cjrgreen@concentric.net (Christopher Green) wrote:
> It is primarily useful in situations in which alternative
> implementations end up causing a bitwise copy.  If
> the object to be converted is large, or the conversion
> must be done many times, this can be a win.

This seems bogus to me. If you replace this by unchecked
conversion of *pointers* (i.e. access values), NOT the
items themselves, then there is no bit copying, and no
inefficiency at all in the access.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Alternate to Unchecked_Conversion - Portable?

[robert_dewar]

In article <m3sobxfpwd.fsf@mheaney.ni.net>,
  Matthew Heaney <matthew_heaney@acm.org> wrote:
>> A copy doesn't necessarily occur.  If I use a constant
declaration:
>
> procedure Op (O : T) is
>
>   OO : constant TT := UC (O);
> begin
>
> then (I assume) there isn't any copy of the source
object.

I would be very surprised if a compiler did NOT make a copy
in this case, it would certainly be an interesting
optimization if it did not. What is the basis of your
assumption here.

Anyway, this is simply the wrong way to go here, it is
far better to use UC on pointers.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Alternate to Unchecked_Conversion - Portable?

[Christopher Green]

On Thu, 25 Feb 1999 19:52:42 GMT, dennison@telepath.com wrote:

>In article <7b3glh$ml6$1@nnrp1.dejanews.com>,
>  robert_dewar@my-dejanews.com wrote:
>
>> A mantra that should be central to every programmer's
>> view of the universe is:
>>
>>   "just because it works does not mean it is right"
>>
>> A lot of programmers violate this because they don't know
>> enough to avoid violations.
>
>I hope you try to ingrain this in your students, because I run into a
>depressing number of programmers who hold the opposite view. One gentleman in
>particular was of the view that putting any extra effort into quality above
>what is required to get the program to operate is tantamount to theft on the
>programmers part.
>
>Luckily, such folk tend to *hate* Ada, so I don't have to work with too many
>of them. :-)
>
>T.E.D.

"Just because it is right does not mean it works".

Code that must, as a matter of functional requirement, implement
interfaces between Ada and constructs that are native in other
languages, tends to expose any number of compiler misfeatures.

Maybe the Unchecked_Conversion of access types has
wider approval from those who develop language standards.
But I cannot afford to spend more time than I have to in
troubleshooting code that fails to port to a new compiler.
In the products I deal with regularly, address representation
clauses are the cause of no more portability problems than are
uses of Unchecked_Conversion.  This includes products in
which Ada 83 and Ada 95 must be supported from the same
source code base.

-- 
Christopher Green
Advanced Technology Center
Laguna Hills, California

Re: Alternate to Unchecked_Conversion - Portable?

[robert_dewar]

In article <36d3ba85.713118@nntp.concentric.net>,
  cjrgreen@concentric.net (Christopher Green) wrote:
> In
> this case, it is natural enough, though not fully
> portable, to declare an Ada array of the actual
> size and map it onto the C array with an address
> clause.

In Ada 83, this is ALWAYS an incorrect approach, because
it is erroneous, which means the compiler need make no
attempt at all (e.g. in suppressing optimziation) to
make this "work".

> In Ada 95, the package Interfaces.C.Pointers is
> a better solution to this kind of problem.

If you look at the implementation of this package, it
will almost certainly use unchecked conversion on pointers!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Alternate to Unchecked_Conversion - Portable?

[robert_dewar]

In article <36d3bf1f.1891152@nntp.concentric.net>,
  cjrgreen@concentric.net (Christopher Green) wrote:
> Unchecked conversion of C pointers to Ada access values
> is, in my experience, no more portable than using address
> clauses to alias structured types.  When the desired Ada
> object is an instance of an unconstrained type,
> converting a pointer is completely nonportable and
> usually impractical.

and also completely meaningless!

An unconstrained array pointer in Ada must have bounds,
and these bounds must come from somewhere. It is not just
that this attempted conversion is non-portable, it is
semantic nonsense.

There are two possible approaches that are likely to be
portable in practice and which make semantic sense.

If you know the bounds, e.g. they are implied by the logic
or by some other parameters that are passed, then you can
declare a local subtype of the array type with the right
bounds, and use a pointer to this constrained type.

If you don't know the bounds, then use a "big array" type
such as

   subtype Big_String is String (Positive);
   type Big_String_Ptr is access Big_String;

now of course once you get a value of type Big_String_Ptr
using Unchecked_Conversion, it is up to you not to access
the array value outside its real bounds, but there is no
magic to prevent this in this case!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Alternate to Unchecked_Conversion - Portable?

[Nick Roberts]

robert_dewar@my-dejanews.com wrote in message
<7avplr$jl5$1@nnrp1.dejanews.com>...
|In article <m3sobxfpwd.fsf@mheaney.ni.net>,
|  Matthew Heaney <matthew_heaney@acm.org> wrote:
|>> A copy doesn't necessarily occur.  If I use a constant
|declaration:
|>
|> procedure Op (O : T) is
|>
|>   OO : constant TT := UC (O);
|> begin
|>
|> then (I assume) there isn't any copy of the source
|object.
|
|I would be very surprised if a compiler did NOT make a copy
|in this case, it would certainly be an interesting
|optimization if it did not. What is the basis of your
|assumption here.


If the type T were not a 'small' type (which can fit into one or two
registers) -- and I think that's what the context of this thread suggests --
I would be surprised by an optimising compiler which did make a copy.
Whyever should it make a copy?

-------------------------------------
Nick Roberts
-------------------------------------

Re: Alternate to Unchecked_Conversion - Portable?

[robert_dewar]

In article <7b2j34$drp$3@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:

> |> procedure Op (O : T) is
> |>
> |>   OO : constant TT := UC (O);
> |> begin
> If the type T were not a 'small' type (which can fit into
> one or two registers) -- and I think that's what the
> context of this thread suggests --
> I would be surprised by an optimising compiler which did
> make a copy. Whyever should it make a copy?


Well Nick, you seem to be operating as a user looking at
a specific case and wondering why it is not optimized,
rather than an implementor writing an optimizing compiler.
All I can say is come back when your optimizing compiler
is complete, and see if you handle this case, and if so
why and how it is a special case of a more general
optimization principle.

Obviously there are two quite separate objects here, and
indeed a programmer would expect that O'Address and
OO'Address would be different, so in the general case
I am not even sure the optimization is valid at all.
This is in fact a very delicate optimization, the
question of when you could treat initialized constants
as implicit renamings is indeed an interesting one.

Note of course that if you write

  OO : TT renames UC (O);

then an Ada 95 (but not necessarily an Ada 83) compiler
may routinely create a reference rather than a copy in
this situation. That's because of the important change
in Unchecked_Conversion semantics in Ada 95 that allows
return by reference.

I often find that users who do not understand compilers
and optimizing compilers in particular well are often in
a mode of looking at specific examples and saying "why is
this paticular case not generating this particular code?"

Humans are VERY good at special casing, but of course the
challenge in an optimizing compiler is to find general
safe optimization principles. Compilers that have lots
of special case optimization are exactly the ones that
have lead many programmers to distrust optimization :-)


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Alternate to Unchecked_Conversion - Portable?

[robert_dewar]

In article <36d50d18.695962@nntp.concentric.net>,
  cjrgreen@concentric.net (Christopher Green) wrote:
> Such compilers (there are a few still in use) are, for
> reasons like this, virtually useless for the sort of
> programming in which address
> clauses,Unchecked_Conversion, or equivalence
> between C pointer types and Ada access types is
> important.

No, not at all.

They may be virtually useless for careless programmers who
do not distinguish between erroneous constructs and those
that may theoretically be non-portable but are in practice
portable.

We have four kinds of programming constructs explicitly
and implicitly mentioned here:

1) Using address clauses to achieve erroneous overlays as
   defined by RM83

2) Using address clauses in a legitimate manner

3) Using Unchecked conversion in general

4) Using Unchecked conversion to convert between Ada access
   types and C pointers

Now of these 4, ONLY 1) is erroneous in Ada 83, and a
competent Ada 83 programmer understands what is and what
is not erroneous, and avoids erroneous constructs.

The rest are not erroneous. In fact the word erroneous
appears in the section on UC only to remind you that the
resulting value must be valid.

Uses of 2) 3) 4) are possibly implementation dependent,
and a compiler can theoretically sabotage you by being
unreasonable, but here the principle that Chris states
is valid. A sensible programmer using these constructs
in a reasonable manner using sensible compilers will not
run into trouble.

But to casually lump erroneous constructs in with
implementation constructs is definitely sloppy, and
we have seen numerous instances of people having
trouble porting Ada 83 code to Ada 95 compilers because
of injudicious programmers writing erroneous code that
just happened to work.

A mantra that should be central to every programmer's
view of the universe is:

  "just because it works does not mean it is right"

A lot of programmers violate this because they don't know
enough to avoid violations.

In this particular case, the use of overlays to achieve the
effect of unchecked conversion is almost always a bad
programming choice, and leads you into unnecessary
implementation dependencies, even in Ada 95 where it
is no longer explicitly erroneous. It is almost always
better to use unchecked conversion of pointers (making
sure OF COURSE that you do not try to use pointers to
unconstrained arrays in this context!)



-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Alternate to Unchecked_Conversion - Portable?

[robert_dewar]

In article <36d51061.1537646@nntp.concentric.net>,
  cjrgreen@concentric.net (Christopher Green) wrote:
> Not quite meaningless; if you can construct the compiler-
> dependent dope associated with the access value, it
> most definitely works.  The result is quite nonportable,
> so it is appropriate only where the effort is worthwhile.

The only meaningful way to do that is to follow the
prescription I gave. Trying to convert constrained to
unconstrained pointers is always meaningless (and indeed
will typically not even come close to "working" in many
compilers)

> It can often be made to work ...

Famous last words. What this means is that by tweaking
and fiddling, you can write something that appears to
work at least in the limited cases in which you try it
out on the particular version of the particular compiler
you are using.

You need to write code which you *know* will work because
you have a good foundation for reasoning about it and
your reasoning indicates that it is correct, not simply
that it works.

The simplest case of course is that you write strictly
portable RM guaranteed code that has no implementation
dependencies.

If you wander into implementation dependent areas, you
need to have a firm basis for your analysis that your
code is correct.

For example, your code may depend on the fact that the
representation of a C pointer and the representation of
an Ada pointer (other than pointer to unconstrained array)
are identical. This is a quite reasonable assumption,
followed by virtually every compiler, and is a well defined
assumption that can be verified if you move from one
compiler to another.

But writing erroneous junk that happens to work on one
compiler, or depending on some fiddling that is dependent
on the very specific layout, e.g. of array bounds in the
unconstrained pointer case, does NOT qualify.


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Alternate to Unchecked_Conversion - Portable?

[dennison]

In article <7b3glh$ml6$1@nnrp1.dejanews.com>,
  robert_dewar@my-dejanews.com wrote:

> A mantra that should be central to every programmer's
> view of the universe is:
>
>   "just because it works does not mean it is right"
>
> A lot of programmers violate this because they don't know
> enough to avoid violations.

I hope you try to ingrain this in your students, because I run into a
depressing number of programmers who hold the opposite view. One gentleman in
particular was of the view that putting any extra effort into quality above
what is required to get the program to operate is tantamount to theft on the
programmers part.

Luckily, such folk tend to *hate* Ada, so I don't have to work with too many
of them. :-)

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Alternate to Unchecked_Conversion - Portable?

[Dale Stanbrough]

> The only meaningful way to do that is to follow the
> prescription I gave. Trying to convert constrained to
> unconstrained pointers is always meaningless (and indeed
> will typically not even come close to "working" in many
> compilers)
> 
> > It can often be made to work ...
> 
> Famous last words. What this means is that by tweaking
> and fiddling, you can write something that appears to
> work at least in the limited cases in which you try it
> out on the particular version of the particular compiler
> you are using.



Why can't we have a routine (it would no doubt have been best
in  System.Address_To_Access_Conversions) that allows
for the creation of unconstrained pointers...

e.g.

   pointer := to_unconstrained_pointer (some_address, low_bound, upper_bound);

This way we could recover some of the Ada semantics back into our
arrays when interfacing with other langauges (esp. as we often know
the dimensions of the arrays we are dealing with).

Perhaps...

   System.Address_To_Access_Conversions.Array_Access

or
   System.Address_To_Array_Access_Conversions

?

For example if you have a pointer to a C string, you could use
the above as...


   X : String_Access := To_Unconstrained_Pointer (
                              C_String'address, 1, strlen (C_String));



Certainly this could only be reliably provided by the compiler vendors,
for the reasons already stated.

Dale

Re: Alternate to Unchecked_Conversion - Portable?

[Tom Moran]

>Maybe the Unchecked_Conversion of access types has
>wider approval from those who develop language standards.
There's  RM 13.9(13)  "An implementation may place restrictions on
Unchecked_Conversion." to worry about, of course.

Re: Alternate to Unchecked_Conversion - Portable?

[robert_dewar]

In article <36d65c7c.15971534@nntp.concentric.net>,
  cjrgreen@concentric.net (Christopher Green) wrote:
> Maybe the Unchecked_Conversion of access types has
> wider approval from those who develop language standards.

If you are using a language, it is incumbent on you to KNOW
the language! The language is defined by the standard, not
by the behavior of the compiler you are using.

> But I cannot afford to spend more time than I have to in
> troubleshooting code that fails to port to a new
> compiler.

If you want to minimize time spent porting stuff, then
know the language and AVOID erroneous constructs.

> In the products I deal with regularly, address
> representation clauses are the cause of no more
> portability problems than are uses of
> Unchecked_Conversion.

Yes, but those are, as you say "the products you deal
with regularly". If you use erroneous constructs then
new versions or new compilers may cause problems that
you do not anticipate.

If you use implementation dependent features, you need
to KNOW you are doing it, and know EXACTLY what you are
depending on, and CHECK that the vendor of your current
compiler really does support what you expect, and USE
these criteria for selecting new compilers.

It is amazing to me how many people write implementation
dependent and erroneous code without even knowing they are
doing so. They then get indignant when their code does not
port to a new compiler, new machine, or even new version of
the same compiler they are using.

  "But I thought Ada was portable! Why should I have to
  change my code. My code is correct -- how do I know,
  because it works! [i.e. appears to work]."

The attitude that you do not have time to learn the
language, and that that stuff is all junk that has to
do with "those who develop language standards", and has
nothing to do with you, is what leads some people to have
a lot of trouble porting their code, while other people
have far less trouble!

There is no question that conversion of access types is,
for many technical reasons, safer and more portable than
the use of address overlays. The reasons have been
discussed here many times.

Yes, you can dismiss these discussions as irrelevant
nonsense which you don't have time to follow, but this
may well be a matter of saving a bit of time now, to be
paid back with high interest later on!





-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Alternate to Unchecked_Conversion - Portable?

[robert_dewar]

In article <36d64ce3.10597940@news.pacbell.net>,
  tmoran@bix.com (Tom Moran) wrote:
> >Maybe the Unchecked_Conversion of access types has
> >wider approval from those who develop language
> >standards. There's  RM 13.9(13)  "An implementation may
> >place restrictions on Unchecked_Conversion." to worry
> >about, of course.

Sure, which is why you have to

(a) know what kinds of unchecked conversions you expect
    to be supported

(b) know enough to know what kinds of unchecked conversions
    are in fact almost certain to be supported in all
    implementations. Remember that vendors are interested
    in making your code run, not taking advantage of the
    RM to ensure that your code does NOT run :-)

Also note that there is a big difference between an
instantiation of unchecked conversion that is rejected
at compile time, and an address overlay that is accepted,
but causes mysterious runtime failures, perhaps dependent
on subtle optimization effects!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Alternate to Unchecked_Conversion - Portable?

[Nick Roberts]

robert_dewar@my-dejanews.com wrote in message
<7b3fk2$lnk$1@nnrp1.dejanews.com>...
[...]
|  OO : TT renames UC (O);


Is this legal?

-------------------------------------
Nick Roberts
-------------------------------------

Re: Alternate to Unchecked_Conversion - Portable?

[Matthew Heaney]

"Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:

> robert_dewar@my-dejanews.com wrote in message
> <7b3fk2$lnk$1@nnrp1.dejanews.com>...
> [...]
> |  OO : TT renames UC (O);
> 
> 
> Is this legal?

Yes, because there is a subtle difference between what a function
returns in Ada95 vs Ada83.  Functions now return "constant objects,"
whereas before, they returned "values."

Re: Alternate to Unchecked_Conversion - Portable?

[Robert A Duff]

robert_dewar@my-dejanews.com writes:

> A mantra that should be central to every programmer's
> view of the universe is:
> 
>   "just because it works does not mean it is right"
> 
> A lot of programmers violate this because they don't know
> enough to avoid violations.

And the rest of us violate this by accident.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Alternate to Unchecked_Conversion - Portable?

[Robert A Duff]

dale@cs.rmit.edu.au (Dale Stanbrough) writes:

> Why can't we have a routine (it would no doubt have been best
> in  System.Address_To_Access_Conversions) that allows
> for the creation of unconstrained pointers...
> 
> e.g.
> 
>    pointer := to_unconstrained_pointer (some_address, low_bound, upper_bound);

Because we wanted to allow compilers to implement
access-to-unconstrained as a single address, pointing to a chunk of
memory that stores both the dope (bounds, &c) and the data.  Given that
implementation, the above is impossible to implement, because the C
compiler presumably didn't leave room for the dope.

It is possible to implement what you suggest, if you implement these
kinds of pointers as a pair (dope, address of data) or (address of dope,
address of data).  But we didn't want to require that, because it's hard
to implement, and (more importantly) many Ada 83 compilers had already
done it the other way.  The (dope, address of data) scheme is hard to
implement because the compiler doesn't always know the size of the dope
when it needs to allocate a pointer -- in the case where it points to an
incomplete type declared in a private part and completed in the package
body.  In the (address of dope, address of data) scheme, it is
complicated to know where to allocate the dope.  And for the
incomplete-completed-in-body case, you have to assume the worst and
allocate two-word pointers, even though 99% of all pointers point to
records with no dope; that's an annoying waste.

For the same reason, we didn't allow 'Access of a slice, even though
some folks argued rather strongly in favor of that feature.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Alternate to Unchecked_Conversion - Portable?

[Christopher Green]

On Fri, 26 Feb 1999 10:42:41 GMT, robert_dewar@my-dejanews.com wrote:

>In article <36d65c7c.15971534@nntp.concentric.net>,
>  cjrgreen@concentric.net (Christopher Green) wrote:
>> Maybe the Unchecked_Conversion of access types has
>> wider approval from those who develop language standards.
>
>If you are using a language, it is incumbent on you to KNOW
>the language! The language is defined by the standard, not
>by the behavior of the compiler you are using.

There are definitions of the language and there are implementations
of the language.  The two frequently fail to coincide.  If I rely on a
property of the language that is defined by standard but poorly im-
plemented, I will end up writing poor programs that exhibit many
problems.  If I rely on a property of implementations that is widely
supported even though deprecated by the standard, I will end up
writing better programs.

I am paid to produce programs that work, not programs that use a
language in conformance to a standard.  If it were my business to
develop compilers that conform to standard, I would probably feel
differently.

-- 
Chris Green
Advanced Technology Center
Laguna Hills, California

Re: Alternate to Unchecked_Conversion - Portable?

[Nick Roberts]

Matthew Heaney wrote in message ...
|"Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:
|> robert_dewar@my-dejanews.com wrote in message
|> <7b3fk2$lnk$1@nnrp1.dejanews.com>...
|> [...]
|> |  OO : TT renames UC (O);
|> Is this legal?
|
|Yes, because there is a subtle difference between what a function
|returns in Ada95 vs Ada83.  Functions now return "constant objects,"
|whereas before, they returned "values."


Thanks Matt.  There it is -- RM95 4.1 -- crystal clear.

And I defer to what Robert was saying about compiler optimisations.  Nearly
all optimisations are delicate things: there are many, many ways of
potentially making correct output code go bad, often subtle and nasty ways;
it is indeed easy to look at a specific piece of source code and say "oh
well it ought to produce ... object code", but very, very hard to build in
so many special optimisations to a compiler that you can be sure it will
produce the best possible code in every circumstance!

I shall try :-)

-------------------------------------
Nick Roberts
-------------------------------------

Re: Alternate to Unchecked_Conversion - Portable?

[robert_dewar]

In article <wcc3e3txdqp.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> robert_dewar@my-dejanews.com writes:
>
> > A mantra that should be central to every programmer's
> > view of the universe is:
> >
> >   "just because it works does not mean it is right"
> >
> > A lot of programmers violate this because they don't
> > know enough to avoid violations.
>
> And the rest of us violate this by accident.
>

Good point! Indeed a common error is to write a program
with a "latent bug" that does not cause the program to
fail now, but can fause a failure later.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Alternate to Unchecked_Conversion - Portable?

[Nick Roberts]

dewar@gnat.com wrote in message <7bei3a$pjk$1@nnrp1.dejanews.com>...
[...]
|It's not so simple. Conformance to the standard is a
|desirable property, but not the only desirable property,
|and a compiler vendor who considers conformance to be
|of primary importance over all other considerations may
|well produce a very correct compiler that is not however
|usable for any number of reasons (just remember that Ada/Ed
|was fully conformant :-)
[...]

All of which granted.  I remember back to the "good old" bad old days, when
many Ada (83!) compilers -- even before the official concession to partial
implementations -- would omit whole features.  "Fixed point? Oh, yeah, well,
we're getting round to fixed point, mate. Next release, maybe."  Aaaargh.

-------------------------------------
Nick Roberts
-------------------------------------

Re: Alternate to Unchecked_Conversion - Portable?

[Nick Roberts]

But, we (programmers in the real world) also need to do what we can to
punish compiler makers whose products: (a) fail to conform to the standard;
(b) conform, but in a way that is likely to create portability difficulties
(without good excuse).  Even if this is just in the form of
disrecommendation to clients (I am a consultant) or colleagues, we need to
stand shoulder-to-shoulder.

-------------------------------------
Nick Roberts
-------------------------------------

Re: Alternate to Unchecked_Conversion - Portable?

[dewar]

In article <7be1ot$mjg$1@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
> But, we (programmers in the real world) also need to do
> what we can to punish compiler makers whose products: (a)
> fail to conform to the standard;
> (b) conform, but in a way that is likely to create
> portability difficulties (without good excuse).  Even if
> this is just in the form of disrecommendation to clients
> (I am a consultant) or colleagues, we need to stand
> shoulder-to-shoulder.

It's not so simple. Conformance to the standard is a
desirable property, but not the only desirable property,
and a compiler vendor who considers conformance to be
of primary importance over all other considerations may
well produce a very correct compiler that is not however
usable for any number of reasons (just remember that Ada/Ed
was fully conformant :-)

To take a simple example, an x86 compiler that does not
support 80-bit IEEE extended arithmetic is clearly violates
B.2(10):

   10  Floating point types corresponding to each floating
       point format fully supported by the hardware.

and is thus non-conformant. It will still be fully
validatable, since this is not the sort of thing the
validation can test with automated tests.

Does that mean the compiler is unusable, or we should
recommend that people not use it? Seems an extreme
viewpoint to me. If your application does not need 80-bit
float (or perhaps even does not want it, since it wants to
be completely portable), then this omission may be
completely unimportant.

Robert Dewar
Ada Core Technologies

P.S. Just to ensure that people do not regard the above as
special pleading for non-conformances in GNAT, please be
sure to realize that GNAT *does* support 80-bit float on
the ia32 (x86).


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own