Using Posix with Apex

Using Posix with Apex

[Paul Van Bellinghen]

 I don't know how many of you are using Rational Apex, but if you are
and want to write any code to extract arguments from a command line,
I had a devel of a time doing it. I recently modified a program that
counted lines of Ada code to take its two arguments (output file,
input file list) from the command line. I was compiling it with
Rational Apex and so I used the Posix
package provided. In order to get say, the first argument on the
command line, I wrote:

Output_File_Name.Name :=
	   Posix.To_String (Posix.Value
           (Posix_Process_Environment.Argument_List, 2));

however, I kept getting an "invalid argument" exception when the code
was executed. I called the  Rational support team and found out that
the line suld read

	Output_File_Name.Name
	   (1 .. Posix.To_String
           (Posix.Value (Posix_Process_Environment.Argument_List, 2))'
		 Length) :=
	   Posix.To_String (Posix.Value
           (Posix_Process_Environment.Argument_List, 2));

The problem was that Output_File_Name.Name and the argument to be
assigned to it had different lengths. This is not allowed by Ada's
rules for assigning to arrays - you must specify which elements of
the array are to be assigned values when the right-hand-side is
shorter than the left-hand-side.

Re: Using Posix with Apex

[Matthew Heaney]

In article <32ee8e2c.1005715@NEWS.CLOUD9.NET>, pvanbell@cloud9.net (Paul
Van Bellinghen) wrote:


>Output_File_Name.Name :=
>           Posix.To_String (Posix.Value
>           (Posix_Process_Environment.Argument_List, 2));

If you don't know the length of the string returned by a function, then in
Ada 83 just declare the object as a constant in some dynamic scope:

declare
   The_Name : constant POSIX_String :=
      POSIX.Value (POSIX_Process_Environment.Argument_List, 2);
begin
   Output_File_Name.Name (1 .. The_Name'Length) :=
       POSIX.To_String (The_Name);
end;

>however, I kept getting an "invalid argument" exception when the code
>was executed. I called the  Rational support team and found out that
>the line suld read
>
>        Output_File_Name.Name
>           (1 .. Posix.To_String
>           (Posix.Value (Posix_Process_Environment.Argument_List, 2))'
>                 Length) :=
>           Posix.To_String (Posix.Value
>           (Posix_Process_Environment.Argument_List, 2));

Rational gave you some bad advice.  Please don't write code like this:
you're calling the function twice, and it's completely unreadable.  This is
not an Ada "problem."

Use declare blocks to hold intermediate values, especially for the result
of a function that returns an unconstrained array.  (Just remember: in Ada
83 you have to declare the object as a constant; this rule went away in Ada
95.)

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Using Posix with Apex

[Dr. Peter E. Obermayer]

Matthew Heaney wrote:
> 
> In article <32ee8e2c.1005715@NEWS.CLOUD9.NET>, pvanbell@cloud9.net (Paul
> Van Bellinghen) wrote:
> 
> >Output_File_Name.Name :=
> >           Posix.To_String (Posix.Value
> >           (Posix_Process_Environment.Argument_List, 2));
> 
> If you don't know the length of the string returned by a function, then in
> Ada 83 just declare the object as a constant in some dynamic scope:
> 
> declare
>    The_Name : constant POSIX_String :=
>       POSIX.Value (POSIX_Process_Environment.Argument_List, 2);
> begin
>    Output_File_Name.Name (1 .. The_Name'Length) :=
>        POSIX.To_String (The_Name);
> end;
>

This solution assumes, that the Length of Output_File_Name.Name equals 
the length of The_Name. A POSIX_String may have a different length than 
the Ada-String, to which it is converted by POSIX.To_String, since 
individual characters might get expanded in two or more characters by 
this translation. (POSIX 1003.5b Chapt. 2.4.3.2).

The following should do better, assuming that Output_file_Name.Name is 
always big enough for The_File_Name :

declare

   The_File_Name: constant String:=
           Posix.To_String (Posix.Value
           (Posix_Process_Environment.Argument_List, 2));

begin
   
   Output_File_Name.Name(1..The_File_Name'Length)
              := The_File_Name;

end;



> >however, I kept getting an "invalid argument" exception when the code
> >was executed. I called the  Rational support team and found out that
> >the line suld read
> >
> >        Output_File_Name.Name
> >           (1 .. Posix.To_String
> >           (Posix.Value (Posix_Process_Environment.Argument_List, 2))'
> >                 Length) :=
> >           Posix.To_String (Posix.Value
> >           (Posix_Process_Environment.Argument_List, 2));
> 
> Rational gave you some bad advice.  Please don't write code like this:
> you're calling the function twice, and it's completely unreadable.  

This generally good advice is here not applicaple due to the reasons I 
gave above. The solution of RATIONAL also avoids the mentioned problems.


< further interesting remarks deleted >

> 
> --------------------------------------------------------------------
> Matthew Heaney
> Software Development Consultant
> <mailto:matthew_heaney@acm.org>
> (818) 985-1271

-- 
Dr. Peter E. Obermayer  Tel.  : xx49-(0)5931 805-469
                        Fax   : xx49-(0)5931 842-46
                        E-Mail: obermayer@cci.de

   _/_/_/ _/_/_/ _/_/_/ Competence Center Informatik GmbH
  _/     _/       _/    Lohberg 10
 _/     _/       _/     D-49716 Meppen
_/_/_/ _/_/_/ _/_/_/    http://www.cci.de/

Re: Using Posix with Apex

[Robert Dewar]

Peter said

<<This solution assumes, that the Length of Output_File_Name.Name equals
the length of The_Name. A POSIX_String may have a different length than
the Ada-String, to which it is converted by POSIX.To_String, since
individual characters might get expanded in two or more characters by
this translation. (POSIX 1003.5b Chapt. 2.4.3.2).>>

Sure, this is true from a formal point of view, but do you really know
any system on which this is actually true. I suspect that in practice
the code you refer to does not have a portability problem in practice.