* Commercial C To Ada 95 compiler @ 2002-06-03 9:26 Henrik Quintel 2002-06-03 18:52 ` Ingo Marks ` (2 more replies) 0 siblings, 3 replies; 56+ messages in thread From: Henrik Quintel @ 2002-06-03 9:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-03 9:26 Commercial C To Ada 95 compiler Henrik Quintel @ 2002-06-03 18:52 ` Ingo Marks 2002-06-04 6:40 ` Henrik Quintel 2002-06-03 20:26 ` Florian Weimer 2002-06-07 3:48 ` Richard Riehle 2 siblings, 1 reply; 56+ messages in thread From: Ingo Marks @ 2002-06-03 18:52 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-03 18:52 ` Ingo Marks @ 2002-06-04 6:40 ` Henrik Quintel 2002-06-04 14:11 ` Frank J. Lhota 0 siblings, 1 reply; 56+ messages in thread From: Henrik Quintel @ 2002-06-04 6:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-04 6:40 ` Henrik Quintel @ 2002-06-04 14:11 ` Frank J. Lhota 2002-06-04 14:26 ` Preben Randhol 0 siblings, 1 reply; 56+ messages in thread From: Frank J. Lhota @ 2002-06-04 14:11 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-04 14:11 ` Frank J. Lhota @ 2002-06-04 14:26 ` Preben Randhol 2002-06-04 16:38 ` Frank J. Lhota 0 siblings, 1 reply; 56+ messages in thread From: Preben Randhol @ 2002-06-04 14:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-04 14:26 ` Preben Randhol @ 2002-06-04 16:38 ` Frank J. Lhota 0 siblings, 0 replies; 56+ messages in thread From: Frank J. Lhota @ 2002-06-04 16:38 UTC (permalink / raw) > Does the bugs get reproduced too ;-) Oh absolutely! Not to mention adding new ones. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-03 9:26 Commercial C To Ada 95 compiler Henrik Quintel 2002-06-03 18:52 ` Ingo Marks @ 2002-06-03 20:26 ` Florian Weimer 2002-06-04 6:43 ` Henrik Quintel 2002-06-07 3:48 ` Richard Riehle 2 siblings, 1 reply; 56+ messages in thread From: Florian Weimer @ 2002-06-03 20:26 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-03 20:26 ` Florian Weimer @ 2002-06-04 6:43 ` Henrik Quintel 2002-06-04 14:18 ` Lutz Donnerhacke 0 siblings, 1 reply; 56+ messages in thread From: Henrik Quintel @ 2002-06-04 6:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-04 6:43 ` Henrik Quintel @ 2002-06-04 14:18 ` Lutz Donnerhacke 0 siblings, 0 replies; 56+ messages in thread From: Lutz Donnerhacke @ 2002-06-04 14:18 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-03 9:26 Commercial C To Ada 95 compiler Henrik Quintel 2002-06-03 18:52 ` Ingo Marks 2002-06-03 20:26 ` Florian Weimer @ 2002-06-07 3:48 ` Richard Riehle 2002-06-07 12:46 ` SteveD 2002-06-07 13:21 ` Larry Kilgallen 2 siblings, 2 replies; 56+ messages in thread From: Richard Riehle @ 2002-06-07 3:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-07 3:48 ` Richard Riehle @ 2002-06-07 12:46 ` SteveD 2002-06-07 13:20 ` Marin David Condic 2002-06-07 13:21 ` Larry Kilgallen 1 sibling, 1 reply; 56+ messages in thread From: SteveD @ 2002-06-07 12:46 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-07 12:46 ` SteveD @ 2002-06-07 13:20 ` Marin David Condic 2002-06-09 21:43 ` Stephen Leake 0 siblings, 1 reply; 56+ messages in thread From: Marin David Condic @ 2002-06-07 13:20 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-07 13:20 ` Marin David Condic @ 2002-06-09 21:43 ` Stephen Leake 2002-06-10 13:17 ` Marin David Condic 0 siblings, 1 reply; 56+ messages in thread From: Stephen Leake @ 2002-06-09 21:43 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-09 21:43 ` Stephen Leake @ 2002-06-10 13:17 ` Marin David Condic 2002-06-11 12:52 ` SteveD 0 siblings, 1 reply; 56+ messages in thread From: Marin David Condic @ 2002-06-10 13:17 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-10 13:17 ` Marin David Condic @ 2002-06-11 12:52 ` SteveD 2002-06-11 13:32 ` Marin David Condic 0 siblings, 1 reply; 56+ messages in thread From: SteveD @ 2002-06-11 12:52 UTC (permalink / raw) "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 > ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-11 12:52 ` SteveD @ 2002-06-11 13:32 ` Marin David Condic 2002-06-12 14:07 ` Larry Kilgallen 0 siblings, 1 reply; 56+ messages in thread From: Marin David Condic @ 2002-06-11 13:32 UTC (permalink / raw) 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". > ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-11 13:32 ` Marin David Condic @ 2002-06-12 14:07 ` Larry Kilgallen 2002-06-12 13:21 ` Marin David Condic 0 siblings, 1 reply; 56+ messages in thread From: Larry Kilgallen @ 2002-06-12 14:07 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-12 14:07 ` Larry Kilgallen @ 2002-06-12 13:21 ` Marin David Condic 0 siblings, 0 replies; 56+ messages in thread From: Marin David Condic @ 2002-06-12 13:21 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-07 3:48 ` Richard Riehle 2002-06-07 12:46 ` SteveD @ 2002-06-07 13:21 ` Larry Kilgallen 2002-06-07 19:48 ` Ted Dennison 1 sibling, 1 reply; 56+ messages in thread From: Larry Kilgallen @ 2002-06-07 13:21 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-07 13:21 ` Larry Kilgallen @ 2002-06-07 19:48 ` Ted Dennison 2002-06-07 20:26 ` Wes Groleau 0 siblings, 1 reply; 56+ messages in thread From: Ted Dennison @ 2002-06-07 19:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-07 19:48 ` Ted Dennison @ 2002-06-07 20:26 ` Wes Groleau 2002-06-08 3:19 ` SteveD 0 siblings, 1 reply; 56+ messages in thread From: Wes Groleau @ 2002-06-07 20:26 UTC (permalink / raw) > > >> 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-07 20:26 ` Wes Groleau @ 2002-06-08 3:19 ` SteveD 2002-06-08 3:59 ` Jim Rogers 0 siblings, 1 reply; 56+ messages in thread From: SteveD @ 2002-06-08 3:19 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-08 3:19 ` SteveD @ 2002-06-08 3:59 ` Jim Rogers 2002-06-08 4:14 ` Darren New ` (3 more replies) 0 siblings, 4 replies; 56+ messages in thread From: Jim Rogers @ 2002-06-08 3:59 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-08 3:59 ` Jim Rogers @ 2002-06-08 4:14 ` Darren New 2002-06-08 4:50 ` SteveD 2002-06-10 18:44 ` Wes Groleau 2002-06-08 4:46 ` SteveD ` (2 subsequent siblings) 3 siblings, 2 replies; 56+ messages in thread From: Darren New @ 2002-06-08 4:14 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-08 4:14 ` Darren New @ 2002-06-08 4:50 ` SteveD 2002-06-08 12:04 ` Robert Dewar 2002-06-10 18:44 ` Wes Groleau 1 sibling, 1 reply; 56+ messages in thread From: SteveD @ 2002-06-08 4:50 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-08 4:50 ` SteveD @ 2002-06-08 12:04 ` Robert Dewar 0 siblings, 0 replies; 56+ messages in thread From: Robert Dewar @ 2002-06-08 12:04 UTC (permalink / raw) "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 :-) ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-08 4:14 ` Darren New 2002-06-08 4:50 ` SteveD @ 2002-06-10 18:44 ` Wes Groleau 2002-06-10 19:23 ` Darren New 1 sibling, 1 reply; 56+ messages in thread From: Wes Groleau @ 2002-06-10 18:44 UTC (permalink / raw) > > 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-10 18:44 ` Wes Groleau @ 2002-06-10 19:23 ` Darren New 2002-06-10 20:55 ` Wes Groleau 0 siblings, 1 reply; 56+ messages in thread From: Darren New @ 2002-06-10 19:23 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-10 19:23 ` Darren New @ 2002-06-10 20:55 ` Wes Groleau 2002-06-10 21:03 ` Darren New 0 siblings, 1 reply; 56+ messages in thread From: Wes Groleau @ 2002-06-10 20:55 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-10 20:55 ` Wes Groleau @ 2002-06-10 21:03 ` Darren New 0 siblings, 0 replies; 56+ messages in thread From: Darren New @ 2002-06-10 21:03 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-08 3:59 ` Jim Rogers 2002-06-08 4:14 ` Darren New @ 2002-06-08 4:46 ` SteveD 2002-06-08 12:11 ` Robert Dewar 2002-06-10 18:47 ` Wes Groleau 2002-06-08 12:06 ` Robert Dewar 2002-06-08 15:53 ` Richard Riehle 3 siblings, 2 replies; 56+ messages in thread From: SteveD @ 2002-06-08 4:46 UTC (permalink / raw) "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 > ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-08 4:46 ` SteveD @ 2002-06-08 12:11 ` Robert Dewar 2002-06-08 18:46 ` SteveD 2002-06-10 18:47 ` Wes Groleau 1 sibling, 1 reply; 56+ messages in thread From: Robert Dewar @ 2002-06-08 12:11 UTC (permalink / raw) > 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). ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-08 12:11 ` Robert Dewar @ 2002-06-08 18:46 ` SteveD 2002-06-10 13:34 ` Marin David Condic 0 siblings, 1 reply; 56+ messages in thread From: SteveD @ 2002-06-08 18:46 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-08 18:46 ` SteveD @ 2002-06-10 13:34 ` Marin David Condic 2002-06-11 16:38 ` Wes Groleau 0 siblings, 1 reply; 56+ messages in thread From: Marin David Condic @ 2002-06-10 13:34 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-10 13:34 ` Marin David Condic @ 2002-06-11 16:38 ` Wes Groleau 2002-06-11 17:27 ` Marin David Condic 0 siblings, 1 reply; 56+ messages in thread From: Wes Groleau @ 2002-06-11 16:38 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-11 16:38 ` Wes Groleau @ 2002-06-11 17:27 ` Marin David Condic 2002-06-12 13:18 ` Pascal Obry 0 siblings, 1 reply; 56+ messages in thread From: Marin David Condic @ 2002-06-11 17:27 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-11 17:27 ` Marin David Condic @ 2002-06-12 13:18 ` Pascal Obry 0 siblings, 0 replies; 56+ messages in thread From: Pascal Obry @ 2002-06-12 13:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-08 4:46 ` SteveD 2002-06-08 12:11 ` Robert Dewar @ 2002-06-10 18:47 ` Wes Groleau 2002-06-10 21:23 ` Larry Kilgallen 1 sibling, 1 reply; 56+ messages in thread From: Wes Groleau @ 2002-06-10 18:47 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-10 18:47 ` Wes Groleau @ 2002-06-10 21:23 ` Larry Kilgallen 2002-06-10 20:59 ` Wes Groleau 0 siblings, 1 reply; 56+ messages in thread From: Larry Kilgallen @ 2002-06-10 21:23 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-10 21:23 ` Larry Kilgallen @ 2002-06-10 20:59 ` Wes Groleau 2002-06-10 21:37 ` Robert A Duff 0 siblings, 1 reply; 56+ messages in thread From: Wes Groleau @ 2002-06-10 20:59 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-10 20:59 ` Wes Groleau @ 2002-06-10 21:37 ` Robert A Duff 2002-06-10 22:34 ` Wes Groleau 0 siblings, 1 reply; 56+ messages in thread From: Robert A Duff @ 2002-06-10 21:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-10 21:37 ` Robert A Duff @ 2002-06-10 22:34 ` Wes Groleau 0 siblings, 0 replies; 56+ messages in thread From: Wes Groleau @ 2002-06-10 22:34 UTC (permalink / raw) > > 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-08 3:59 ` Jim Rogers 2002-06-08 4:14 ` Darren New 2002-06-08 4:46 ` SteveD @ 2002-06-08 12:06 ` Robert Dewar 2002-06-08 15:53 ` Richard Riehle 3 siblings, 0 replies; 56+ messages in thread From: Robert Dewar @ 2002-06-08 12:06 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-08 3:59 ` Jim Rogers ` (2 preceding siblings ...) 2002-06-08 12:06 ` Robert Dewar @ 2002-06-08 15:53 ` Richard Riehle 2002-06-08 15:58 ` Preben Randhol ` (3 more replies) 3 siblings, 4 replies; 56+ messages in thread From: Richard Riehle @ 2002-06-08 15:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-08 15:53 ` Richard Riehle @ 2002-06-08 15:58 ` Preben Randhol 2002-06-10 13:37 ` Marin David Condic 2002-06-08 17:45 ` tmoran ` (2 subsequent siblings) 3 siblings, 1 reply; 56+ messages in thread From: Preben Randhol @ 2002-06-08 15:58 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-08 15:58 ` Preben Randhol @ 2002-06-10 13:37 ` Marin David Condic 2002-06-10 23:32 ` Darren New 0 siblings, 1 reply; 56+ messages in thread From: Marin David Condic @ 2002-06-10 13:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-10 13:37 ` Marin David Condic @ 2002-06-10 23:32 ` Darren New 2002-06-11 13:11 ` Marin David Condic 0 siblings, 1 reply; 56+ messages in thread From: Darren New @ 2002-06-10 23:32 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-10 23:32 ` Darren New @ 2002-06-11 13:11 ` Marin David Condic 2002-06-12 15:42 ` Darren New 0 siblings, 1 reply; 56+ messages in thread From: Marin David Condic @ 2002-06-11 13:11 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-11 13:11 ` Marin David Condic @ 2002-06-12 15:42 ` Darren New 2002-06-21 17:23 ` David Thompson 0 siblings, 1 reply; 56+ messages in thread From: Darren New @ 2002-06-12 15:42 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-12 15:42 ` Darren New @ 2002-06-21 17:23 ` David Thompson 0 siblings, 0 replies; 56+ messages in thread From: David Thompson @ 2002-06-21 17:23 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-08 15:53 ` Richard Riehle 2002-06-08 15:58 ` Preben Randhol @ 2002-06-08 17:45 ` tmoran 2002-06-08 18:32 ` Pascal Obry 2002-06-08 20:06 ` Jim Rogers 3 siblings, 0 replies; 56+ messages in thread From: tmoran @ 2002-06-08 17:45 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-08 15:53 ` Richard Riehle 2002-06-08 15:58 ` Preben Randhol 2002-06-08 17:45 ` tmoran @ 2002-06-08 18:32 ` Pascal Obry 2002-06-09 17:41 ` Richard Riehle 2002-06-08 20:06 ` Jim Rogers 3 siblings, 1 reply; 56+ messages in thread From: Pascal Obry @ 2002-06-08 18:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-08 18:32 ` Pascal Obry @ 2002-06-09 17:41 ` Richard Riehle 2002-06-10 8:11 ` Fraser Wilson 0 siblings, 1 reply; 56+ messages in thread From: Richard Riehle @ 2002-06-09 17:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-09 17:41 ` Richard Riehle @ 2002-06-10 8:11 ` Fraser Wilson 0 siblings, 0 replies; 56+ messages in thread From: Fraser Wilson @ 2002-06-10 8:11 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-08 15:53 ` Richard Riehle ` (2 preceding siblings ...) 2002-06-08 18:32 ` Pascal Obry @ 2002-06-08 20:06 ` Jim Rogers 2002-06-09 17:49 ` Richard Riehle 3 siblings, 1 reply; 56+ messages in thread From: Jim Rogers @ 2002-06-08 20:06 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Commercial C To Ada 95 compiler 2002-06-08 20:06 ` Jim Rogers @ 2002-06-09 17:49 ` Richard Riehle 0 siblings, 0 replies; 56+ messages in thread From: Richard Riehle @ 2002-06-09 17:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
end of thread, other threads:[~2002-06-21 17:23 UTC | newest] Thread overview: 56+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-06-03 9:26 Commercial C To Ada 95 compiler Henrik Quintel 2002-06-03 18:52 ` Ingo Marks 2002-06-04 6:40 ` Henrik Quintel 2002-06-04 14:11 ` Frank J. Lhota 2002-06-04 14:26 ` Preben Randhol 2002-06-04 16:38 ` Frank J. Lhota 2002-06-03 20:26 ` Florian Weimer 2002-06-04 6:43 ` Henrik Quintel 2002-06-04 14:18 ` Lutz Donnerhacke 2002-06-07 3:48 ` Richard Riehle 2002-06-07 12:46 ` SteveD 2002-06-07 13:20 ` Marin David Condic 2002-06-09 21:43 ` Stephen Leake 2002-06-10 13:17 ` Marin David Condic 2002-06-11 12:52 ` SteveD 2002-06-11 13:32 ` Marin David Condic 2002-06-12 14:07 ` Larry Kilgallen 2002-06-12 13:21 ` Marin David Condic 2002-06-07 13:21 ` Larry Kilgallen 2002-06-07 19:48 ` Ted Dennison 2002-06-07 20:26 ` Wes Groleau 2002-06-08 3:19 ` SteveD 2002-06-08 3:59 ` Jim Rogers 2002-06-08 4:14 ` Darren New 2002-06-08 4:50 ` SteveD 2002-06-08 12:04 ` Robert Dewar 2002-06-10 18:44 ` Wes Groleau 2002-06-10 19:23 ` Darren New 2002-06-10 20:55 ` Wes Groleau 2002-06-10 21:03 ` Darren New 2002-06-08 4:46 ` SteveD 2002-06-08 12:11 ` Robert Dewar 2002-06-08 18:46 ` SteveD 2002-06-10 13:34 ` Marin David Condic 2002-06-11 16:38 ` Wes Groleau 2002-06-11 17:27 ` Marin David Condic 2002-06-12 13:18 ` Pascal Obry 2002-06-10 18:47 ` Wes Groleau 2002-06-10 21:23 ` Larry Kilgallen 2002-06-10 20:59 ` Wes Groleau 2002-06-10 21:37 ` Robert A Duff 2002-06-10 22:34 ` Wes Groleau 2002-06-08 12:06 ` Robert Dewar 2002-06-08 15:53 ` Richard Riehle 2002-06-08 15:58 ` Preben Randhol 2002-06-10 13:37 ` Marin David Condic 2002-06-10 23:32 ` Darren New 2002-06-11 13:11 ` Marin David Condic 2002-06-12 15:42 ` Darren New 2002-06-21 17:23 ` David Thompson 2002-06-08 17:45 ` tmoran 2002-06-08 18:32 ` Pascal Obry 2002-06-09 17:41 ` Richard Riehle 2002-06-10 8:11 ` Fraser Wilson 2002-06-08 20:06 ` Jim Rogers 2002-06-09 17:49 ` Richard Riehle
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox