Porting from Modula-2 to Ada

Porting from Modula-2 to Ada

[Manuel Collado]

We are porting some legacy Modula-2/C code to Ada. The code uses
low-level facilities from Modula-2 and C. We would like to port it to
clean Ada, without interfacing to C code. In addition we would like to
keep the old interface unchanged (if possible).

Al present we are looking for ways to manage memory and binary files as
arrays of bytes. The trouble is that Modula-2 allows the use of relaxed
ARRAY OF BYTE subprogram formal parameters, that are compatible with
actual parameters of any type. Example:

   PROCEDURE Xxx( raw: ARRAY OF BYTE );
      ...
   BEGIN
      FOR  k := 0 TO HIGH(raw) DO
         ... raw[k] ....
      END
   END Xxx;

   Num: INTEGER;
   ...
      Xxx( Num );
   ...


So far, my only porting scheme is to replace ARRAY OF BYTE parameters by
the pair (address, size), as follows:

   procedure Xxx (Raw_Address: System.Address; Raw_Size: Integer) ...

   Num: Integer;
   ...
      Xxx (Num'Address, Num'Size);
   ...

But this requires recoding every call to the procedure. Is there another
way to pass raw data without having to recode every call?

Thanks.
-- 
To reply by e-mail, please remove the extra dot
in the given address:  m.collado -> mcollado

Re: Porting from Modula-2 to Ada

[Bernd Specht]

Manuel Collado <m.collado@lml.ls.fi.upm.es> wrote in news:3DAFC542.152C0EE0
@lml.ls.fi.upm.es:

> We are porting some legacy Modula-2/C code to Ada. The code uses
> low-level facilities from Modula-2 and C. We would like to port it to
> clean Ada, without interfacing to C code. In addition we would like to
> keep the old interface unchanged (if possible).
> 
> Al present we are looking for ways to manage memory and binary files as
> arrays of bytes. The trouble is that Modula-2 allows the use of relaxed
> ARRAY OF BYTE subprogram formal parameters, that are compatible with
> actual parameters of any type. Example:
> 
>    PROCEDURE Xxx( raw: ARRAY OF BYTE );
>       ...
>    BEGIN
>       FOR  k := 0 TO HIGH(raw) DO
>          ... raw[k] ....
>       END
>    END Xxx;
> 
>    Num: INTEGER;
>    ...
>       Xxx( Num );
>    ...
> 
> 
> So far, my only porting scheme is to replace ARRAY OF BYTE parameters by
> the pair (address, size), as follows:
> 
>    procedure Xxx (Raw_Address: System.Address; Raw_Size: Integer) ...
> 
>    Num: Integer;
>    ...
>       Xxx (Num'Address, Num'Size);
>    ...
> 
> But this requires recoding every call to the procedure. Is there another
> way to pass raw data without having to recode every call?
> 
> Thanks.


Would it be an idea not to substitute the procedure by _one_ other procedure  
but with a set of overloaded procedures?

procedure Xxx (raw : Integer_Field) is ...
procedure Xxx (raw : Character_Field) is ...
procedure Xxx (raw : Float_Field) is ...

where 
type Integer_Field is array (Integer range <>) of Integer;
type Character_Field is array (Integer range <>) of Character;
type Float_Field is array (Integer range <>) of Float;

Re: Porting from Modula-2 to Ada

[Lutz Donnerhacke]

* Bernd Specht wrote:
> Would it be an idea not to substitute the procedure by _one_ other
> procedure but with a set of overloaded procedures?
> 
> procedure Xxx (raw : Integer_Field) is ...
> procedure Xxx (raw : Character_Field) is ...
> procedure Xxx (raw : Float_Field) is ...

And now use generics:

generic
  type T(<>) is limited private;
procedure Xxx (data : T);

procedure Xxx (data : T) is
  use System.Storage_Elements;
  raw : Storage_Array (Storage_Offset'First ..
        Storage_Offset'First + (data'Size + Storage_Unit - 1) / Storage_Unit);
  pragma Import (Ada, raw);
  for raw'Address use data'Address;
begin
  ...

Re: Porting from Modula-2 to Ada

[Jeffrey Creem]

I'd probably go with a generic that can be instantiated for each "thing" you
want to
write or use a ugly 'address and 'size based approach that does not require
generics.
Note that if you take the generic route it is a little more work but
somewhat cleaner.

When I have done this I tend to make the generic formal parameter be private
instead
of limited private. There are times when limited might be right but almost
any time
someone makes something limited, the in memory representation one would get
via the
type is somewhat bogus.

Also, it is worth checking in the generic body that the 'size of the type is
a multiple of
the 'size of the storage element (or whatever type you use to write to the
file)

"Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message
news:slrnaqvosa.nv.lutz@taranis.iks-jena.de...
> * Bernd Specht wrote:
> > Would it be an idea not to substitute the procedure by _one_ other
> > procedure but with a set of overloaded procedures?
> >
> > procedure Xxx (raw : Integer_Field) is ...
> > procedure Xxx (raw : Character_Field) is ...
> > procedure Xxx (raw : Float_Field) is ...
>
> And now use generics:
>
> generic
>   type T(<>) is limited private;
> procedure Xxx (data : T);
>
> procedure Xxx (data : T) is
>   use System.Storage_Elements;
>   raw : Storage_Array (Storage_Offset'First ..
>         Storage_Offset'First + (data'Size + Storage_Unit - 1) /
Storage_Unit);
>   pragma Import (Ada, raw);
>   for raw'Address use data'Address;
> begin
>   ...

Re: Porting from Modula-2 to Ada

[Lutz Donnerhacke]

* Jeffrey Creem wrote:
> "Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message
>> generic
>>   type T(<>) is limited private;
>> procedure Xxx (data : T);
>
> When I have done this I tend to make the generic formal parameter be
> private instead of limited private. There are times when limited might be
> right but almost any time someone makes something limited, the in memory
> representation one would get via the type is somewhat bogus.

generic types define the most restrictive assumptions can be made on every
real type: You can instantiate a limited generic type with an ordinary one.

When removing the limited constraint from the generic definiton, you allow
the generic program to copy variables of the generic type. So you are never
allowed to instantiate this construct with a limited type.

The other way around you are allowed to instantiate, because your real type
fullfills all requirements (and a lot more).

> Also, it is worth checking in the generic body that the 'size of the type
> is a multiple of the 'size of the storage element (or whatever type you
> use to write to the file)

You didn't read my code. :-/

Re: Porting from Modula-2 to Ada

[Jeffrey Creem]

"Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message
>
> generic types define the most restrictive assumptions can be made on every
> real type: You can instantiate a limited generic type with an ordinary
one.
>

That is exactly my point. I believe one should instantiate that generic with
"normal" types
and private types but never (or almost never) limited private types. One
could argue that the limited types should be allowed here "just in case" it
makes sense but these cases are much more rare than the cases where someone
would accidentally believe they can
use a limited type here when they can not.



> When removing the limited constraint from the generic definiton, you allow
> the generic program to copy variables of the generic type. So you are
never
> allowed to instantiate this construct with a limited type.

yup....When someone makes something limited, they remove assignment, they
remove "=" this usually means that one can not make reasonable assumptions
about the data in the type (could be a pointer to a linked list, address of
something, etc)..
Again, I don't argue that there would never be a case where it would make
sense
to use a limited type..But I have never seen one where it would.


>
> > Also, it is worth checking in the generic body that the 'size of the
type
> > is a multiple of the 'size of the storage element (or whatever type you
> > use to write to the file)
>
> You didn't read my code. :-/

Actually your code is doing reasonable things and avoiding common errors (by
writing out all storage elements associated with the data) but it is  not
doing what I was suggested.  Depending on what these procedures are used for
it can be useful to know that the "actual useful" data is not a multiple of
storage element sizes. This is less imporant on write commands like this but
can be a problem on the read equivilent when some unexpected piece of data
in a packed structure gets overwritten.

Re: Porting from Modula-2 to Ada

[Jeffrey Carter]

Lutz Donnerhacke wrote:
> generic
>   type T(<>) is limited private;
> procedure Xxx (data : T);
> 
> procedure Xxx (data : T) is
>   use System.Storage_Elements;
>   raw : Storage_Array (Storage_Offset'First ..
>         Storage_Offset'First + (data'Size + Storage_Unit - 1) / Storage_Unit);
>   pragma Import (Ada, raw);
>   for raw'Address use data'Address;
> begin
>   ...

System.Storage_Elements.Storage_Array is the best way to deal with 
untyped storage in Ada. This example is almost right; it seems to 
allocate one more Storage_Element than it should. A better way to 
achieve the same thing would be

Raw : Storage_Array (1 .. Data'Max_Size_In_Storage_Elements);

which avoids such off-by-one errors.

-- 
Jeff Carter
"Now look, Col. Batguano, if that really is your name."
Dr. Strangelove

Re: Porting from Modula-2 to Ada

[Jeffrey Carter]

Jeffrey Carter wrote:
> Raw : Storage_Array (1 .. Data'Max_Size_In_Storage_Elements);

Oops, that attribute is only defined for a subtype. That should be

T'Max_Size_In_Storage_Elements

-- 
Jeff Carter
"Now look, Col. Batguano, if that really is your name."
Dr. Strangelove

Re: Porting from Modula-2 to Ada

[Nicolas Cailín Paul Gloster]

Manuel Collado wrote:

"We are porting some legacy Modula-2/C code to Ada. The code uses
low-level facilities from Modula-2 and C. We would like to port it to
clean Ada[..]"

I noticed that in the book "Safety-critical computer systems" written
by Neil Storey and published in 1996 by Addison-Wesley with ISBN
020 1427 877 that were more compilers available for embedded targets,
at least according to Neil Storey or the author(s) of a study looking
at Pascal; C; Ada 83; Modula 2; assemblies; and about three other
languages he referred to, Modula-2 would be preferrable to use than Ada.
What are your views on this?
Thanks.

Re: Porting from Modula-2 to Ada

[Pat Rogers]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1795 bytes --]

"Nicolas Cail�n Paul Gloster" <Colin_Paul_Gloster@ACM.org> wrote in
message news:3DAFEE75.9BF44775@ACM.org...
> Manuel Collado wrote:
>
> "We are porting some legacy Modula-2/C code to Ada. The code uses
> low-level facilities from Modula-2 and C. We would like to port it
to
> clean Ada[..]"
>
> I noticed that in the book "Safety-critical computer systems"
written
> by Neil Storey and published in 1996 by Addison-Wesley with ISBN
> 020 1427 877 that were more compilers available for embedded
targets,
> at least according to Neil Storey or the author(s) of a study
looking
> at Pascal; C; Ada 83; Modula 2; assemblies; and about three other
> languages he referred to, Modula-2 would be preferrable to use than
Ada.
> What are your views on this?

That is not the conclusion I would draw from the text.  See for
example page 224:

"This factor [use of mature tools versus new ones] has implications
for the use of languages such as Modula-2.  From Table 9.2 it is clear
that a suitable subset of Modula-2 has many of the attractive
attributes associated with safety-critical software.  However, the
comparatively little use of this language within this field is a
distinct disadvantage.  Some safety-critical applications are using
Modula-2 ... and perhaps, in time, sufficient experience will be
gained to allow it to become a preferred language in this area."

I'm not aware of the "internationally recognized safe subset" for
Modula-2 that his tables (and the text on pg. 223) indicate exist.
Does anyone have a reference?

--
Patrick Rogers                       Consulting and Training in:
http://www.classwide.com       Real-Time/OO Languages
progers@classwide.com          Hard Deadline Schedulability Analysis
(281)648-3165                            Software Fault Tolerance

Re: Porting from Modula-2 to Ada

[Colin Paul Gloster]

In article <xzVr9.8$7m4.2475110@newssvr12.news.prodigy.com>, Pat Rogers wrote:
""Nicolas Cail�n Paul Gloster" <Colin_Paul_Gloster@ACM.org> wrote in
message news:3DAFEE75.9BF44775@ACM.org...
[..] 
 > I noticed that in the book "Safety-critical computer systems"
  written
 > by Neil Storey and published in 1996 by Addison-Wesley with ISBN
 > 020 1427 877 that were more compilers available for embedded
  targets,
 > at least according to Neil Storey or the author(s) of a study
  looking
 > at Pascal; C; Ada 83; Modula 2; assemblies; and about three other
 > languages he referred to, Modula-2 would be preferrable to use than
  Ada.
 > What are your views on this?
  
  That is not the conclusion I would draw from the text.  See for
  example page 224:
  
  "This factor [use of mature tools versus new ones] has implications
  for the use of languages such as Modula-2.  From Table 9.2 it is clear
  that a suitable subset of Modula-2 has many of the attractive
  attributes associated with safety-critical software.  However, the
  comparatively little use of this language within this field is a
  distinct disadvantage.  Some safety-critical applications are using
  Modula-2 ... and perhaps, in time, sufficient experience will be
  gained to allow it to become a preferred language in this area."
  
  I'm not aware of the "internationally recognized safe subset" for
  Modula-2 that his tables (and the text on pg. 223) indicate exist.
  Does anyone have a reference?" 

I will not have access to the book again for quite some time, but I thought that he or a study he referred to advocated the Modula-2 language for ideal world use, but that in real world use it was not used enough to reassure that its compilers are good enough, so that Ada was still recommended as the favorite due to tool quality (not language) concerns.

I do not remember a mention of a subset of Modula-2, but if he mentioned it, then it might be described in the study examining Pascal; C; Ada 83; Modula-2; and assemblies he referred to for one of his tables. 

Re: Porting from Modula-2 to Ada

[Dennis Lee Bieber]

Colin Paul Gloster fed this fish to the penguins on Thursday 24 October 
2002 07:51 am:

>   
>   That is not the conclusion I would draw from the text.  See for
>   example page 224:
>   
>   "This factor [use of mature tools versus new ones] has implications
>   for the use of languages such as Modula-2.  From Table 9.2 it is
>   clear that a suitable subset of Modula-2 has many of the attractive
>   attributes associated with safety-critical software.  However, the
>   comparatively little use of this language within this field is a
>   distinct disadvantage.  Some safety-critical applications are using
>   Modula-2 ... and perhaps, in time, sufficient experience will be
>   gained to allow it to become a preferred language in this area."
>   
>   I'm not aware of the "internationally recognized safe subset" for
>   Modula-2 that his tables (and the text on pg. 223) indicate exist.
>   Does anyone have a reference?"
>
        As an outsider, why does this sound like a Modula-2 variant of 
Ravenscar? <G>

--  
 > ============================================================== <
 >   wlfraed@ix.netcom.com  | Wulfraed  Dennis Lee Bieber  KD6MOG <
 >      wulfraed@dm.net     |       Bestiaria Support Staff       <
 > ============================================================== <
 >        Bestiaria Home Page: http://www.beastie.dm.net/         <
 >            Home Page: http://www.dm.net/~wulfraed/             <

Re: Porting from Modula-2 to Ada

[Colin Paul Gloster]

Colin Paul Gloster said on Thursday 24th October 2002:

"In article <xzVr9.8$7m4.2475110@newssvr12.news.prodigy.com>, Pat Rogers
wrote:
""Nicolas Cail�n Paul Gloster" <Colin_Paul_Gloster@ACM.org> wrote in
message news:3DAFEE75.9BF44775@ACM.org...
[..] 
 > I noticed that in the book "Safety-critical computer systems"
 written
 > by Neil Storey and published in 1996 by Addison-Wesley with ISBN
 > 020 1427 877 that were more compilers available for embedded
 targets,
 > at least according to Neil Storey or the author(s) of a study
 looking
 > at Pascal; C; Ada 83; Modula 2; assemblies; and about three other
 > languages he referred to, Modula-2 would be preferrable to use than
 Ada.
 > What are your views on this?
  
  That is not the conclusion I would draw from the text.  See for
  example page 224:
  
  "This factor [use of mature tools versus new ones] has implications
  for the use of languages such as Modula-2.  From Table 9.2 it is clear
  that a suitable subset of Modula-2 has many of the attractive
  attributes associated with safety-critical software.  However, the
  comparatively little use of this language within this field is a
  distinct disadvantage.  Some safety-critical applications are using
  Modula-2 ... and perhaps, in time, sufficient experience will be
  gained to allow it to become a preferred language in this area."
  
  I'm not aware of the "internationally recognized safe subset" for
  Modula-2 that his tables (and the text on pg. 223) indicate exist.
  Does anyone have a reference?" 

I will not have access to the book again for quite some time, but I
thought that he or a study he referred to advocated the Modula-2
language for ideal world use, but that in real world use it was not
used enough to reassure that its compilers are good enough, so that
Ada was still recommended as the favorite due to tool quality (not
language) concerns.

I do not remember a mention of a subset of Modula-2, but if he mentioned
it, then it might be described in the study examining Pascal; C; Ada 83;
Modula-2; and assemblies he referred to for one of his tables."

I have looked up the reference Neil Storey gave for Table 9.2. The paper 
is arguably lacking in detail and references. More quickly I have looked
back at Neil Storey's book, and I do not seem to see his expressing of
preferrence for Modula-2 instead of Ada 83, almost the reverse. Sorry.

From "The choice of computer languages for use in safety-critical
systems" by W.J. Cullyer, S.J. Goodenough [what a surname!] and
B.A. Wichmann on pages 51 to 58 of the IEE's March 1991 Volume 6 Number 2
issue of "Software Engineering Journal":

"[..]

[From page 51:] This paper makes it clear that 'unsafe' constructions
exist in all known assembly and high-order languages. [..] Hence, the
advice given favours the use of well defined subsets of the commonly
available languages.

[..]

[From page 52:] The resulting Tables should not be regarded as fixed. New
research and development of sub-languages policed by formal methods may
tend to enhance particular assessment as we move into the 1990s. This is
particularly true in rela-tion to Ada, which at the moment is immature for
this application area. All assessments given in the Tables should
therefore be treated as lower bounds, arising from the state of scientific
knowledge.

[..]

[From page 56:]

	Table 5		Modula-2 and a subset
	[..]

4.6	Modula-2

The Modula-2 language has a substantial fraction of the power of Ada but
is only of the same complexity as ISO Pascal. In some respects, it can
be regarded as a highly suitable language for safety-critical software,
being strongly typed and with modules for information hiding. ISO has
agreed to standardise the language, and this work is being undertaken [..]

* Data typing: although Modula-2 is a strongly typed language, there are
three loopholes to the type rules:
	* unsafe use of variant records, as in Pascal;
	* use of an explicit unsafe conversion function;
	* use of parameters of type WORD, which matches
	any parameter type.

[..]

* Safe subsets: a safe subset would exclude case state-ments with
uncovered cases and the three forms of type loopholes noted above.
[..]
[..] although a Modula-2 subset looks good, it may lack adequate
functionality for a specific application. [..From page 57:] Nevertheless,
it is felt that of the Standard languages, Modula-2 is inherently more
secure than the others listed here.

4.7	Ada

[..] the assessment given below of the characteristics of a sub-language
that could appear is of necessity, based on theoretical considerations
rather than experience.
[..]

* The languages that design teams should consider as candidates for use in
high-integrity systems are, according to the assessments in this paper,
and in descending order of merit

	* ISO Pascal [..]
	* an Ada sub-language[..]
	* a Modula-2 sub-language[..]

[..]

* If analysis of the hazards suggests that the risks are comparatively
low, the second group of languages that may be considered includes, in no
particular order

	* structured assembly languages;
	* DoD Ada, with minimal restrictions;
	* ISO Pascal, with minimal restrictions;
	* Modula-2, with minimal restrictions.

[..]

* Based on the assessments in this paper, the use of the following
languages is to be deprecated when safety is an issue:

	* [..]
	* C (despite its many adherents);
	* [..].

[..]

(C) Crown copyright 1991.

[..]"

Re: Porting from Modula-2 to Ada

[Robert I. Eachus]

> I do not remember a mention of a subset of Modula-2, but if he mentioned
> it, then it might be described in the study examining Pascal; C; Ada 83;
> Modula-2; and assemblies he referred to for one of his tables."

> From "The choice of computer languages for use in safety-critical
> systems" by W.J. Cullyer, S.J. Goodenough [what a surname!] and
> B.A. Wichmann on pages 51 to 58 of the IEE's March 1991 Volume 6 Number 2
> issue of "Software Engineering Journal"...

Brian Wichmann and John Goodenough were both heavily involved in the 
development of Ada 83 and Ada 95.  John also did a lot of work on Rate 
monotonic scheduling.  But that is John B. Goodenough, I don't know if 
S. J. is one of his children.

Brain has also done a lot of work on SPARK a safety-critical subset of 
Ada and what is known as the Ravescar Profile for tasking in embedded 
Ada systems.

I am not in a position to judge whether SPARK is the best subset 
language for safety-critical applications, but it is probably one of the 
most popular across all possible base languages.  (I tend to prefer a 
richer subset with machine language level review tools...)

Re: Porting from Modula-2 to Ada

[SteveD]

"Manuel Collado" <m.collado@lml.ls.fi.upm.es> wrote in message
news:3DAFC542.152C0EE0@lml.ls.fi.upm.es...
[snip]
> So far, my only porting scheme is to replace ARRAY OF BYTE parameters by
> the pair (address, size), as follows:
>
>    procedure Xxx (Raw_Address: System.Address; Raw_Size: Integer) ...
>
>    Num: Integer;
>    ...
>       Xxx (Num'Address, Num'Size);
>    ...
>
> But this requires recoding every call to the procedure. Is there another
> way to pass raw data without having to recode every call?

First: I have translated a significant amount of Pascal code to Ada.  From
this experience I would recommend producing a tool to do most of the
translation.

Making the mapping you just described should be fairly easy for such a tool.

The only alternate for this implementation that comes to mind is to create
arrays of bytes that alias each structure and passing the alias to Xxx.  For
example:

with Interfaces; use interfaces;
with Ada.Text_Io;

procedure testconv is

  type byte_array is array( Natural range <> ) of Unsigned_8;

  type data_rec is
    record
      field_1 : Integer;
      field_2 : String( 1 .. 8 );
    end record;

  procedure Xxx( raw : in out byte_array ) is
  begin
    raw( 0 ) := 2;
    raw( 1 ) := 0;
    raw( 2 ) := 0;
    raw( 3 ) := 0;
  end Xxx;

  data : data_rec;
  data_alias : byte_array( 0 .. data_rec'size / 8 - 1 );
  for data_alias'address use data'address;
begin
  data.field_1 := 1;
  Ada.Text_Io.Put_Line( "field_1 before: " & Integer'IMAGE(
data.field_1 ) );
  Xxx( data_alias );
  Ada.Text_Io.Put_Line( "field_1 after: " & Integer'IMAGE( data.field_1 ) );
end testconv;

This makes the code look more like the original source, but requires an
additional declaration for each parameter passed to Xxx and still requires
the calls to be modified.

Sorry I don't have a better answer,

SteveD
>
> Thanks.
> --
> To reply by e-mail, please remove the extra dot
> in the given address:  m.collado -> mcollado

Re: Porting from Modula-2 to Ada

[Manuel Collado]

SteveD wrote:
> 
> "Manuel Collado" <m.collado@lml.ls.fi.upm.es> wrote in message
> news:3DAFC542.152C0EE0@lml.ls.fi.upm.es...
> [snip]
> First: I have translated a significant amount of Pascal code to Ada.  From
> this experience I would recommend producing a tool to do most of the
> translation.

I've already done that.

> 
> Making the mapping you just described should be fairly easy for such a tool.
> 
> The only alternate for this implementation that comes to mind is to create
> arrays of bytes that alias each structure and passing the alias to Xxx.  For
> example:
> [snip]

Thanks for the suggestion.
-- 
To reply by e-mail, please remove the extra dot
in the given address:  m.collado -> mcollado

Re: Porting from Modula-2 to Ada

[Manuel Collado]

Manuel Collado wrote:
> [snip]
> Al present we are looking for ways to manage memory and binary files as
> arrays of bytes. The trouble is that Modula-2 allows the use of relaxed
> ARRAY OF BYTE subprogram formal parameters, that are compatible with
> actual parameters of any type. Example:
> [snip]
> So far, my only porting scheme is to replace ARRAY OF BYTE parameters by
> the pair (address, size), as follows:
> 
>    procedure Xxx (Raw_Address: System.Address; Raw_Size: Integer) ...
> 
>    Num: Integer;
>    ...
>       Xxx (Num'Address, Num'Size);
>    ...

Thanks to all who respond. After considering the suggestions, I think
I'll keep the initial proposed scheme. It doesn't follow the Ada
programming style, but is straightforward. And in some cases it can be
reduced in fact to passing the address, because the size is already an
explicit parameter in some procedures.

Thanks again,
-- 
To reply by e-mail, please remove the extra dot
in the given address:  m.collado -> mcollado

Re: Porting from Modula-2 to Ada

[Jeffrey Carter]

Manuel Collado wrote:
> Thanks to all who respond. After considering the suggestions, I think
> I'll keep the initial proposed scheme. It doesn't follow the Ada
> programming style, but is straightforward. And in some cases it can be
> reduced in fact to passing the address, because the size is already an
> explicit parameter in some procedures.

This is the way C does it. Decades of experience with C have shown that 
this is the source of many subtle errors.

Enjoy your long nights with the debugger.

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

Re: Porting from Modula-2 to Ada

[Manuel Collado]

Jeffrey Carter wrote:
> 
> Manuel Collado wrote:
> > Thanks to all who respond. After considering the suggestions, I think
> > I'll keep the initial proposed scheme. It doesn't follow the Ada
> > programming style, but is straightforward. And in some cases it can be
> > reduced in fact to passing the address, because the size is already an
> > explicit parameter in some procedures.
> 
> This is the way C does it. Decades of experience with C have shown that
> this is the source of many subtle errors.

I'm certainly aware of that. But I'm not writing new code, but simply
trying to precisely reproduce the behaviour of legacy, hopefully
debugged code.

> 
> Enjoy your long nights with the debugger.

I hardly use debuggers. In case of errors, I insert assertions and print
sentences to selectively trace program's execution. And I do extensive
unit testing.
-- 
To reply by e-mail, please remove the extra dot
in the given address:  m.collado -> mcollado