Commercial C To Ada 95 compiler

Commercial C To Ada 95 compiler

[Henrik Quintel]

Dear all,
does someone knows an ANSI C to Ada 95 compiler (commercial)?
The compiler has to translate C header and C body files.

Would be nice if you could send me a few addresses.

Thanks in advance.

Greetings Henrik


-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Re: Commercial C To Ada 95 compiler

[Ingo Marks]

Henrik Quintel wrote:

> does someone knows an ANSI C to Ada 95 compiler (commercial)?
> The compiler has to translate C header and C body files.

Wouldn't it be easier to link compiled C code into Ada 95?

Example:

C:
   int c_test (char *s) { return strlen(s); }

Ada:
   with Interfaces.C;                 use Interfaces.C;
   with Interfaces.C.Strings;         use Interfaces.C.Strings;

   function test (s : Chars_Ptr) return Integer;
   pragma Import(C,test,"c_test");

Regards

Re: Commercial C To Ada 95 compiler

[Henrik Quintel]

Hi,
> Wouldn't it be easier to link compiled C code into Ada 95?
No, thanks that wouldn't help. I want to know how such a compiler works
and if such a
compiler can produce acceptable Ada Code.

Greetings Henrik


-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Re: Commercial C To Ada 95 compiler

[Frank J. Lhota]

> No, thanks that wouldn't help. I want to know how such a compiler works
> and if such a
> compiler can produce acceptable Ada Code.

I've had some experience with automatic conversion. Yes, a well-written
converter can get you "acceptable" code in that the generated code is 90%
likely to compile and reproduce the expected behavior. Other than that, the
code resulting from automatic conversions is usually atrocious.
Automatically converted code is frequently used as a starting point, with
some significant clean up effort later.

Re: Commercial C To Ada 95 compiler

[Preben Randhol]

On Tue, 04 Jun 2002 14:11:03 GMT, Frank J. Lhota wrote:
> I've had some experience with automatic conversion. Yes, a
> well-written converter can get you "acceptable" code in that the
> generated code is 90% likely to compile and reproduce the expected
> behavior.

Does the bugs get reproduced too ;-)

Preben

Re: Commercial C To Ada 95 compiler

[Frank J. Lhota]

> Does the bugs get reproduced too ;-)

Oh absolutely! Not to mention adding new ones.

Re: Commercial C To Ada 95 compiler

[Florian Weimer]

"Henrik Quintel" <henrik.quintel@gmx.de> writes:

> does someone knows an ANSI C to Ada 95 compiler (commercial)?
> The compiler has to translate C header and C body files.

If you are still stuck with the same program, such a tool won't help
you at all.

Re: Commercial C To Ada 95 compiler

[Henrik Quintel]

Hi Florian,
> If you are still stuck with the same program, such a tool won't help
> you at all.
No, I don't have the same program nor the same problem. :-))
I have stopped porting the C program like you and Lutz suggested.
At the moment I write a complete new application from the beginning.
In some cases I am simply interested how such a compiler works.

Greetings Henrik






-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Re: Commercial C To Ada 95 compiler

[Lutz Donnerhacke]

* Henrik Quintel wrote:
>I have stopped porting the C program like you and Lutz suggested.

Fine.

>At the moment I write a complete new application from the beginning.

Unfortunly you still trying to write your C idioms in Ada without
understanding the minimal Ada syntax. This will fail.

>In some cases I am simply interested how such a compiler works.

No. You are interested in something strange, but definitly not in generating
Ada code.

Re: Commercial C To Ada 95 compiler

[Richard Riehle]

Henrik Quintel wrote:

> Dear all,
> does someone knows an ANSI C to Ada 95 compiler (commercial)?
> The compiler has to translate C header and C body files.

This idea, if you will forgive my being blunt, makes absolutely
no sense at all.    Ada is built on a design model more sophisticated
than C, and any attempt to promote C syntax to the Ada structural
model is likely to produce the kind of code that make Ada look
bad.    We have seen enough of this absurdity in the Fortran to
Ada translators and Jovial to Ada translators.

The problem is this: how do you promote low-level syntactic
constructs, with none of the elegance of Ada's type model, and
no hint of scope and visibility rules, to good Ada code.  How do
you convert a program written in a language where the default for
every construct is unsafe to a program written in a language where
the default for every construct is safe. It is simply not worth the
effort to try.

Richard Riehle

Re: Commercial C To Ada 95 compiler

[SteveD]

"Richard Riehle" <richard@adaworks.com> wrote in message
news:3D002D11.CC706952@adaworks.com...
> Henrik Quintel wrote:
>
> > Dear all,
> > does someone knows an ANSI C to Ada 95 compiler (commercial)?
> > The compiler has to translate C header and C body files.
>
> This idea, if you will forgive my being blunt, makes absolutely
> no sense at all....

It might make sense if you are planning to migrate a large C application to
Ada in a step-wise fashion.  Getting the application into Ada first and then
re-designing and coding subsets of the system incrementally allows such a
migration that includes having a running system at each step of the process.

I have experienced this benefit in moving a few moderate sized Pascal
programs to Ada.  Although I admit that the move from Pascal to Ada is much
less of a step than from C to Ada.

SteveD

Re: Commercial C To Ada 95 compiler

[Marin David Condic]

Lots of times, we're confronted with problems for which there are only
butt-ugly solutions:

"I want to use this Ada compiler to develop all the new chunks of code for
this system & I don't want to be maintaining stuff in multiple languages, so
I've got to find a quick way of getting everything changed into Ada. If it
costs too much to convert, I'll just have to abandon the effort..."

I agree that a C-to-Ada translator is only going to produce horrendous code
and it is definitely not the way to go for things you want to keep around
for a while. Sometimes ugly solutions still have a time * place, though.
Sometimes its an attractive "Siren Song" to want to auto-translate & just
move forward. It just has to be done with the caveat that nothing produced
that way is going to be any good no matter what you do, so you don't want to
have to try to ever upgrade any auto-translated code. You'd just be
polishing a turd.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"SteveD" <nospam_steved94@attbi.com> wrote in message
news:GW1M8.123856$352.6037@sccrnsc02...
>
> It might make sense if you are planning to migrate a large C application
to
> Ada in a step-wise fashion.  Getting the application into Ada first and
then
> re-designing and coding subsets of the system incrementally allows such a
> migration that includes having a running system at each step of the
process.
>

Re: Commercial C To Ada 95 compiler

[Stephen Leake]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> Lots of times, we're confronted with problems for which there are only
> butt-ugly solutions:
> 
> "I want to use this Ada compiler to develop all the new chunks of code for
> this system & I don't want to be maintaining stuff in multiple languages, so
> I've got to find a quick way of getting everything changed into Ada. If it
> costs too much to convert, I'll just have to abandon the effort..."

I understand this is your example, but I'd like to point out that with
modern compilers, maintaining code in multiple languages is not as
hard as many people seem to think.

Gnu C and Gnu Ada link together, and work very well together. The same
is true of Greenhills Ada and Greenhills C (although I have not
personally used that combination). 

So keeping parts of the original C while converting parts to Ada
should be given serious consideration.

-- 
-- Stephe

Re: Commercial C To Ada 95 compiler

[Marin David Condic]

Fair enough, but there is *way* more that goes into the overall costs on a
project besides the compiler. Maintaining two languages on the same project
means things like maintaining expertise in two languages instead of one. It
often means maintenance of different toolsets - especially home-grown
tools - to deal with both languages. It can mean increased maintenance
headaches because of having to track down bugs in two compilers instead of
one. (Even if its the same compiler, its really got two different parts, so
you multiply your risk of errors) It can mean increased costs in
configuration management. Etc., etc. etc...

Some projects are small enough and simple enough that glomming onto some
chunk of useful C code and utilizing Gnat to compile both the C and Ada
might not present that big of a problem. However, for projects that might be
long lived, large, complex, etc., you really would be inviting increased
costs and risks by going to multiple languages. I certainly wouldn't choose
to do it that way if I had a clean slate (would anyone?) so any attempt to
do so is, IMHO, a compromise that needs to be justified carefully.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Stephen Leake" <stephen_leake@acm.org> wrote in message
news:wkk7p8qgbb.fsf@acm.org...
>
> I understand this is your example, but I'd like to point out that with
> modern compilers, maintaining code in multiple languages is not as
> hard as many people seem to think.
>
> Gnu C and Gnu Ada link together, and work very well together. The same
> is true of Greenhills Ada and Greenhills C (although I have not
> personally used that combination).
>
> So keeping parts of the original C while converting parts to Ada
> should be given serious consideration.
>

Re: Commercial C To Ada 95 compiler

[SteveD]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:ae28st$aqa$1@nh.pace.co.uk...
> Fair enough, but there is *way* more that goes into the overall costs on a
> project besides the compiler. Maintaining two languages on the same
project
> means things like maintaining expertise in two languages instead of one.
It
> often means maintenance of different toolsets - especially home-grown
> tools - to deal with both languages. It can mean increased maintenance
> headaches because of having to track down bugs in two compilers instead of
> one. (Even if its the same compiler, its really got two different parts,
so
> you multiply your risk of errors) It can mean increased costs in
> configuration management. Etc., etc. etc...

Dang.  If I have to use this logic, I guess all my future projects will have
to be in C.  While I don't normally add C code to a project, most of my
projects do involve interfacing to C and require knowledge of C to create
the interfaces.

Just when I thought using Ada with existing C code was a good choice.
Thanks for setting me straight ;-)

> Some projects are small enough and simple enough that glomming onto some
> chunk of useful C code and utilizing Gnat to compile both the C and Ada
> might not present that big of a problem. However, for projects that might
be
> long lived, large, complex, etc., you really would be inviting increased
> costs and risks by going to multiple languages. I certainly wouldn't
choose
> to do it that way if I had a clean slate (would anyone?) so any attempt to
> do so is, IMHO, a compromise that needs to be justified carefully.

Your projects must involve deeper pockets than ours.  We usually try to
reuse as much code as possible... regardless of the language and rarely have
the opportunity to start with a "clean slate".

SteveD

> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
>

Re: Commercial C To Ada 95 compiler

[Marin David Condic]

Please read carefully what I'm saying. If one had a "clean slate" would one
deliberately choose to develop a whole new project in multiple languages?
Probably only rarely where you had some really unusual, specialized needs.
So by that point, any attempt to mix languages is a *compromise* with the
ideal situation and should be considered carefully.

Sure, if I have a PC-based, interactive user app where software failures
aren't life-or-death and the app will probably be toast in a year to
eighteen months when the next product cycle starts up and I've got some
large body of C code I can leverage, I might choose to mix Ada and C with
the Gnat compiler. If I've got an embedded military project that is going to
be around for 30 years and has life-or-death consequences, I'm going to be
much more eager to pick and choose my tools up front because the costs over
the life of the project are far more important. From that perspective,
re-engineering a large chunk of C code into Ada and then having to deal with
only *one* language is probably the wise choice because the up-front cost is
pretty small in comparison to the recurring costs of maintaining two
languages. Which gets us back to my original point - for large, long lived,
complex projects, those overall costs have to be looked at and if you *do*
want to compromise and mix languages, you'd best exercise all due diligence
to be sure it is the right decision.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"SteveD" <nospam_steved94@attbi.com> wrote in message
news:jomN8.159965$cQ3.4608@sccrnsc01...
> "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote > >
Some projects are small enough and simple enough that glomming onto some
> > chunk of useful C code and utilizing Gnat to compile both the C and Ada
> > might not present that big of a problem. However, for projects that
might
> be
> > long lived, large, complex, etc., you really would be inviting increased
> > costs and risks by going to multiple languages. I certainly wouldn't
> choose
> > to do it that way if I had a clean slate (would anyone?) so any attempt
to
> > do so is, IMHO, a compromise that needs to be justified carefully.
>
> Your projects must involve deeper pockets than ours.  We usually try to
> reuse as much code as possible... regardless of the language and rarely
have
> the opportunity to start with a "clean slate".
>

Re: Commercial C To Ada 95 compiler

[Larry Kilgallen]

In article <ae4u52$7p2$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
> Please read carefully what I'm saying. If one had a "clean slate" would one
> deliberately choose to develop a whole new project in multiple languages?
> Probably only rarely where you had some really unusual, specialized needs.

In my experience, the pay rate is higher for tending to unusual specialized
needs :-)

Re: Commercial C To Ada 95 compiler

[Marin David Condic]

Sure, but I guess that becomes A Good Thing or A Bad Thing depending on
where you sit. Here in Cubeville, its A Good Thing. But when the company
stock is in my 401-k portfolio, it becomes A Bad Thing. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:DJDxWyYsAt9N@eisner.encompasserve.org...
>
> In my experience, the pay rate is higher for tending to unusual
specialized
> needs :-)

Re: Commercial C To Ada 95 compiler

[Larry Kilgallen]

In article <3D002D11.CC706952@adaworks.com>, Richard Riehle <richard@adaworks.com> writes:
> Henrik Quintel wrote:
> 
>> Dear all,
>> does someone knows an ANSI C to Ada 95 compiler (commercial)?
>> The compiler has to translate C header and C body files.
> 
> This idea, if you will forgive my being blunt, makes absolutely
> no sense at all.

It might make sense in a mythical future when product liability laws
discouraged vendors from selling C compilers :-)

Re: Commercial C To Ada 95 compiler

[Ted Dennison]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<ppIBFZ2aI1Vx@eisner.encompasserve.org>...
> In article <3D002D11.CC706952@adaworks.com>, Richard Riehle <richard@adaworks.com> writes:
> > Henrik Quintel wrote:
> > 
> >> does someone knows an ANSI C to Ada 95 compiler (commercial)?
> >> The compiler has to translate C header and C body files.
> > 
> > This idea, if you will forgive my being blunt, makes absolutely
> > no sense at all.
> 
> It might make sense in a mythical future when product liability laws
> discouraged vendors from selling C compilers :-)

:-)

The only problem with that is that the translation would have to be
just as unsafe for it to be a valid translation of C. Think lots of
integers, floats, unchecked_conversions, and "pragma Suppress
(All_Checks);"s. Absolutely no good would come from such a
translation, unless you happened to need to use a platform that has an
Ada compiler and no C compiler. You could try to refactor it
afterwards, I suppose. But it would probably be easier to do so
straight from the original C.

On the other hand, it might make sense if we added to your universe: 

software developers who believe touching raw C code leaves them
ritually unclean.

Running the C through a tool has got to be cheaper than hiring some
software monk like Grady Booch to come in and perform some kind of
cleansing ceremony on your whole software development environment.
Plus, there's that 7 day waiting period, not to mention that getting
computers to run again after being immersed in mikvah is a bitch.

:-)

-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Commercial C To Ada 95 compiler

[Wes Groleau]

> > >> does someone knows an ANSI C to Ada 95 compiler (commercial)?
> > >> The compiler has to translate C header and C body files.
> > >
> > > This idea, if you will forgive my being blunt, makes absolutely
> > > no sense at all.
> (All_Checks);"s. Absolutely no good would come from such a
> translation, unless you happened to need to use a platform that has an
> Ada compiler and no C compiler. You could try to refactor it
> afterwards, I suppose. But it would probably be easier to do so
> straight from the original C.

Suppose the team is experienced in Ada
but not in C.  They are not accustomed
to the kind of disasters C creates and
may not see them in the code.

A direct translation to Ada will reveal
some bugs at compile time.  And the developers
are looking at a language they can read
when they fix those bugs.

Other bugs will appear as the developers
improve things in the process of working
on the code.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Commercial C To Ada 95 compiler

[SteveD]

"Wes Groleau" <wesgroleau@despammed.com> wrote in message
news:3D0116F3.7254E263@despammed.com...
>
[snip]
> A direct translation to Ada will reveal
> some bugs at compile time.  And the developers
> are looking at a language they can read
> when they fix those bugs.

I disagree.  A direct translation to Ada should not reveal any bugs at
compile time.  In fact it should replicate memory leaks and errant pointers.
If it doesn't do so, it is not a direct translation.

If C coding errors are translated directly to Ada, the error should be
reproduced.  However looking at the code that is generated, the error in the
source may be obvious if reviewed by a human reader.

For example, the C code:

  for( i = 0 ; i < 10 ; i++ );
  {
    printf( "%d\n", i );
  }

Should be directly translated to:

  i : Integer;

  i := 0;
  while i < 10 loop
    i := i + 1;
  end loop;
  Ada.Integer.Text_Io.Put( i );
  Ada.Text_Io.New_Line;

bug and all.  To do anything else would not be a direct translation.

Once the code has been translated these sort of problems are easy to spot
with code walk-thrus.  A translator also may be set up do report potential
problem areas.

In my experince with Pascal to Ada translation, no bugs showed up as a
result of direct translation.  Bugs only showed up because of incomplete
translation and in cases where I refined the code by hand to permit the
compiler to make more checks.

SteveD

> Other bugs will appear as the developers
> improve things in the process of working
> on the code.
>
> --
> Wes Groleau
> http://freepages.rootsweb.com/~wgroleau

Re: Commercial C To Ada 95 compiler

[Jim Rogers]

SteveD wrote:

> "Wes Groleau" <wesgroleau@despammed.com> wrote in message
> news:3D0116F3.7254E263@despammed.com...
> 
> [snip]
> 
>>A direct translation to Ada will reveal
>>some bugs at compile time.  And the developers
>>are looking at a language they can read
>>when they fix those bugs.
>>
> 
> I disagree.  A direct translation to Ada should not reveal any bugs at
> compile time.  In fact it should replicate memory leaks and errant pointers.
> If it doesn't do so, it is not a direct translation.


You may be very wrong here. Ada compilers tend to identify many more
errors at compile time than C compilers. This means that code
which compiles without error on a C compiler, when directly translated
to Ada, will may not compile.

One simple example is indexing past the end of an array.
C compilers simply will not catch this problem. Ada compilers will.

On the whole, direct translation may not be possible. C uses
implicit conversion between integer and floating point types.
Ada provides no such implicit conversion. You will at least need
to make all implicit C conversions explicit in Ada.

Another incompatibility is trying to reference the control
variable in a "for" loop outside the scope of the "for" loop.
This is impossible in Ada and not uncommon in C. The C compiler
will allow this. The Ada compiler will not.

Your example of "direct" translation of a C for loop with a null
body to an Ada while loop is a good approximation of the problem,
but not, IMHO, a direct translation. A direct translation would have
the C code also using a while loop. Ada for loops simply cannot
demonstrate this error. Any attempt to do so will create a
compiler error.

Jim Rogers

Re: Commercial C To Ada 95 compiler

[Darren New]

Jim Rogers wrote:
> One simple example is indexing past the end of an array.
> C compilers simply will not catch this problem. Ada compilers will.

True, assuming it's sufficiently obvious. I would think there might be a lot
of weird C-ish stuff that Ada would have trouble doing, like malloc'ing an
array of floats and then casting it to a (char *) and filling it in with
some pattern.
 
> On the whole, direct translation may not be possible. C uses
> implicit conversion between integer and floating point types.
> Ada provides no such implicit conversion. You will at least need
> to make all implicit C conversions explicit in Ada.

Well, I would imagine that the translator could do this, yes?

C:
  f = i;
Ada
  f := Float (i);



> Another incompatibility is trying to reference the control
> variable in a "for" loop outside the scope of the "for" loop.
> This is impossible in Ada and not uncommon in C. The C compiler
> will allow this. The Ada compiler will not.

Well, if your translator translates C for loops that have references to the
index variable outside the for loop into Ada for loops, it'll be a problem.
They'd have to translate it to the corresponding while loop.
 
I guess if you're going to be strict enough about the word "direct
translation" to mean that a C for loop can't translate to an Ada while loop,
what you say would be true. I don't think that's what's generally meant by
"direct translation".

I think there would be more problematic constructs, tho, like static
variables (inside and/or outside of functions), pointers cast to different
types, and so on. 

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: Commercial C To Ada 95 compiler

[SteveD]

"Darren New" <dnew@san.rr.com> wrote in message
news:3D0184BD.69723B2D@san.rr.com...
[snip]
>
> I think there would be more problematic constructs, tho, like static
> variables (inside and/or outside of functions), pointers cast to different
> types, and so on.

Not really that difficult.  Static variables can be handled by nesting
packages... it isn't pretty, but you can get there.  As for pointer casts,
you'd be amazed at the stuff you can do with unchecked conversion and
Interfaces.C.

You'd wind up with really crappy Ada code, just like the original ...
Ooops! Don't want to start a language war.

SteveD

> --
> Darren New
> San Diego, CA, USA (PST). Cryptokeys on demand.
> ** http://home.san.rr.com/dnew/DNResume.html **
> ** http://images.fbrtech.com/dnew/ **
>
>      My brain needs a "back" button so I can
>          remember where I left my coffee mug.

Re: Commercial C To Ada 95 compiler

[Robert Dewar]

"SteveD" <nospam_steved94@attbi.com> wrote in message news:<s2gM8.137622$ux5.183790@rwcrnsc51.ops.asp.att.net>...
> "Darren New" <dnew@san.rr.com> wrote in message
> news:3D0184BD.69723B2D@san.rr.com...
> [snip]
> >
> > I think there would be more problematic constructs, tho, like static
> > variables (inside and/or outside of functions), pointers cast to different
> > types, and so on.
> 
> Not really that difficult.  Static variables can be handled by nesting
> packages... it isn't pretty, but you can get there. 

This is wrong, you don't need nested packages here. The translation of
static variables is straightforward. Part of the trouble with this thread is
that it is about solutions, not problems. We really don't know why anyone
would want to translate C to Ada, and since this does not make much sense
as a solution to any problem, there is too much guessing going on as to the
desired nature of the solution :-)

Re: Commercial C To Ada 95 compiler

[Wes Groleau]

> > Ada provides no such implicit conversion. You will at least need
> > to make all implicit C conversions explicit in Ada.
> 
> Well, I would imagine that the translator could do this, yes?

Yes, but the translator can't tell the difference
between an implicit conversion that the programmer
intentionally took advantage of and an implicit
conversion that comes from a programmer's screw-up.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Commercial C To Ada 95 compiler

[Darren New]

Wes Groleau wrote:
> Yes, but the translator can't tell the difference
> between an implicit conversion that the programmer
> intentionally took advantage of and an implicit
> conversion that comes from a programmer's screw-up.

True, but... so?  If the C code is buggy, I don't think you'll find too many
automated ways of removing the bugs and making it Do What I Mean.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: Commercial C To Ada 95 compiler

[Wes Groleau]

> True, but... so?  If the C code is buggy, I don't think you'll find too many
> automated ways of removing the bugs and making it Do What I Mean.

You're changing the subject on me again.  What I said way back when
is that translating C into Ada will reveal new bugs at compile time.

And that it would also reveal bugs in other ways.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Commercial C To Ada 95 compiler

[Darren New]

Wes Groleau wrote:
> 
> > True, but... so?  If the C code is buggy, I don't think you'll find too many
> > automated ways of removing the bugs and making it Do What I Mean.
> 
> You're changing the subject on me again.  What I said way back when
> is that translating C into Ada will reveal new bugs at compile time.

Well, if in C I go
  float f; int i; ... f = i;
and I meant that, then it's not a bug. I guess it would "reveal a bug", but
it would also give the same diagnostic for things that aren't bugs, so I'd
think that's less useful.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: Commercial C To Ada 95 compiler

[SteveD]

"Jim Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
news:3D018106.6080004@worldnet.att.net...
> SteveD wrote:
>
[snip]
>
> You may be very wrong here. Ada compilers tend to identify many more
> errors at compile time than C compilers. This means that code
> which compiles without error on a C compiler, when directly translated
> to Ada, will may not compile.
>
> One simple example is indexing past the end of an array.
> C compilers simply will not catch this problem. Ada compilers will.

In fact this is not an error in C.  Programs can (and do) intentionally
index past the end of arrays.  I have seen C code that allocates memory
dynamically and uses array access to reference the memory.  It is nearly
impossible to distinguish these cases.

> On the whole, direct translation may not be possible. C uses
> implicit conversion between integer and floating point types.
> Ada provides no such implicit conversion. You will at least need
> to make all implicit C conversions explicit in Ada.

I disagree, direct translation is possible.  The order of conversions in C
is explicitly defined.  The translation would have to turn these implicit
conversions into explicit conversions.  Again, a review of the translated
could may reveal surprises.

> Another incompatibility is trying to reference the control
> variable in a "for" loop outside the scope of the "for" loop.
> This is impossible in Ada and not uncommon in C. The C compiler
> will allow this. The Ada compiler will not.

In this case a direct translation should translate the for loop to a while
construct.  For a direct translation the generated code must behave exactly
the same as the original code.

> Your example of "direct" translation of a C for loop with a null
> body to an Ada while loop is a good approximation of the problem,
> but not, IMHO, a direct translation. A direct translation would have
> the C code also using a while loop. Ada for loops simply cannot
> demonstrate this error. Any attempt to do so will create a
> compiler error.

You miss my point.  The translation is from C to Ada.  I can't change the C
code, I'm translating it.

In my example the C code had an error, the fact that the for loop was empty
was missed in the original code.  This shows up readily in the Ada code.

BTW:  I'm not saying I would want a C to Ada translator.  I'm just saying
that if someone said they wanted one, I can understand their reasoning.

SteveD

>
> Jim Rogers
>

Re: Commercial C To Ada 95 compiler

[Robert Dewar]

> In fact this is not an error in C.  Programs can (and do) intentionally
> index past the end of arrays.  I have seen C code that allocates memory
> dynamically and uses array access to reference the memory.  It is nearly
> impossible to distinguish these cases.

This is an erroneous C program. Definitely it will be hard to translate
programs that are erroneous and have undefined semantics. Or from a more
formal point of view, ANY translation of such a program is correct! Many
C programmers think C has general address arithmetic. It does not. If you
want general address arithmetic, you must use some other language, e.g.
Ada, which does have this feature. 
 
> > Another incompatibility is trying to reference the control
> > variable in a "for" loop outside the scope of the "for" loop.
> > This is impossible in Ada and not uncommon in C. The C compiler
> > will allow this. The Ada compiler will not.
> 
> In this case a direct translation should translate the for loop to a while
> construct.  For a direct translation the generated code must behave exactly
> the same as the original code.

A better response is that there is no "for" loop in C. The thing that looks
like a for loop in C is (and is defined to be) simply a macro form for a while
loop. Most obviously it must be translated into a while loop.

In general the point is that a translator that does this kind of translation
must have all the intelligence and semantic knowledge of a C compiler (and
must be written by someone who knows the formal semantics and typical usage
of both languages comprehensively).

Re: Commercial C To Ada 95 compiler

[SteveD]

"Robert Dewar" <dewar@gnat.com> wrote in message
news:5ee5b646.0206080411.7da58d12@posting.google.com...
[snip]
>
> In general the point is that a translator that does this kind of
translation
> must have all the intelligence and semantic knowledge of a C compiler (and
> must be written by someone who knows the formal semantics and typical
usage
> of both languages comprehensively).

I think you would agree that a C to Ada translator is technically feasable.
Whether or not anyone would want such a beast is another matter.  It is
unlikely that anyone would fund such an effort but... stranger things have
happened.

SteveD

Re: Commercial C To Ada 95 compiler

[Marin David Condic]

Its just difficult to imagine a situation in which a C-to-Ada translator is
a *good* solution to any sort of reasonably long-term problem. As a
quick-and-dirty fix to a short term problem, maybe, but not if you have to
live with it for very long. Hence, not a lot of incentive to fund the
production of such a tool.

In some development environments I've been in, the management attitude
towards old code goes something like this: If the original developer of some
body of code quits, I declare that a "Legacy System" and no further
development/enhancement is done on it. The reason is that it is just too
expensive to get someone else up to speed on it and I'm better off starting
a "Version 2" development with whatever new requirements need to be met.
(The new system is cheaper than the old system plus new requirements.)

If I were confronted with some legacy C code someone wanted to leverage into
an Ada project through conversion, that would be my gut reaction - probably
it is cheaper to build it over again with *new* requirements that reflect
everything we want than it would be to translate the old stuff and keep
hammering on it to try to get whatever additional capabilities are needed.
But occasionally, there may be oddball cases. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"SteveD" <nospam_steved94@attbi.com> wrote in message
news:kisM8.144693$ux5.185603@rwcrnsc51.ops.asp.att.net...
>
> I think you would agree that a C to Ada translator is technically
feasable.
> Whether or not anyone would want such a beast is another matter.  It is
> unlikely that anyone would fund such an effort but... stranger things have
> happened.
>

Re: Commercial C To Ada 95 compiler

[Wes Groleau]

> If I were confronted with some legacy C code someone wanted to leverage into
> an Ada project through conversion, that would be my gut reaction - probably
> it is cheaper to build it over again with *new* requirements that reflect
> everything we want than it would be to translate the old stuff and keep

Indeed.  Updating code without changing languages
sometimes takes a lot of change.

The fact that it was written in C makes a high probability
that it will REALLY take a lot of work--unless you personally
know that a top-quality process was followed to create it.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Commercial C To Ada 95 compiler

[Marin David Condic]

Well, there's good C code and bad C code, so one has to take it on a case by
case basis. The thing of it is, if one is confronted with a body of code
large enough to warrant some kind of auto-translation, one has to ask "why?"
and be careful. If its well written and well documented and not too large to
be a problem with understanding, then why auto-translate? Why not just read
it, understand it and re-write it? (or use it as-is?) That way the developer
doing the work is now up to speed on the internals of the code and you're
not confronted with unmaintainable crap from some auto-generator.

If its too big, poorly documented or poorly constructed - thus motivating an
auto-translation - then you're going to end up with a body of code nobody
understands and that nobody can enhance or maintain. (and is probably going
to be broken in the auto-translation phase!) This is possibly O.K. for a
short-term, quick-and-dirty fix (although I have my doubts) but it would be
disasterous if you have to live with it for some length of time. More likely
something like this will cost more in the long run than just biting the
bullet and redesigning it - especially if you think you need new features
along the way.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Wes Groleau" <wesgroleau@despammed.com> wrote in message
news:3D062797.15D77E1B@despammed.com...
>
> Indeed.  Updating code without changing languages
> sometimes takes a lot of change.
>
> The fact that it was written in C makes a high probability
> that it will REALLY take a lot of work--unless you personally
> know that a top-quality process was followed to create it.
>

Re: Commercial C To Ada 95 compiler

[Pascal Obry]

I agree 100% with Marin. Either the code is running fine and you should use it
as-is. Why taking the risk to break something during the translation ? Just
build a nice library and interface to it. If the code is not good (not
documented, not running well, too expensive to maintain) you should consider
to rewrite it from scratch.

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: Commercial C To Ada 95 compiler

[Wes Groleau]

> In fact this is not an error in C.  Programs can (and do) intentionally
> index past the end of arrays.  I have seen C code that allocates memory

But more often it's not intentional, it's a bug.
And the Ada compiler will tell you so, sometimes
during compile, sometimes during execution.

> > to make all implicit C conversions explicit in Ada.
> 
> I disagree, direct translation is possible.  The order of conversions in C
> is explicitly defined.  The translation would have to turn these implicit
> conversions into explicit conversions.  Again, a review of the translated

But doing so would be hiding bugs.  Not all implicit
conversions in C are intended by the programmer.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Commercial C To Ada 95 compiler

[Larry Kilgallen]

In article <3D04F442.741C386C@despammed.com>, Wes Groleau <wesgroleau@despammed.com> writes:

>> > to make all implicit C conversions explicit in Ada.
>> 
>> I disagree, direct translation is possible.  The order of conversions in C
>> is explicitly defined.  The translation would have to turn these implicit
>> conversions into explicit conversions.  Again, a review of the translated
> 
> But doing so would be hiding bugs.  Not all implicit
> conversions in C are intended by the programmer.

It seems to me making the implicit conversions into expliccit conversions
would be "unhiding" them.  Some standard comment text to indicate an
unreviewed conversion could be inserted in the output source.

Re: Commercial C To Ada 95 compiler

[Wes Groleau]

> It seems to me making the implicit conversions into expliccit conversions
> would be "unhiding" them.  Some standard comment text to indicate an
> unreviewed conversion could be inserted in the output source.

What I'm saying is that in C, implicit conversions
are three kinds:

1. Intentional documented implementation decisions
2. Intentional undocumented implementation decisions
3. Careless mistakes, whether harmful or not.

An automatic translator cannot tell the difference.
Usually, neither can a human translator.  Making
all of them explicit conversions hides the bugs
unless you comment them as you say.

Not making any explicit will show all the bugs,
but it forces you to identify and fix all the
ones that are not bugs before you can compile.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Commercial C To Ada 95 compiler

[Robert A Duff]

Wes Groleau <wesgroleau@despammed.com> writes:

> > It seems to me making the implicit conversions into expliccit conversions
> > would be "unhiding" them.  Some standard comment text to indicate an
> > unreviewed conversion could be inserted in the output source.
> 
> What I'm saying is that in C, implicit conversions
> are three kinds:
> 
> 1. Intentional documented implementation decisions
> 2. Intentional undocumented implementation decisions
> 3. Careless mistakes, whether harmful or not.

Right, and surely the vast majority are not of kind 3...

> An automatic translator cannot tell the difference.
> Usually, neither can a human translator.  Making
> all of them explicit conversions hides the bugs
> unless you comment them as you say.
> 
> Not making any explicit will show all the bugs,
> but it forces you to identify and fix all the
> ones that are not bugs before you can compile.

...which is most of them.

- Bob

Re: Commercial C To Ada 95 compiler

[Wes Groleau]

> > 1. Intentional documented implementation decisions
> > 2. Intentional undocumented implementation decisions
> > 3. Careless mistakes, whether harmful or not.
> 
> Right, and surely the vast majority are not of kind 3...

C and C culture being what it is, I imagine
a LOT of them are.  Much of the C code I've
seen gives the distinct impression that it
never had ANY implementation "decisions" except
those made when after it failed.  Of course,
I can't say I've never seen Ada code like that.  :-)

Considering the quantity of careless mistakes
I've seen in Ada--a language that discourages
them--how much better can it be in a language
that encourages them?

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Commercial C To Ada 95 compiler

[Robert Dewar]

Jim Rogers <jimmaureenrogers@worldnet.att.net> wrote in message news:<3D018106.6080004@worldnet.att.net>...
> SteveD wrote:

> One simple example is indexing past the end of an array.
> C compilers simply will not catch this problem. Ada compilers will.

Indexing past the end of an array is definitely an error in C. Some cases
can be caught at compile time, others at run time.

Re: Commercial C To Ada 95 compiler

[Richard Riehle]

Jim Rogers wrote:

> One simple example is indexing past the end of an array.
> C compilers simply will not catch this problem. Ada compilers will.

Actually, note that the following program that indexes off the end
of an array will compile in Ada.

     procedure Index_Past_The_End is
             type Vector is array(Positive range <>) of Integer;
             The_Vector : Vector (1..100) := (others => 0);
    begin
          for I in The_Vector'First .. The_Vector'Last + 1
              loop
                   null;
              end loop;
    end Index_Past_The_End;

Richard Riehle

Re: Commercial C To Ada 95 compiler

[Preben Randhol]

On Sat, 08 Jun 2002 08:53:28 -0700, Richard Riehle wrote:
> Jim Rogers wrote:
> 
>> One simple example is indexing past the end of an array.
>> C compilers simply will not catch this problem. Ada compilers will.
> 
> Actually, note that the following program that indexes off the end
> of an array will compile in Ada.
> 
>      procedure Index_Past_The_End is
>              type Vector is array(Positive range <>) of Integer;
>              The_Vector : Vector (1..100) := (others => 0);
>     begin
>           for I in The_Vector'First .. The_Vector'Last + 1
>               loop
>                    null;
>               end loop;
>     end Index_Past_The_End;

Yes, however the Ada program will end with an exception at run-time.
With the C program anything could happen, even a reboot I guess.

Preben

Re: Commercial C To Ada 95 compiler

[Marin David Condic]

Would it? If you never reference "The_Vector (101)" does it raise an
exception? But then, of course, one must ask if this constitutes "indexing
off the end of an array."

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnag4acc.3fs.randhol+abuse@kiuk0156.chembio.ntnu.no...
>
> Yes, however the Ada program will end with an exception at run-time.
> With the C program anything could happen, even a reboot I guess.
>
> Preben

Re: Commercial C To Ada 95 compiler

[Darren New]

Marin David Condic wrote:
> Would it? If you never reference "The_Vector (101)" does it raise an
> exception? But then, of course, one must ask if this constitutes "indexing
> off the end of an array."

Well, in theory

{ char x[3]; char * y = x;
  y++; y++; y++; y++; y++;
}

is illegal. You're indexing off the end of the x array.

Of course, very few compilers enforce this.


-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: Commercial C To Ada 95 compiler

[Marin David Condic]

Unless my intent was to figure out the address of the thing located just
after X - probably Y in this case. :-) The thing is that it isn't really an
error until you are trying to de-reference the thing pointed to by Y. Before
that its just incrementing a counter - which might be done for all sorts of
reasons none of which may have anything to do with the array X.

Its not "normal" programming, so I'd agree that it would be really nice to
know when someone is making this kind of error. Its just that this
particular case might come under the heading of "No Harm - No Foul" - It may
be an error in the code, but one that has no impact on the correct operation
of the program.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Darren New" <dnew@san.rr.com> wrote in message
news:3D053737.476B8185@san.rr.com...
>
> Well, in theory
>
> { char x[3]; char * y = x;
>   y++; y++; y++; y++; y++;
> }
>
> is illegal. You're indexing off the end of the x array.
>
> Of course, very few compilers enforce this.
>

Re: Commercial C To Ada 95 compiler

[Darren New]

Marin David Condic wrote:
> 
> Unless my intent was to figure out the address of the thing located just
> after X - probably Y in this case. 

You're allowed to go one past the end in either direction. You're not
allowed to go two past the end.

> The thing is that it isn't really an
> error until you are trying to de-reference the thing pointed to by Y.

This is what I'm saying. No, that's theoretically incorrect. It *is* an
error even if you don't try to dereference the thing pointed to by Y. Simply
doing the arithmetic on Y is in theory erroneous.

> Before
> that its just incrementing a counter - which might be done for all sorts of
> reasons none of which may have anything to do with the array X.

Well, no, it's incrementing a pointer into the array X. If you were talking
about using array subscripting, that would be true. But if you're talking
about incrementing pointers rather than integers, the hardware is allowed to
enforce (for example) segments of exactly the right size, such that a
pointer to one chunk of memory is not allowed to point to a different chunk
of memory via incrementing.

> particular case might come under the heading of "No Harm - No Foul" - It may
> be an error in the code, but one that has no impact on the correct operation
> of the program.

Until you port it to a machine that actually checks it, or to a C compiler
or interpreter that actually implements the range checks it's allowed to
implement.

My point is that the C standard says you're *allowed* to implement range
checking on arrays. In practice, very few do, and in my experience, those
that do are specifically low-performance debugging type interpreters.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: Commercial C To Ada 95 compiler

[David Thompson]

Darren New <dnew@san.rr.com> wrote :
> Marin David Condic wrote:
> >
[ about C:  int * p = array; p++; p++; etc. ]
> > Unless my intent was to figure out the address of the thing located just
> > after X - probably Y in this case.
>
> You're allowed to go one past the end in either direction. You're not
> allowed to go two past the end.
>
To be really precise, in Standard/portable C you are allowed to
compute the address (pointer) one-past-the-(right-)end, but not
dereference it.  This allows the common idiom (dating from
before standardization):
  for( p = array; p < array+n; p++ ) do_something_with(*p);
  /* and all variants/isomorphs thereof */

You cannot safely even compute array-1 or array+N+1.
In C89 in theory you cannot even use &array[N] instead of
array+N, because in the abstract semantics this actually
dereferences to form the lvalue before taking its address.
In practice all compiles actually implement &*(array+n)
as array+n and this works because of the memory layout
requirements above, and C99 adds an explicit blessing.

> > The thing is that it isn't really an
> > error until you are trying to de-reference the thing pointed to by Y.
>
> This is what I'm saying. No, that's theoretically incorrect. It *is* an
> error even if you don't try to dereference the thing pointed to by Y. Simply
> doing the arithmetic on Y is in theory erroneous.
>
Right.  As above.

> > Before
> > that its just incrementing a counter - which might be done for all sorts of
> > reasons none of which may have anything to do with the array X.
>
> Well, no, it's incrementing a pointer into the array X. If you were talking
> about using array subscripting, that would be true. But if you're talking
> about incrementing pointers rather than integers, the hardware is allowed to
> enforce (for example) segments of exactly the right size, such that a
> pointer to one chunk of memory is not allowed to point to a different chunk
> of memory via incrementing.
>
And, perhaps slightly more likely, to place an array beginning at
the base of a segment, so that the "-1" address does not exist.
But not to put an array exactly at the end of a segment, or the
end of the address space.  However, there need only be one byte
(perhaps otherwise unused) following the end, whereas supporting
-1 would require a whole array element (possibly quite large)
before the beginning; this asymmetry is often given as the rationale,
in addition to the asymmetry of the idiomatic half-open ranges.

...
> My point is that the C standard says you're *allowed* to implement range
> checking on arrays. In practice, very few do, and in my experience, those
> that do are specifically low-performance debugging type interpreters.
>
Yes.

--
- David.Thompson 1 now at worldnet.att.net

Re: Commercial C To Ada 95 compiler

[tmoran]

> the following program that indexes off the end of an array will compile
> in Ada.
>         for I in The_Vector'First .. The_Vector'Last + 1
>             loop
>                  null;
>             end loop;
 I don't see any indexing going on at all.

Re: Commercial C To Ada 95 compiler

[Pascal Obry]

Richard Riehle <richard@adaworks.com> writes:

> Actually, note that the following program that indexes off the end
> of an array will compile in Ada.

No it does not, there is nothing into the loop.

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: Commercial C To Ada 95 compiler

[Richard Riehle]

Pascal Obry wrote:

> Richard Riehle <richard@adaworks.com> writes:
>
> > Actually, note that the following program that indexes off the end
> > of an array will compile in Ada.
>
> No it does not, there is nothing into the loop.

  OK.  Replace the null statement with
                 The_Vector(I) := 0;

  This will still compile.    The point is that someone said this
  kind of thing would be rejected as an error by an Ada compiler.
  It is not rejected by every compiler, even though some compilers
  might provide a warning.

  I agree with the comment that it will be caught at run-time.  No
  argument that the outcome is better than one might expect from
  a C program.   However, the assertion that the compiler will
  detect it is wrong, even when you add code to manipulate the
  content of the array and not just the index.

  Richard Riehle

Re: Commercial C To Ada 95 compiler

[Fraser Wilson]

Richard Riehle <richard@adaworks.com> writes:

>   This will still compile.    The point is that someone said this
>   kind of thing would be rejected as an error by an Ada compiler.
>   It is not rejected by every compiler, even though some compilers
>   might provide a warning.

True.  On the other hand, everybody iterates through arrays with a for
loop over the range, an option not available in C.  I think this is
idiom one of the key wins for Ada: no range checking required, no
performance penalty, and no chance of a run time exception.

I expect that detecting this as a special case in a C to Ada compiler
would not be excessively difficult, assuming the array bounds were
available somewhere (though recognising the extra length argument to
an array handling function would be tricky).

cheers,
Fraser.

Re: Commercial C To Ada 95 compiler

[Jim Rogers]

Richard Riehle wrote:

> Jim Rogers wrote:
> 
> 
>>One simple example is indexing past the end of an array.
>>C compilers simply will not catch this problem. Ada compilers will.
>>
> 
> Actually, note that the following program that indexes off the end
> of an array will compile in Ada.
> 
>      procedure Index_Past_The_End is
>              type Vector is array(Positive range <>) of Integer;
>              The_Vector : Vector (1..100) := (others => 0);
>     begin
>           for I in The_Vector'First .. The_Vector'Last + 1
>               loop
>                    null;
>               end loop;
>     end Index_Past_The_End;


Ah, but you are not indexing the array. You are merely creating
a range based upon the array index range. You can iterate through
any range you want. You will get a compiler error when you
attempt to access (index) an array "element" beyond either end of
the array.

    The_Vector(The_Vector'Last + 1) := 10;

Jim Rogers

Re: Commercial C To Ada 95 compiler

[Richard Riehle]

Jim Rogers wrote:

> Richard Riehle wrote:
>
> > Jim Rogers wrote:
> >
> >
> >>One simple example is indexing past the end of an array.
> >>C compilers simply will not catch this problem. Ada compilers will.
> >>
> >
> > Actually, note that the following program that indexes off the end
> > of an array will compile in Ada.
> >
> >      procedure Index_Past_The_End is
> >              type Vector is array(Positive range <>) of Integer;
> >              The_Vector : Vector (1..100) := (others => 0);
> >     begin
> >           for I in The_Vector'First .. The_Vector'Last + 1
> >               loop
> >                    null;
> >               end loop;
> >     end Index_Past_The_End;
>
> Ah, but you are not indexing the array. You are merely creating
> a range based upon the array index range. You can iterate through
> any range you want. You will get a compiler error when you
> attempt to access (index) an array "element" beyond either end of
> the array.
>
>     The_Vector(The_Vector'Last + 1) := 10;
>
> Jim Rogers

You are correct about this example Jim.   It is also true that in my
original example,  the null statement does not cause a run-time error.
I used the null because I was being lazy.

However, in my other post where I suggested adding,
               The_Vector(I) := 10;
the code is doing an indexed operation and will, at execution,
attempt to index past the end of the array.   This will raise
a constraint_error at run-time that is not detected by the compiler.

Richard Riehle