Concatenation and Characters

Concatenation and Characters

[Justin Birtwell]

Hi,

Another Newbie question.  I"m having trouble understanding concatenation in
Ada with its unbounded strings, and the difference between Character arrays
and String arrays.

If I concatenate two Bounded Strings

S:String(1..4):="ABCD";
T:String(1..2):="EF";
U:String(1..N);
Begin
    U(1..6):=S&T;     --Constraint Error!! Why?
or...
    U:=S&T;   ---Constraint Error!  Why?

    Put(U);
end;
Also If I have an array of Characters

Chars:array range(1..3) of Characters:=('a','b','c');

How can I convert it to a string?

Put(Chars) --Compile Error:Invalid param list!

I look forward to getting answers to these pesky problems.

Thanks as always,

Justin

Re: Concatenation and Characters

[Preben Randhol]

Justin Birtwell wrote:
> Hi,
> 
> Another Newbie question.  I"m having trouble understanding concatenation in
> Ada with its unbounded strings, and the difference between Character arrays
> and String arrays.
> 
> If I concatenate two Bounded Strings
> 
> S:String(1..4):="ABCD";
> T:String(1..2):="EF";
> U:String(1..N);

What is N ?

which compiler?

-- 
Ada95 is good for you.
http://libre.act-europe.fr/Software_Matters/02-C_pitfalls.pdf

Re: Concatenation and Characters

[Justin Birtwell]

Sorry...
I declare N as an unitialized Natural.  Also I'm using the GNAT compiler.
Justin

N:Natrual;
S:String(1..4):="ABCD";
T:String(1..2):="EF";
U:String(1..N);
Begin
    U(1..6):=S&T;     --Constraint Error!! Why?
or...
    U:=S&T;   ---Constraint Error!  Why?

    Put(U);
end;

Re: Concatenation and Characters

[Preben Randhol]

Justin Birtwell wrote:
> Sorry...
> I declare N as an unitialized Natural.  Also I'm using the GNAT compiler.

But you are not allowed to do that. I mean N can be any number. You must
do:

N : Natural := 6;



-- 
Ada95 is good for you.
http://libre.act-europe.fr/Software_Matters/02-C_pitfalls.pdf

Re: Concatenation and Characters

[Justin Birtwell]

This is what I don't understand!  How can you declare a string variable when
you don't know before hand what the string is going to be?  Do you overload
the String like String(1..80) and hope for the best?  This seems like
overkill.  I know this must really be boner of a newbie question, but I'm
baffled.

I look forward to you your response,
Justin

Re: Concatenation and Characters

[Georg Bauhaus]

Justin Birtwell <jbirtwell@yahoo.com> wrote:
:  How can you declare a string variable when
: you don't know before hand what the string is going to be? 

If you don't known the length, you can't.
However, it depends on the extent of "beforehand".
Say you arrive at some point in your program where you want to
store some text in a string, to be used locally. Then you will
have a means (function) to find its length because you know what
is going to be stored in the string and
declare
   calculated_length: constant natural := image_length_of (some_data);
   booklet: constant string(1..calculated_length) := image_of (some_data);
begin
  --- use booklet
end;

Otherwise you need either bounded strings or unbounded strings,
and you will need the operations for them, to store information
the way you indicated. The operations are provided by Ada.Strings.*
packages, which see, or perhaps some chapter about strings? It's
good reading anyway, as (apparently) years of experience in string
handling have influenced the design of these packages, and so they
are full of useful information.

Sometimes it might also be more useful to just not store the information
in string variables and instead pass it on to where it is used, via
subprogram parameters.

-- Georg

Re: Concatenation and Characters

[Preben Randhol]

Justin Birtwell wrote:
> This is what I don't understand!  How can you declare a string variable when
> you don't know before hand what the string is going to be?  Do you overload
> the String like String(1..80) and hope for the best?  This seems like
> overkill.  I know this must really be boner of a newbie question, but I'm
> baffled.

Relax :-)

The point is that Ada is a strict language. It does boundary checks etc
and to do this it needs to know the size of the string. But you also
have variable strings. Let me first show you an example:

with Ada.Strings.Unbounded;
use  Ada.Strings.Unbounded;
procedure string_test is

   First_Name : String (1 .. 6) := "Preben";
   Sirname    : String (1 .. 7) := "Randhol";

   -- Defining a String with fixed length
   Full_Name : String (1 .. 14);

   Variable  : Unbounded_String;
begin
   
   Full_Name := First_Name & " " & Sirname;

   -- Another way

   declare
      Name : String := First_Name & " " & Sirname;
   begin
      -- You can now use Name here. You don't have to say that 
      -- it is 1 .. 14 because it will be defined as you use the :=
   end;

   -- Another way using Unbounded string:

   Variable := To_Unbounded (First_Name & " ");  
   Variable := Variable & To_Unbounded (Sirname);

   --  You see that you can now have a variable length string and
   --  Add parts as you like.

end string_test;

> 
> I look forward to you your response,
> Justin
> 
> 


-- 
Ada95 is good for you.
http://libre.act-europe.fr/Software_Matters/02-C_pitfalls.pdf

Re: Concatenation and Characters

[Robert A Duff]

"Justin Birtwell" <jbirtwell@yahoo.com> writes:

> This is what I don't understand!  How can you declare a string variable when
> you don't know before hand what the string is going to be?

Type String is fixed-length, meaning that you have to know the exact
length when you create a String object.  (But different Strings can be
different lengths.)  Yes, this is somewhat restrictive.

One thing you can do is leave the bounds off.  That's allowed if the
String has an initial value, and the String is then exactly as long as
that value (and its length never changes).  Like this:

    S: String := "ABCD";
    T: String := "EF";
    U: String := S & T; -- U has bounds 1..6.

Note that you can write functions that return "String" -- the length of
the String is determined when the function returns, and can be different
each time it's called.  And you can use a call to initialize a variable
or constant:

    X: constant String := Func(...);

In fact, "&" is really just a built-in function that works this way.

If you really want strings whose length changes over time, you should
use the Bounded or Unbounded_Strings packages.  Unbounded_Strings is the
most flexible.

Your other question was:

> Chars:array range(1..3) of Characters:=('a','b','c');
> 
> How can I convert it to a string?
> 
> Put(Chars) --Compile Error:Invalid param list!

You can use a type conversion, as in:

    Put(String(Chars));

There are lots of complicated rules about what types may be converted to
what other types -- look up "type conversion" in the RM or some
textbook.

By the way, you could have used a string_literal above:

    Chars: array (1..3) of Character := "abc";

String_literals are not specific to type String; they work for any
"string type".  A string type is any one-dimensional array of a
character type.  A character type is any enumeration type that has
character literals -- although you normally only need the predefined
ones Character and Wide_Character.  The (anonymous) type of Chars is a
string type.

Or, you could consider whether you really want Chars to have a separate
type -- you could say:

    Chars: String := "abc";

or

    Chars: constant String := "abc";

if Chars never changes.  Then you can "Put(Chars);".

- Bob

Re: Concatenation and Characters

[Justin Birtwell]

Oh,

N:Natural;
S:String(1..N);  Doesn't give me a compile error.  Any ideas why?

Re: Concatenation and Characters

[Preben Randhol]

Justin Birtwell wrote:
> Oh,
> 
> N:Natural;
> S:String(1..N);  Doesn't give me a compile error.  Any ideas why?

Because as I said N can be anything. When I tested it N was 13423763 (or
some large number like that). This leads to that S becomes a string from
1 to 13423763 which is huge.

When you tried perhaps N was 3 then S is from 1 .. 3 and you get
contraint_error.

I got Storage_Error (= out of memory)

Preben
-- 
Ada95 is good for you.
http://libre.act-europe.fr/Software_Matters/02-C_pitfalls.pdf

Re: Concatenation and Characters

[Mark Biggar]

Justin Birtwell wrote:
> Oh,
> 
> N:Natural;
> S:String(1..N);  Doesn't give me a compile error.  Any ideas why?

Becasue evaluating an uninitialized variable is only a bounded error,
which is handled at run-time.  The code is allowed to do one of a small
list of things which includes: raise a run-time exception or use
what ever junk value is found there.  The compiler is allow to, but does
not have to, warn you about the use of uninitialized variables, beceause
in the general case determining this at compile time is equilivant to
solving the halting problem.

I your case it is likely that your compiler did the second thing above:
used the junk value (very likely 0) and thus S was too small (N needs to
be at least 6 for your example to work) and thus you get a CE.


-- 
Mark Biggar
mark.a.biggar@attbi.com

Re: Concatenation and Characters

[Stephen Leake]

Mark Biggar <mark.a.biggar@attbi.com> writes:

> Justin Birtwell wrote:
> > Oh,
> > N:Natural;
> > S:String(1..N);  Doesn't give me a compile error.  Any ideas why?
> 
> <snip>
> 
> I your case it is likely that your compiler did the second thing above:
> used the junk value (very likely 0) and thus S was too small (N needs to
> be at least 6 for your example to work) and thus you get a CE.

Actually, N needs to be _exactly_ 6 for the code to avoid Constraint_Error.

-- 
-- Stephe

Re: Concatenation and Characters

[Mark Biggar]

Stephen Leake wrote:
> Mark Biggar <mark.a.biggar@attbi.com> writes:
> 
> 
>>Justin Birtwell wrote:
>>
>>>Oh,
>>>N:Natural;
>>>S:String(1..N);  Doesn't give me a compile error.  Any ideas why?
>>
>><snip>
>>
>>I your case it is likely that your compiler did the second thing above:
>>used the junk value (very likely 0) and thus S was too small (N needs to
>>be at least 6 for your example to work) and thus you get a CE.
> 
> 
> Actually, N needs to be _exactly_ 6 for the code to avoid Constraint_Error.
> 

He had too examples, the first:

S(1..6) := T&U;

works with N >=6

the second:

S := T&U

does require exactly 6.


-- 
Mark Biggar
mark.a.biggar@attbi.com

Re: Concatenation and Characters

[Programmer Dude]

Mark Biggar wrote:

> Becasue evaluating an uninitialized variable is only a bounded error,
> which is handled at run-time.

I'm new to, and just beginning to explore, Ada.  It surprised me that
Ada allows evalutation of an uninitialized variable without saying
*something* about it during compile.

Surely I'm missing something?

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|



Opinions expressed herein are my own and may not represent those of my employer.

Re: Concatenation and Characters

[Preben Randhol]

Programmer Dude wrote:
> Mark Biggar wrote:
> 
>> Becasue evaluating an uninitialized variable is only a bounded error,
>> which is handled at run-time.
> 
> I'm new to, and just beginning to explore, Ada.  It surprised me that
> Ada allows evalutation of an uninitialized variable without saying
> *something* about it during compile.
> 
> Surely I'm missing something?

Here is an example:

with Ada.Text_IO; use Ada.Text_IO;

procedure uninit is
   A  : Integer;
   B  : Integer := 2;
begin

   if A > B then
      Put_Line ("A is greater than B");
   else
      Put_Line ("B is greater than A");
   end if;
end uninit;


Compiling it with GNAT:

gnatmake uninit.adb 

gnatgcc -c uninit.adb
uninit.adb:4:04: warning: "A" is never assigned a value
gnatbind -x uninit.ali
gnatlink uninit.ali

You can also compile with the -gnatwe flag which treats all warnings as
errors.

Regards,
Preben
-- 
This is Ada land. On quiet nights you can hear C programmers debug.

Re: Concatenation and Characters

[Wes Groleau]

> I'm new to, and just beginning to explore, Ada.  It surprised me that
> Ada allows evalutation of an uninitialized variable without saying
> *something* about it during compile.

It surprised me that Java required initializing a variable
to a meaningless value when any idiot could see it was
assigned to something reasonable in before any other reference.
And refused to compile without it.  And the J-fans have the
nerve to complain that Ada is "anal"  :-)

Re: Concatenation and Characters

[Georg Bauhaus]

Wes Groleau <wesgroleau@despammed.com> wrote:
:   And the J-fans have the
: nerve to complain that Ada is "anal"  :-)

(J is a programming language in the APL family.)

-- georg

Re: Concatenation and Characters

[Mark Biggar]

Programmer Dude wrote:
> Mark Biggar wrote:
> 
> 
>>Becasue evaluating an uninitialized variable is only a bounded error,
>>which is handled at run-time.
> 
> 
> I'm new to, and just beginning to explore, Ada.  It surprised me that
> Ada allows evalutation of an uninitialized variable without saying
> *something* about it during compile.
> 
> Surely I'm missing something?

It should be obvious that the general problem of detecting all
accesses to uninitialized variables is equivalent to the halting
problem.  So it is impossible for a compiler to do a perfect job, thus
some form of run-time detection or action is necessary anyway.  So the
LRM can't require compile time detection, so it makes it optional.  The
LRM does allow compilers to warn you when you write code that will
always raise an expection and as raising Program_Error is one of the
allowed run-time responses to accessing an uninitialized variable the
LRM does allows for optional warnings for this case.  If your complier
doesn't issue such warnings, it's only a "quality of implementation"
issue not a compiler bug.

-- 
Mark Biggar
mark.a.biggar@attbi.com

Re: Concatenation and Characters

[Dmitry A.Kazakov]

Mark Biggar wrote:

> Programmer Dude wrote:

>> I'm new to, and just beginning to explore, Ada.  It surprised me that
>> Ada allows evalutation of an uninitialized variable without saying
>> *something* about it during compile.
>> 
>> Surely I'm missing something?
> 
> It should be obvious that the general problem of detecting all
> accesses to uninitialized variables is equivalent to the halting
> problem.  So it is impossible for a compiler to do a perfect job, thus
> some form of run-time detection or action is necessary anyway.  So the
> LRM can't require compile time detection, so it makes it optional.  The
> LRM does allow compilers to warn you when you write code that will
> always raise an expection and as raising Program_Error is one of the
> allowed run-time responses to accessing an uninitialized variable the
> LRM does allows for optional warnings for this case.  If your complier
> doesn't issue such warnings, it's only a "quality of implementation"
> issue not a compiler bug.

I think you missed the point. The question was about the language not a 
compiler.

It is true that no compiler can detect all uninitialized variables. So?

Then the language shall require them to be either initialized or 
*explicitly* specified as uninitialized:

X : Integer with null; -- or some other syntax

Maybe one should require this also for out-parameters (via default value):

procedure Foo (X : out Integer := 23);
function Foo returns Integer := 23;

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Concatenation and Characters

[Wes Groleau]

Dmitry A.Kazakov wrote:
> Then the language shall require them to be either initialized or 
> *explicitly* specified as uninitialized:

It already does:

    O : Some_Type;             -- explicitly uninitialized
    O : Some_Type := Default;  -- explicitly initialized

It's fairly obvious which is which, and there is no third option
that I know of.

> procedure Foo (X : out Integer := 23);

That's obviously explicitly initialized.

> function Foo returns Integer := 23;

You're saying that instead raising program_error for failing to hit
a return statement we should look to a default result on the spec?

No, thank you.

Re: Concatenation and Characters

[Dmitry A. Kazakov]

On Mon, 21 Oct 2002 09:13:53 -0500, Wes Groleau
<wesgroleau@despammed.com> wrote:

>Dmitry A.Kazakov wrote:
>> Then the language shall require them to be either initialized or 
>> *explicitly* specified as uninitialized:
>
>It already does:
>
>    O : Some_Type;             -- explicitly uninitialized
>    O : Some_Type := Default;  -- explicitly initialized
>
>It's fairly obvious which is which, and there is no third option
>that I know of.

Computer is a deterministic system, so one could claim that everything
is explicit. I would not count

O : Some_Type;

for an explicit specification that O is uninitialized.

1. In case of controlled, access, task, protected object types, O *is*
initialized.

2. In any case the syntax form for an uninitialized variable should be
no shorter than another (safer) one. For example:

O : Some_Type := <>;

or

O : Some_Type with null;

>> procedure Foo (X : out Integer := 23);
>
>That's obviously explicitly initialized.

The point is that *maybe* 

procedure Foo (X : out Integer);

should be made illegal for types which have no reasonable initial
value, because there is a possibility that X will be left unset. If it
is a desired behavior then probably it would be better to make it
clear from the specification.

>> function Foo returns Integer := 23;
>
>You're saying that instead raising program_error for failing to hit
>a return statement we should look to a default result on the spec?

Raising an exception is a run-time fault, which is usually too late. 

As for looking in spec, well, for what ever reason Ada requires that
all defaults be repeated in the bodies (:-))

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Concatenation and Characters

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
:>> procedure Foo (X : out Integer := 23);
: procedure Foo (X : out Integer);
:>> function Foo returns Integer := 23;

Anything wrong with explicitly passing a success indication
parameter or a default value? For example,

  function foo(default: integer:= 23) return Integer;

: [...] should be made illegal for types which have no reasonable initial
: value, because there is a possibility that X will be left unset. If it
: is a desired behavior then probably it would be better to make it
: clear from the specification.

-- georg

Re: Concatenation and Characters

[Dmitry A.Kazakov]

Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> :>> procedure Foo (X : out Integer := 23);
> : procedure Foo (X : out Integer);
> :>> function Foo returns Integer := 23;
> 
> Anything wrong with explicitly passing a success indication
> parameter or a default value? For example,
> 
>   function foo(default: integer:= 23) return Integer;

That's another case. First of all I am not so pretty sure about function 
return values, because Ada has an explicit return statement and no explicit 
result variable. It is sometimes good, sometimes bad, but it is another 
story. My concern is out parameters which may be left unset. It is very 
unlikely with function results, so I mentioned them merely for the sake of 
language regularity (function result is a special case of an out parameter).

Secondly, your example refers to program semantics, not syntax. Semantics 
cannot be checked or verified neither formally nor by a human being. One of 
good ideas of Ada design as I see it, was to *syntactically* mark the 
constructs which are potentially dangerous, make them visible for both who 
writes and who reads the program. Because an uninitialized thing is a 
potential breach it should be made not disallowed, but just visible. 
Compare it with the case statement, which requires an explicit "when 
others" when not all alternatives are covered.

A similar thing which was mentioned in c.l.a sometime ago. The default of a 
declaration should be a constant, not a variable.

> : [...] should be made illegal for types which have no reasonable initial
> : value, because there is a possibility that X will be left unset. If it
> : is a desired behavior then probably it would be better to make it
> : clear from the specification.

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Concatenation and Characters

[Georg Bauhaus]

Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> wrote:
: Secondly, your example refers to program semantics, not syntax. Semantics 
: cannot be checked or verified neither formally nor by a human being.

Hmmm....  Wasn't there something in SPARK...

: One of 
: good ideas of Ada design as I see it, was to *syntactically* mark the 
: constructs which are potentially dangerous, make them visible for both who 
: writes and who reads the program.

o.K. it is not built into the language, but a syntactically valid
subprogram a la

  procedure fill(bowl: out glass; filled: out boolean);

does inform readers about a potentially unsatisfying dring?

-- georg

Re: Concatenation and Characters

[Lutz Donnerhacke]

* Georg Bauhaus wrote:
> o.K. it is not built into the language, but a syntactically valid
> subprogram a la
> 
>   procedure fill(bowl: out glass; filled: out boolean);
> 
> does inform readers about a potentially unsatisfying dring?

It raises EDONTDRINKANDDRIVE.

Re: Concatenation and Characters

[Georg Bauhaus]

Lutz Donnerhacke <lutz@iks-jena.de> wrote:
: * Georg Bauhaus wrote:
:> o.K. it is not built into the language, but a syntactically valid
:> subprogram a la
:> 
:>   procedure fill(bowl: out glass; filled: out boolean);
:> 
:> does inform readers about a potentially unsatisfying dring?
: 
: It raises EDONTDRINKANDDRIVE.

No it doesn't :)

package drinks is
   
   EDONTDRINKANDDRIVE: exception;
   -- everyone knows this
   
   subtype up_to is float range 0.0..1.1365;
   -- filling glasses looks more honest in Britain
   
   type vessel is
     tagged record
	watermark: up_to := 0.0;
     end record;
   
   procedure refill(v: in out vessel);
   --  might raise EDONTDRINKANDDRIVE under some circumstances

   type glass is new vessel with null record;
   -- it's for humans, otherwise we might want saucers, buckets, troughs.
   -- (Or vats in case of a famous monk.) (Is it true that
   -- beer is served from tubs in some rural Irish pubs?)
   
   procedure fill(cupped: in out glass'class; filled: out boolean);
   --  `cupped` is filled iff `filled = true` on return
   
end drinks;



package body drinks is
   
   generous: constant := 0.9463;
   -- US bar keeper in continental Europe (that's
   -- _more_ than what you might get here, when comparing
   -- liquid level to glass height.)
   
   
   must_drive_home: constant boolean:= false;
   -- an accidential circumstance of life
   
   
   procedure refill(v: in out vessel) is
   begin
      if must_drive_home then
	 raise EDONTDRINKANDDRIVE;
      end if;
      v.watermark := generous;
   end refill;
   
   
   procedure fill (cupped: in out glass'class; filled: out boolean) is
   begin
      refill(cupped);
      filled := true;
   exception
      -- ... 
      when others =>  -- including EDONTDRINKANDDRIVE:
         filled := false;
   end fill;

end drinks;

-- georg

Re: Concatenation and Characters

[Dmitry A. Kazakov]

On Tue, 22 Oct 2002 12:05:27 +0000 (UTC), Georg Bauhaus
<sb463ba@l1-hrz.uni-duisburg.de> wrote:

>Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> wrote:
>: Secondly, your example refers to program semantics, not syntax. Semantics 
>: cannot be checked or verified neither formally nor by a human being.
>
>Hmmm....  Wasn't there something in SPARK...

semantics check => halting problem

>: One of 
>: good ideas of Ada design as I see it, was to *syntactically* mark the 
>: constructs which are potentially dangerous, make them visible for both who 
>: writes and who reads the program.
>
>o.K. it is not built into the language, but a syntactically valid
>subprogram a la
>
>  procedure fill(bowl: out glass; filled: out boolean);
>
>does inform readers about a potentially unsatisfying dring?

No. [ Of course, one could write an appropriate comment, but this sort
of things can be well applied to any language even to ugly C++.]

In this case "bowl" and "filled" have different semantics. "bowl" can
be left uninitailized (I assume that "glass" isn't controlled),
"filled" shall be always set. So I wished that this difference would
be exposed through the syntax. Which way, it is another question. It
could be for example:

procedure fill(bowl: out glass := <>; filled: out boolean := True);

Here I see from the spec, that bowl could be possibly invalid.

Should I write:

procedure fill(bowl: out glass; filled: out boolean);

then the compiler would complain that this form of parameter
specification is allowed for only the types having initial values.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Concatenation and Characters

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: 
: semantics check => halting problem

halting problem => infinite program/data size
(otherwise just hard work, may take too long or not)

: In this case "bowl" and "filled" have different semantics. "bowl" can
: be left uninitailized (I assume that "glass" isn't controlled),
: "filled" shall be always set. So I wished that this difference would
: be exposed through the syntax. Which way, it is another question.

But which way is there to satisfy any request made this way?
Is there any way to be sure that bit(n) of memory(k) or
register(m) will be "valid", so filled does reflect what it was
intended to reflect?
As you said, that's difficult, or worse than that, right?

: then the compiler would complain that this form of parameter
: specification is allowed for only the types having initial values.

Ah, o.k., but can this be done for deeply nested specifications?

-- georg

Re: Concatenation and Characters

[Dmitry A. Kazakov]

On Wed, 23 Oct 2002 14:39:47 +0000 (UTC), Georg Bauhaus
<sb463ba@l1-hrz.uni-duisburg.de> wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>: 
>: semantics check => halting problem
>
>halting problem => infinite program/data size
>(otherwise just hard work, may take too long or not)

Right. And well, formally, there is no difference between Assembler
and Ada. (:-))

>: In this case "bowl" and "filled" have different semantics. "bowl" can
>: be left uninitailized (I assume that "glass" isn't controlled),
>: "filled" shall be always set. So I wished that this difference would
>: be exposed through the syntax. Which way, it is another question.
>
>But which way is there to satisfy any request made this way?
>Is there any way to be sure that bit(n) of memory(k) or
>register(m) will be "valid", so filled does reflect what it was
>intended to reflect?
>As you said, that's difficult, or worse than that, right?

I said only that the difference should be made visible. Should we
apply a reasoning like above to the access types, we could claim that
all that one need is "void *", because there is no way to ensure that
in all cases an X of "type X is access all Y" really points to an Y.

>: then the compiler would complain that this form of parameter
>: specification is allowed for only the types having initial values.
>
>Ah, o.k., but can this be done for deeply nested specifications?

Of course. The rule could by very primitive:

If a type has no default constructor, then all [non-imported]
variables and out parameters of the type shall be "initialized" by
either a value or the box <>.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Concatenation and Characters

[Warren W. Gay VE3WWG]

Wes Groleau wrote:
> Dmitry A.Kazakov wrote:
> 
>> Then the language shall require them to be either initialized or 
>> *explicitly* specified as uninitialized:
> 
> 
> It already does:
> 
>    O : Some_Type;             -- explicitly uninitialized
>    O : Some_Type := Default;  -- explicitly initialized
> 
> It's fairly obvious which is which, and there is no third option
> that I know of.

Actually, the first case can be initialized if the type
is an access type (it is initialized to null).

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Concatenation and Characters

[Georg Bauhaus]

Programmer Dude <cjsonnack@mmm.com> wrote:
: I'm new to, and just beginning to explore, Ada.  It surprised me that
: Ada allows evalutation of an uninitialized variable without saying
: *something* about it during compile.
: 
: Surely I'm missing something?

try this with your Java compiler:

	int k;  // not initialised

	try
	    {
		k = Integer.parseInt("abc");
	    }
	catch (NumberFormatException nfe)
	    {
		k = Integer.parseInt("abc");
		// That's stupid, o.K., but Sun's compiler is silent.
		// same for jikes
	    }

	if (k == 0)  // no complaint here
	    {
		k++;  // neither
	    }

Is this consistent?


-- georg

Re: Concatenation and Characters

[Programmer Dude]

Georg Bauhaus wrote:

>> Surely I'm missing something?
> 
> try this with your Java compiler:

Java??  Who cares about Java?!?!  ;-\


So, bottom line from the answers I've read is that Ada (the language)
allows uninitialized variables to be used which *may* (must?) require
a run-time exception.... but what if the random value in the variable
isn't a contraint violation?  Does that mean an uninitialized variable
*could* be taken seriously and never detected as having a random bit
pattern?

Surely not??

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|



Opinions expressed herein are my own and may not represent those of my employer.

Re: Concatenation and Characters

[Jim Rogers]

Programmer Dude wrote:

> Georg Bauhaus wrote:
> 
> 
>>>Surely I'm missing something?
>>>
>>try this with your Java compiler:
>>
> 
> Java??  Who cares about Java?!?!  ;-\
> 
> 
> So, bottom line from the answers I've read is that Ada (the language)
> allows uninitialized variables to be used which *may* (must?) require
> a run-time exception.... but what if the random value in the variable
> isn't a contraint violation?  Does that mean an uninitialized variable
> *could* be taken seriously and never detected as having a random bit
> pattern?
> 


If the compiler detects that you are attempting to use an uninitialized
value it will issue a diagnostic message. It is never a good thing to
release a program without first addressing and eliminating all compiler
diagnostic messages.

Jim Rogers

Re: Concatenation and Characters

[tmoran]

> > isn't a contraint violation?  Does that mean an uninitialized variable
> > *could* be taken seriously and never detected as having a random bit
> > pattern?
> If the compiler detects that you are attempting to use an uninitialized
  IIRC some machine architectures have had descriptor bits that generated
a fault when that word was read before being written.
  What fraction of bugs are due to uninitialized variables?

Re: Concatenation and Characters

[Programmer Dude]

Jim Rogers wrote:

>> So, bottom line from the answers I've read is that Ada (the language)
>> allows uninitialized variables to be used which *may* (must?) require
>> a run-time exception.... but what if the random value in the variable
>> isn't a contraint violation?  Does that mean an uninitialized variable
>> *could* be taken seriously and never detected as having a random bit
>> pattern?
> 
> If the compiler detects that you are attempting to use an uninitialized
> value it will issue a diagnostic message. It is never a good thing to
> release a program without first addressing and eliminating all compiler
> diagnostic messages.

Oh, I agree completely.  I have--where possible--my compilers set to
treat warnings as errors when compiling for release.

But is this *required* behavior or QOI behavior?  Some of the posts
seem to suggest this is not required by the language spec, and THAT'S
what I'm finding slightly surprising.

I guess I'm wondering what behavior the language requires.  If it is
required that uninitialized variables never be evaluated, I can see
an implementation choosing not to attempt to diagnose this at compile
time and using another mechanism to detect it at run-time (such as
special values or descriptor bits or whatever).

Upthread Preben Randhol wrote this:

| with Ada.Text_IO; use Ada.Text_IO;
| 
| procedure uninit is
|    A  : Integer;
|    B  : Integer := 2;
| begin
| 
|    if A > B then
|       Put_Line ("A is greater than B");
|    else
|       Put_Line ("B is greater than A");
|    end if;
| end uninit;

Maybe my question is best stated thus: is there any correct implentation
of Ada that would allow this code to run?

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|



Opinions expressed herein are my own and may not represent those of my employer.

Re: Concatenation and Characters

[Jeffrey Carter]

Programmer Dude wrote:
> Upthread Preben Randhol wrote this:
> 
> | with Ada.Text_IO; use Ada.Text_IO;
> | 
> | procedure uninit is
> |    A  : Integer;
> |    B  : Integer := 2;
> | begin
> | 
> |    if A > B then
> |       Put_Line ("A is greater than B");
> |    else
> |       Put_Line ("B is greater than A");
> |    end if;
> | end uninit;
> 
> Maybe my question is best stated thus: is there any correct implentation
> of Ada that would allow this code to run?

All correct implementations of Ada must compile and execute this 
program. Ada does not require default initialization of variables except 
for access variables, if we limit ourselves to elementary types. Ada 
does not require that compilers detect references to uninitialized 
variables. Ada does not require that references to uninitialized 
variables be detected at run time.

Some compilers will warn you of references to uninitialized variables, 
but that is not required.

In general, detecting all references to uninitialized variables during 
compilation, without ever incorrectly flagging a reference to an 
initialized variable, is impossible. Compilers that issue warnings 
usually only do so for "simple" cases.

Ada is intended for embedded, real-time systems. The overhead of 
requiring default initialization of all variables may not be acceptable 
for such systems. This was especially true in the early 1980s when Ada 
was first being developed.

Between the overhead of default initialization and the impossibility of 
detecting references to uninitialized variables, the language did not 
require such things. The revision process for the language has backwards 
compatibility as a major goal, so don't expect this to change.

However, you might be interested in pragma Normalize_Scalars in the 
Safety and Security Annex (Annex H). If your compiler supports this 
Annex and you can accept the overhead, this pragma insures that scalars 
are default initialized to some value. When possible, this value will be 
out of range for the subtype.

-- 
Jeff Carter
"Your mother was a hamster and your father smelt of elderberries."
Monty Python & the Holy Grail

Re: Concatenation and Characters

[Robert A Duff]

Jeffrey Carter <jrcarter@acm.org> writes:

> Programmer Dude wrote:
> > Upthread Preben Randhol wrote this:
> > | with Ada.Text_IO; use Ada.Text_IO;
> > | | procedure uninit is
> > |    A  : Integer;
> > |    B  : Integer := 2;
> > | begin
> > | |    if A > B then
> > |       Put_Line ("A is greater than B");
> > |    else
> > |       Put_Line ("B is greater than A");
> > |    end if;
> > | end uninit;
> > Maybe my question is best stated thus: is there any correct
> > implentation
> > of Ada that would allow this code to run?

>...The revision process for the language has backwards
> compatibility as a major goal, so don't expect this to change.

But it *did* change.  In Ada 83, the above program was erroneous (i.e.,
had unpredictable behavior), whereas in Ada 95, it has a bounded error.
It must print "A is greater than B" or "B is greater than A" or raise an
exception.

Note that the Ada compiler will also fail to detect the *other* bug in
this program -- namely, the second Put_Line should print
"B is greater than or equal to A".  ;-)

Even SPARK would fail to detect such a bug, if the bug occurred in both
the code and the formal specification!

- Bob

Re: Concatenation and Characters

[Jeffrey Carter]

Robert A Duff wrote:
> Jeffrey Carter <jrcarter@acm.org> writes:
> 
>>...The revision process for the language has backwards
>>compatibility as a major goal, so don't expect this to change.

"This" referred to the lack of a requirement to detect a reference to an 
uninitialized variable.

> But it *did* change.  In Ada 83, the above program was erroneous (i.e.,
> had unpredictable behavior), whereas in Ada 95, it has a bounded error.
> It must print "A is greater than B" or "B is greater than A" or raise an
> exception.

The definition of what happens changed. The lack of a requirement to 
detect references to uninitialized variables didn't change.

-- 
Jeff Carter
"This school was here before you came,
and it'll be here before you go."
Horse Feathers

Re: Concatenation and Characters

[Pascal Obry]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> Note that the Ada compiler will also fail to detect the *other* bug in
> this program -- namely, the second Put_Line should print
> "B is greater than or equal to A".  ;-)

This is unfortunate, I think Ada compiler should include a kind of NLP (Natural
Language Processing) and a good AI module :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Concatenation and Characters

[Matthew Heaney]

"Jeffrey Carter" <jrcarter@acm.org> wrote in message
news:3DB4AD20.4070109@acm.org...
>
> All correct implementations of Ada must compile and execute this
> program. Ada does not require default initialization of variables except
> for access variables, if we limit ourselves to elementary types. Ada
> does not require that compilers detect references to uninitialized
> variables. Ada does not require that references to uninitialized
> variables be detected at run time.

This isn't quite right.  If an object of a discrete type is used to index an
array, the compiler is required to ensure that the object --even if
uninitialized-- is only used to index an actual component of the array
object.

For example:

procedure Op (S : String) is
  I : Positive;
begin
  S (I) := 'x';
end;

The Ada95 language guarantees that index I will only touch the memory owned
by array object S.

This is one area where Ada95 differs from Ada83, which made no such
guarantee.

Re: Concatenation and Characters

[Jeffrey Carter]

Matthew Heaney wrote:
> This isn't quite right.  If an object of a discrete type is used to index an
> array, the compiler is required to ensure that the object --even if
> uninitialized-- is only used to index an actual component of the array
> object.
> 
> For example:
> 
> procedure Op (S : String) is
>   I : Positive;
> begin
>   S (I) := 'x';
> end;

I presume you mean "S : in out String"?

> 
> The Ada95 language guarantees that index I will only touch the memory owned
> by array object S.
> 
> This is one area where Ada95 differs from Ada83, which made no such
> guarantee.

This has nothing to do with detecting a reference to an uninitialized 
variable. It is about bound checking of array indexing, which did exist 
in Ada 83. Unless run-time checks are suppressed, this behaves as if it 
were written

procedure Op (S : in out String) is
    I : Positive;
begin
    if I not in S'range then
       raise Constraint_Error;
    end if;

    S (I) := 'x';
end Op;

This was true in Ada 83. This is true even if I is initialized:

-- In Op:
I : Positive := 7;

-- Elsewhere:
X : String := "abcdefg";
...
Op (S => X (3 .. 5) ); -- Raises Constraint_Error

With run-time checks suppressed, what happens is anyone's guess, in Ada 
83 and Ada.

-- 
Jeff Carter
"This school was here before you came,
and it'll be here before you go."
Horse Feathers

Re: Concatenation and Characters

[Robert A Duff]

Jeffrey Carter <jrcarter@acm.org> writes:

> Matthew Heaney wrote:
> > This isn't quite right.  If an object of a discrete type is used to index an
> > array, the compiler is required to ensure that the object --even if
> > uninitialized-- is only used to index an actual component of the array
> > object.
> > For example:
> > procedure Op (S : String) is
> >   I : Positive;
> > begin
> >   S (I) := 'x';
> > end;
> 
> I presume you mean "S : in out String"?
> 
> > The Ada95 language guarantees that index I will only touch the memory
> > owned
> > by array object S.
> > This is one area where Ada95 differs from Ada83, which made no such
> > guarantee.
> 
> This has nothing to do with detecting a reference to an uninitialized
> variable.

It has to do with uninitialized variables, certainly, if not their
"detection".  In Ada 83, there was no requirement for an array bounds
check in the above program.  That's because the execution was erroneous.
In Ada 95, there *is* a requirement for an array bounds check.
In fact, the *only* purpose of a bounds check in the above example is to
detect uninit vars -- if I were initialized, there would be no need for
the check.  So I think your "...nothing to do with..." claim is
overstated at best.

This *does* make a difference in practise.  Ada 83 compilers *were*
sometimes smart enough to notice that "S(I) := ..." does not need a
range check, and eliminated the check, so that statement could destroy
arbitrary memory locations.  Ada 95 compilers are not allowed to do that
optimization, unless they can prove I is initialized.

The Ada 83 optimizer could reason as follows:

    I is of subtype Positive.
    So either the value of I is in Positive, or else I is uninitialized.
    If I is in Positive, we can leave out the array bounds check,
    because the index subtype of String is also Positive.
    If I is uninitialized, we can leave out the check because
    the program execution will be erroneous (unpredictable).

This reasoning is incorrect for an Ada 95 compiler, and the difference
is precisely in the semantics of uninit vars.

>...It is about bound checking of array indexing, which did exist
> in Ada 83.

No, as I said, bounds checking did *not* exist in Ada 83 for the above
example.  (Yes, bounds checking did exist -- but not in the cases we're
talking about.)

>... Unless run-time checks are suppressed, this behaves as if it
> were written
> 
> procedure Op (S : in out String) is
>     I : Positive;
> begin
>     if I not in S'range then
>        raise Constraint_Error;
>     end if;
> 
>     S (I) := 'x';
> end Op;
> 
> This was true in Ada 83.

Yes, this is essentially equivalent.  In Ada 83, the compiler was
allowed to optimize away the entire 'if' statement.  In Ada 95, it is
not (unless it somehow knows that I is initialized).

>... This is true even if I is initialized:
> 
> -- In Op:
> I : Positive := 7;
> 
> -- Elsewhere:
> X : String := "abcdefg";
> ...
> Op (S => X (3 .. 5) ); -- Raises Constraint_Error

Correct.

> With run-time checks suppressed, what happens is anyone's guess, in Ada
> 83 and Ada.

Correct.

- Bob

Re: Concatenation and Characters

[Jeffrey Carter]

Robert A Duff wrote:
> The Ada 83 optimizer could reason as follows:
> 
>     I is of subtype Positive.
>     So either the value of I is in Positive, or else I is uninitialized.
>     If I is in Positive, we can leave out the array bounds check,
>     because the index subtype of String is also Positive.
>     If I is uninitialized, we can leave out the check because
>     the program execution will be erroneous (unpredictable).

Well, if you say this was so, I guess it probably was so. Having used 
Ada 83 for over a decade, I never encountered a compiler that wouldn't 
check that I was in the range of S (not the index subtype of String). 
Clearly the range of S could be anything from null through Positive. I'm 
surprised that Ada 83 would allow a variable to index an array of 
unknown range without a bounds check.

-- 
Jeff Carter
"What I wouldn't give for a large sock with horse manure in it."
Annie Hall

Re: Concatenation and Characters

[Matthew Heaney]

"Jeffrey Carter" <jrcarter@acm.org> wrote in message
news:3DB60342.3020104@acm.org...
>
> Well, if you say this was so, I guess it probably was so. Having used
> Ada 83 for over a decade, I never encountered a compiler that wouldn't
> check that I was in the range of S (not the index subtype of String).
> Clearly the range of S could be anything from null through Positive. I'm
> surprised that Ada 83 would allow a variable to index an array of
> unknown range without a bounds check.

We were using Ada on Solaris, and it was in fact very easy to get a core
dump if you used an initialized variable to index an array.

Many Ada83 programmers made the same mistake: assuming that there's an
automatic check when indexing an array.  There was not, in Ada83.  There is
now, in Ada95.

Re: Concatenation and Characters

[Jeffrey Carter]

Matthew Heaney wrote:
> 
> We were using Ada on Solaris, and it was in fact very easy to get a core
> dump if you used an initialized variable to index an array.

I presume you mean "uninitialized" here.

> 
> Many Ada83 programmers made the same mistake: assuming that there's an
> automatic check when indexing an array.  There was not, in Ada83.  There is
> now, in Ada95.

One of the biggest sources of unexpected Constraint_Errors I encountered 
using Ada 83 was beginners assuming that a parameter of type String had 
a lower bound of one. I used a lot of Ada-83 compilers, but maybe I just 
got lucky and they all generated checks for all array indexing.

-- 
Jeff Carter
"English bed-wetting types."
Monty Python & the Holy Grail

Re: Concatenation and Characters

[Robert A Duff]

Jeffrey Carter <jrcarter@acm.org> writes:

> Robert A Duff wrote:
> > The Ada 83 optimizer could reason as follows:
> >     I is of subtype Positive.
> >     So either the value of I is in Positive, or else I is uninitialized.
> >     If I is in Positive, we can leave out the array bounds check,
> >     because the index subtype of String is also Positive.
> >     If I is uninitialized, we can leave out the check because
> >     the program execution will be erroneous (unpredictable).
> 
> Well, if you say this was so, I guess it probably was so.

Not true.  I wasn't thinking clearly.  For the example given, you are
correct that a bounds check is needed, at least on the upper bound.  I
suppose the compiler could optimize away the check on the lower bound.

In any case, although I put my foot in my mount about *that* example, I
think my more general point is correct: there are cases where an Ada 83
compiler could optimize away checks (based on the erroneousness of
uninit vars), where an Ada 95 compiler cannot (or at least has to prove
more).

>... Having used
> Ada 83 for over a decade, I never encountered a compiler that wouldn't
> check that I was in the range of S (not the index subtype of
> String). Clearly the range of S could be anything from null through
> Positive. I'm surprised that Ada 83 would allow a variable to index an
> array of unknown range without a bounds check.

- Bob

Re: Concatenation and Characters

[Jeffrey Carter]

Robert A Duff wrote:
> Not true.  I wasn't thinking clearly.  For the example given, you are
> correct that a bounds check is needed, at least on the upper bound.  I
> suppose the compiler could optimize away the check on the lower bound.

I would think even on the lower bound. The compiler knows nothing about 
the bounds. The lower bound could be any value in Positive, so a 
variable in Positive could easily be less than the lower bound just as 
it could be greater than the upper bound.

> 
> In any case, although I put my foot in my mount about *that* example, I
> think my more general point is correct: there are cases where an Ada 83
> compiler could optimize away checks (based on the erroneousness of
> uninit vars), where an Ada 95 compiler cannot (or at least has to prove
> more).

If the variable has the same subtype as the index of the array object, I 
can see this:

procedure Op (S : in out String) is
    I : Positive range S'range;
begin -- Op
    S (I) := 'x';
end Op;

I is either in range or execution is erroneous.

As I said in another post, a source of unexpected Constraint_Errors I 
encountered in Ada 83 was from beginners assuming the lower bound of a 
String parameter was one. A bounds check is required unless the index is 
known to the compiler to be in the index range of the array object.

I guess String was not a good type to use for an example. If it had been

type Index is range 1 .. 100;
type Arr is array (Index) of Integer;

I : Index;
A : Arr
...
A (I) := 1;

it would have been more obvious what we're talking about (I think).

-- 
Jeff Carter
"English bed-wetting types."
Monty Python & the Holy Grail

Re: Concatenation and Characters

[Robert A Duff]

Jeffrey Carter <jrcarter@acm.org> writes:

> Robert A Duff wrote:
> > Not true.  I wasn't thinking clearly.  For the example given, you are
> > correct that a bounds check is needed, at least on the upper bound.  I
> > suppose the compiler could optimize away the check on the lower bound.
> 
> I would think even on the lower bound. The compiler knows nothing about
> the bounds. The lower bound could be any value in Positive, so a
> variable in Positive could easily be less than the lower bound just as
> it could be greater than the upper bound.

Yes, that's right.

> > In any case, although I put my foot in my mount about *that* example, I
                                              ^^^^^
I can't even spell "mouth" right.  :-(

> > think my more general point is correct: there are cases where an Ada 83
> > compiler could optimize away checks (based on the erroneousness of
> > uninit vars), where an Ada 95 compiler cannot (or at least has to prove
> > more).
> 
> If the variable has the same subtype as the index of the array object, I
> can see this:
> 
> procedure Op (S : in out String) is
>     I : Positive range S'range;
> begin -- Op
>     S (I) := 'x';
> end Op;
> 
> I is either in range or execution is erroneous.

Yes (in Ada 83).

> As I said in another post, a source of unexpected Constraint_Errors I
> encountered in Ada 83 was from beginners assuming the lower bound of a
> String parameter was one. A bounds check is required unless the index is
> known to the compiler to be in the index range of the array object.
> 
> I guess String was not a good type to use for an example. If it had been
> 
> type Index is range 1 .. 100;
> type Arr is array (Index) of Integer;
> 
> I : Index;
> A : Arr
> ...
> A (I) := 1;
> 
> it would have been more obvious what we're talking about (I think).

Yes.  ;-)

- Bob

Re: Concatenation and Characters

[Jim Rogers]

Programmer Dude wrote:


> I guess I'm wondering what behavior the language requires.  If it is
> required that uninitialized variables never be evaluated, I can see
> an implementation choosing not to attempt to diagnose this at compile
> time and using another mechanism to detect it at run-time (such as
> special values or descriptor bits or whatever).
>



One of the reasons default initialization is difficult for numerics
in Ada is because Ada allows you to define your own numeric types.
This means that the language cannot assume any particular value is
always a correct value for any numeric type.

You can write your code to get around this using the scalar attributes
'First or 'Last as values for explicit initialization. When using
compound types such as arrays or record types you can use explicit
initialization syntax. Record definitions also allow you to specify
your own initial value for each field. In fact, these initial values
go a long way to providing the capabilities of default constructors in
other languages.

Note that the 'Valid attribute can be checked before accessing any
variable. This attribute returns TRUE when the variable contains a
valid value and FALSE when the variable contains an invalid value.

Following is an excerpt from the Ada Language Reference Manual.

13.9.1 Data Validity

Certain actions that can potentially lead to erroneous execution are not 
directly erroneous, but instead can cause objects to become abnormal. Subsequent 
uses of abnormal objects can be erroneous.

A scalar object can have an invalid representation, which means that the 
object's representation does not represent any value of the object's subtype. 
The primary cause of invalid representations is uninitialized variables.

Abnormal objects and invalid representations are explained in this subclause.

Dynamic Semantics

When an object is first created, and any explicit or default initializations 
have been performed, the object and all of its parts are in the normal state. 
Subsequent operations generally leave them normal. However, an object or part of 
an object can become abnormal in the following ways:

� An assignment to the object is disrupted due to an abort (see 9.8) or due to 
the failure of a language-defined check (see 11.6).

� The object is not scalar, and is passed to an in out or out parameter of an 
imported procedure or language-defined input procedure, if after return from the 
procedure the representation of the parameter does not represent a value of the 
parameter's subtype.

Whether or not an object actually becomes abnormal in these cases is not 
specified. An abnormal object becomes normal again upon successful completion of 
an assignment to the object as a whole.

Erroneous Execution

It is erroneous to evaluate a primary that is a name denoting an abnormal 
object, or to evaluate a prefix that denotes an abnormal object.

Bounded (Run-Time) Errors

If the representation of a scalar object does not represent a value of the 
object's subtype (perhaps because the object was not initialized), the object is 
said to have an invalid representation. It is a bounded error to evaluate the 
value of such an object. If the error is detected, either Constraint_Error or 
Program_Error is raised. Otherwise, execution continues using the invalid 
representation. The rules of the language outside this subclause assume that all 
objects have valid representations. The semantics of operations on invalid 
representations are as follows:

� If the representation of the object represents a value of the object's type, 
the value of the type is used.

� If the representation of the object does not represent a value of the object's 
type, the semantics of operations on such representations is 
implementation-defined, but does not by itself lead to erroneous or 
unpredictable execution, or to other objects becoming abnormal.

Erroneous Execution

A call to an imported function or an instance of Unchecked_Conversion is 
erroneous if the result is scalar, and the result object has an invalid 
representation.

The dereference of an access value is erroneous if it does not designate an 
object of an appropriate type or a subprogram with an appropriate profile, if it 
designates a nonexistent object, or if it is an access-to-variable value that 
designates a constant object. Such an access value can exist, for example, 
because of Unchecked_Deallocation, Unchecked_Access, or Unchecked_Conversion.

NOTES

18 Objects can become abnormal due to other kinds of actions that directly 
update the object's representation; such actions are generally considered 
directly erroneous, however.




Jim Rogers

Re: Concatenation and Characters

[Robert A Duff]

Jim Rogers <jimmaureenrogers@worldnet.att.net> writes:

> One of the reasons default initialization is difficult for numerics
> in Ada is because Ada allows you to define your own numeric types.
> This means that the language cannot assume any particular value is
> always a correct value for any numeric type.

True.  In fact, what would you like as the default initial value of
this:

    X: Integer range 1..0;

?

> Note that the 'Valid attribute can be checked before accessing any
> variable. This attribute returns TRUE when the variable contains a
> valid value and FALSE when the variable contains an invalid value.

Not "any variable" -- it doesn't work for composite types.

Anyway, 'Valid is irrelevant to the problem of uninitialized variables.
It's silly to check 'Valid of all your variables -- much easier to 
make sure they are initialized properly.  'Valid is for validating input
data, not for detecting program bugs.

By the way, it's interesting that a pre-1983 version of Ada (or maybe it
was called Green then) required run-time detection of uses of
uninitialized variables -- an exception was raised.  I presume they got
rid of that because of concerns about run-time speed (or lack of it).
I think that was a mistake: you could always use pragma Suppress if you
need the speed.  This decision (the trade-off between the debugging aid
and speed) should be in the hands of the programmer, not the language
designer.

Another issue with run-time detection is that it sometimes requires
extra bits to be allocated, which might mess up representations
(e.g., if you're interfacing to hardware).

- Bob

Re: Concatenation and Characters

[Fraser Wilson]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> True.  In fact, what would you like as the default initial value of
> this:
> 
>     X: Integer range 1..0;

And speaking of, I've occasionally had the need to return a zero
length array from a function, but there doesn't seem to be a literal
for this case.  So my code looks like this:

    type Array_Type is array (Positive range <>) of ... ;

    ....

    declare
       Empty : constant Array_Type (1 .. 0);
    begin
       return Empty;
    end;

Is this the only way?  I feel dense.

Fraser.

Re: Concatenation and Characters

[David C. Hoos]

----- Original Message ----- 
From: "Fraser Wilson" <newsfraser@blancolioni.org>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: Tuesday, October 22, 2002 10:02 AM
Subject: Re: Concatenation and Characters


<snip>
> And speaking of, I've occasionally had the need to return a zero
> length array from a function, but there doesn't seem to be a literal
> for this case.  So my code looks like this:
> 
>     type Array_Type is array (Positive range <>) of ... ;
> 
>     ....
> 
>     declare
>        Empty : constant Array_Type (1 .. 0);
>     begin
>        return Empty;
>     end;
You can just write 
       return Array_Type (1 ..0);

Re: Concatenation and Characters

[Fraser Wilson]

"David C. Hoos" <david.c.hoos.sr@ada95.com> writes:

> You can just write 
>        return Array_Type (1 ..0);

Thanks.  I'm glad there was a good reason I felt dense.  :)

Fraser.

Re: Concatenation and Characters

[Robert A Duff]

Fraser Wilson <newsfraser@blancolioni.org> writes:

> "David C. Hoos" <david.c.hoos.sr@ada95.com> writes:
> 
> > You can just write 
> >        return Array_Type (1 ..0);

Ummm.  No, you can't, actually.  "Array_Type (1 ..0)" is not an
expression, it's a subtype_mark.

However, you can write this:

    return (1..0 => 123);

if the component type is Integer, say.  This is annoying, because you
have to invent a completely junk value -- 123 is never used.

Or if you like to emphasize the type, you can use a qualified
expression:

    return Array_Type'(1..0 => 123);

It really is a language design flaw that you can't have a zero-length
positional aggregate.  String_literals don't have this flaw, so if the
component type happens to be a character type, you can say:

    return "";

> Thanks.  I'm glad there was a good reason I felt dense.  :)

;-)

- Bob

Re: Concatenation and Characters

[Dmitry A. Kazakov]

On Tue, 22 Oct 2002 16:13:43 GMT, Robert A Duff
<bobduff@shell01.TheWorld.com> wrote:

>Fraser Wilson <newsfraser@blancolioni.org> writes:
>
>> "David C. Hoos" <david.c.hoos.sr@ada95.com> writes:
>> 
>> > You can just write 
>> >        return Array_Type (1 ..0);
>
>Ummm.  No, you can't, actually.  "Array_Type (1 ..0)" is not an
>expression, it's a subtype_mark.
>
>However, you can write this:
>
>    return (1..0 => 123);
>
>if the component type is Integer, say.  This is annoying, because you
>have to invent a completely junk value -- 123 is never used.

BTW, do you know a solution of this problem for generics? Let the
array element is a generic parameter and there is no Null_Element
parameter, where to get a junk value?

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Concatenation and Characters

[Lutz Donnerhacke]

* Dmitry A Kazakov wrote:
>>However, you can write this:
>>
>>    return (1..0 => 123);
>>
>>if the component type is Integer, say.  This is annoying, because you
>>have to invent a completely junk value -- 123 is never used.
> 
> BTW, do you know a solution of this problem for generics? Let the
> array element is a generic parameter and there is no Null_Element
> parameter, where to get a junk value?

There are several other cases where a default value can't be specified (task).
Then I use
   declare
      empty : Array_Type (Offset_Type'Last ..
                          Offset_Type'Pred(Offset_Type'Last));
   begin
      return empty;
   end;

Re: Concatenation and Characters

[Dmitry A. Kazakov]

On Wed, 23 Oct 2002 09:08:24 +0000 (UTC), Lutz Donnerhacke
<lutz@iks-jena.de> wrote:

>* Dmitry A Kazakov wrote:
>>>However, you can write this:
>>>
>>>    return (1..0 => 123);
>>>
>>>if the component type is Integer, say.  This is annoying, because you
>>>have to invent a completely junk value -- 123 is never used.
>> 
>> BTW, do you know a solution of this problem for generics? Let the
>> array element is a generic parameter and there is no Null_Element
>> parameter, where to get a junk value?
>
>There are several other cases where a default value can't be specified (task).
>Then I use
>   declare
>      empty : Array_Type (Offset_Type'Last ..
>                          Offset_Type'Pred(Offset_Type'Last));
>   begin
>      return empty;
>   end;

There is a pathological case when this does not work:

type Index is new Integer range Integer'First..Integer'First;
type Array_Type is array (Index range <>) of Integer;
   
Empty : Array_Type (Index'Last..Index'Pred (Index'Last));
               -- Constraint_Error

-------------------------------

Could we inroduce an attribute, say S'Empty, which for an array type
would give an empty array and for a discrete type an empty range?

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Concatenation and Characters

[Lutz Donnerhacke]

* Dmitry A Kazakov wrote:
> On Wed, 23 Oct 2002 09:08:24 +0000 (UTC), Lutz Donnerhacke
>>Then I use
>>   declare
>>      empty : Array_Type (Offset_Type'Last ..
>>                          Offset_Type'Pred(Offset_Type'Last));
>>   begin
>>      return empty;
>>   end;
> 
> There is a pathological case when this does not work:
> 
> type Index is new Integer range Integer'First..Integer'First;
> type Array_Type is array (Index range <>) of Integer;

Of course. I'd change this construct to:
   declare
      empty : Array_Type (Offset_Type'Last ..
                          Offset_Type'Base'Pred(Offset_Type'Last));
   begin
      return empty;
   end;

But really in the case of generics, I don't expect such functionality.
Requireing an generic empty variable is more approbriate.

Re: Concatenation and Characters

[Frank J. Lhota]

> Could we inroduce an attribute, say S'Empty, which for an array type
> would give an empty array and for a discrete type an empty range?

Consider this:

    type Great_One is ( Jackie_Gleason );

    type S is array( Great_One range <> ) of Honeymooner;

What would S'Empty'First and S'Empty'Last return?

Re: Concatenation and Characters

[Dmitry A. Kazakov]

On Wed, 23 Oct 2002 17:15:47 GMT, "Frank J. Lhota"
<NOSPAM.lhota.adarose@verizon.net> wrote:

>> Could we inroduce an attribute, say S'Empty, which for an array type
>> would give an empty array and for a discrete type an empty range?
>
>Consider this:
>
>    type Great_One is ( Jackie_Gleason );
>
>    type S is array( Great_One range <> ) of Honeymooner;
>
>What would S'Empty'First and S'Empty'Last return?

Constraint_Error, I suppose. This is obviously a case when
X'First..X'Last /= X'Range. Even worse, if it could be possible to
declare Great_Nobody with no literals at all, even then, formally,
there could exist empty arrays!

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Concatenation and Characters

[Fraser Wilson]

"Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> writes:

> Consider this:
> 
>     type Great_One is ( Jackie_Gleason );
> 
>     type S is array( Great_One range <> ) of Honeymooner;
> 
> What would S'Empty'First and S'Empty'Last return?

It's certainly (imho) a bit of a wart that you need at least two
elements in the A'Range'Base to make a zero-length array.  And it's
not clear that 'First and 'Last should be defined at all when 'Range
is empty, although it's certainly convenient sometimes.

Mind you, most of the time you can test for membership in 'Range
rather than comparing directly to 'Last or 'First.

Fraser.

Re: Concatenation and Characters

[Matthew Heaney]

"Fraser Wilson" <newsfraser@blancolioni.org> wrote in message
news:uhefc429n.fsf@FWILSON.i-did-not-set--mail-host-address--so-shoot-me...
> "Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> writes:
>
> > Consider this:
> >
> >     type Great_One is ( Jackie_Gleason );
> >
> >     type S is array( Great_One range <> ) of Honeymooner;
> >
> > What would S'Empty'First and S'Empty'Last return?
>
> It's certainly (imho) a bit of a wart that you need at least two
> elements in the A'Range'Base to make a zero-length array.  And it's
> not clear that 'First and 'Last should be defined at all when 'Range
> is empty, although it's certainly convenient sometimes.

The issue is that an enumeration type is "its own base type."  The problem
is in the declaration of Great_One, which really should have been done like
this:

type Great_One_Base is
   (Great_One_Base_First, Jackie_Gleason, Great_One_Base_Last);

subtype Great_One is Great_One_Base range
   Great_One_Base'Succ (Great_One_Base_First) ..
   Great_One_Base'Pred (Great_One_Base_Last);

type S is array (Great_One range <>) of Honeymooner.

Now all the problems go away.

Yes, this is sort of a pain, but it's simply a consequence of Ada's type
model for enumerations.  For integer discrete types, the language gives you
T'Base for free, but for enumerations you have to declare T'Base manually.

 You have the same issue when instantiating the Charles vector package,
which accepts a discrete type as a generic formal index type.  The web page
has an explanation similar to what appears above.

http://home.earthlink.net/~matthewjheaney/charles/charles-vectors-unbounded.
html

The most recent release occured on 2002/10/21.

http://home.earthlink.net/~matthewjheaney/charles/index.html

Re: Concatenation and Characters

[David C. Hoos]

Robert -- Thanks for correcting me. No excuse except
being in a hurry, and not thinking enough.
----- Original Message ----- 
From: "Robert A Duff" <bobduff@shell01.TheWorld.com>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: Tuesday, October 22, 2002 11:13 AM
Subject: Re: Concatenation and Characters


> Fraser Wilson <newsfraser@blancolioni.org> writes:
> 
> > "David C. Hoos" <david.c.hoos.sr@ada95.com> writes:
> > 
> > > You can just write 
> > >        return Array_Type (1 ..0);
> 
> Ummm.  No, you can't, actually.  "Array_Type (1 ..0)" is not an
> expression, it's a subtype_mark.
> 
> However, you can write this:
> 
>     return (1..0 => 123);
> 
> if the component type is Integer, say.  This is annoying, because you
> have to invent a completely junk value -- 123 is never used.
> 
> Or if you like to emphasize the type, you can use a qualified
> expression:
> 
>     return Array_Type'(1..0 => 123);
> 
> It really is a language design flaw that you can't have a zero-length
> positional aggregate.  String_literals don't have this flaw, so if the
> component type happens to be a character type, you can say:
> 
>     return "";

Re: Concatenation and Characters

[Stuart Palin]

Jim Rogers wrote:
> 
> Programmer Dude wrote:
<snip>
> >
> > So, bottom line from the answers I've read is that Ada (the language)
> > allows uninitialized variables to be used which *may* (must?) require
> > a run-time exception.... but what if the random value in the variable
> > isn't a contraint violation?  Does that mean an uninitialized variable
> > *could* be taken seriously and never detected as having a random bit
> > pattern?
> >
> 
> If the compiler detects that you are attempting to use an uninitialized
> value it will issue a diagnostic message. It is never a good thing to
> release a program without first addressing and eliminating all compiler
> diagnostic messages.

It is my experience that compilers only tend to give such
warnings where the use of the uninitialized value is
unconditional.  Usually, where a variable may be
uninitialized under some conditions the compiler 'assumes'
the programmer knows what they are doing and does not give a
warning.

If you want the full set of warnings you need to consider
using tools such as SPARK (or possibly/probably) some of the
Abstract Interpretation analysis tools such as Polyspace
Verifier.

The matter of Initialization is one given considerable
attention in SPARK.

In response to Programmer Dude's comments: Ada is not a
'safe' language (whatever that may mean).  It does a number
of trade-offs between supporting 'safety enhancing' concepts
and reasonably efficient implementation.  Initialization of
variables is one of these trade-offs.

SPARK uses Ada as a basis, but takes the issues of
demonstrating safety-enhancing features (such as correctness
of data flow) much further.  But it is worth noting that it
can not (always) do this within the scope of the Ada
language; which is why, in addition to sub-setting the
language, it requires annotations to add information about
the [intended] behaviour of the software.

If you are unfamiliar with SPARK, check out
www.sparkada.com.

--
Stuart Palin
[usual disclaimers]

Re: Concatenation and Characters

[Programmer Dude]

Stuart Palin wrote:

> In response to Programmer Dude's comments: Ada is not a
> 'safe' language (whatever that may mean).  It does a number
> of trade-offs between supporting 'safety enhancing' concepts
> and reasonably efficient implementation.  Initialization of
> variables is one of these trade-offs.

Ah, I understand.  Thanks for clearing that up.

And thanks to those who also responded.  Very interesting fare!!

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|



Opinions expressed herein are my own and may not represent those of my employer.

Re: Concatenation and Characters

[Georg Bauhaus]

Programmer Dude <cjsonnack@mmm.com> wrote:
: Java??  Who cares about Java?!?!  ;-\

Seems I've taken Wes' comments as beeing yours. Sorry.

Re: Concatenation and Characters

[Grein, Christoph]

>    First_Name : String (1 .. 6) := "Preben";
>    Sirname    : String (1 .. 7) := "Randhol";
> 
>    -- Defining a String with fixed length
>    Full_Name : String (1 .. 14);
> 
>    Variable  : Unbounded_String;
> begin
>    
>    Full_Name := First_Name & " " & Sirname;

Preben, have you been raised to the peerage? But then your name is
Sir Preben 
:-)

Re: Concatenation and Characters

[Preben Randhol]

Grein, Christoph wrote:
>>    Full_Name := First_Name & " " & Sirname;
> 
> Preben, have you been raised to the peerage? But then your name is
> Sir Preben 

Oops *BLUSH* Surname it should have been. No I don't want to be a Sir
:-)

-- 
Ada95 is good for you.
http://libre.act-europe.fr/Software_Matters/02-C_pitfalls.pdf

Re: Concatenation and Characters

[Grein, Christoph]

> It really is a language design flaw that you can't have a zero-length
> positional aggregate.

with Ada.Text_IO;
use  Ada.Text_IO;

procedure Xxx is

  type Empty is range 1 .. 0;
  type Array_Type is array (Positive range <>) of Empty;

  function F return Array_Type is
  begin
    return (5 .. 4 => 0);
  end;

  Nothing: Array_Type := F;

begin

  Put_Line (Boolean'Image (Nothing = (7..4 => Empty'First)));
  Put_Line (Boolean'Image (Nothing = (0..-1 => Empty'Last)));

end Xxx;


try to run this. No value can fulfil the range constraint of Empty, but it does 
not matter, since the range is empty and the value is not evaluated.

(I'm not so sure that the range 0..-1 is legal, but my compiler accepts it and 
prints True twice, and I 
just do not feel like searching the RM :-(

Re: Concatenation and Characters

[Matthew Heaney]

"Grein, Christoph" <christoph.grein@eurocopter.com> wrote in message
news:mailman.1035350522.7202.comp.lang.ada@ada.eu.org...

> (I'm not so sure that the range 0..-1 is legal, but my compiler accepts it
and
> prints True twice, and I
> just do not feel like searching the RM :-(

Subtype constraints only apply when First <= Last.  If Last < First, then it
doesn't matter what that values are.  In your case, the values 0 and -1 are
both outside the range of array index subtype Positive, but it doesn't
matter, because the range is null.

Re: Concatenation and Characters

[Grein, Christoph]

> Many Ada83 programmers made the same mistake: assuming that there's an
> automatic check when indexing an array.  There was not, in Ada83.  There is
> now, in Ada95.

RM83 4.1.1(4)
... The exception CONSTRAINT_ERROR is raised if an index value does not belong 
to the range of the corresponding index of the prefixing array ...


A: array (Some_Range) of Something;

I: Some_Range;
J: Integer;

A (I) - the range check can be omitted
A (J) - the range check cannot be omitted if Some_Range is smaller than Integer

Re: Concatenation and Characters

[Matthew Heaney]

"Grein, Christoph" <christoph.grein@eurocopter.com> wrote in message
news:mailman.1035439204.28367.comp.lang.ada@ada.eu.org...
> > Many Ada83 programmers made the same mistake: assuming that there's an
> > automatic check when indexing an array.  There was not, in Ada83.  There
is
> > now, in Ada95.
>
> RM83 4.1.1(4)
> ... The exception CONSTRAINT_ERROR is raised if an index value does not
belong
> to the range of the corresponding index of the prefixing array ...
>
>
> A: array (Some_Range) of Something;
>
> I: Some_Range;
> J: Integer;
>
> A (I) - the range check can be omitted

And there you see the problem.  If index I is initialized with garbage, then
program execution is errnoneous as soon as you use I to index into the
array.  If you're lucky you'll get a core dump.