* Urgent question: malloc and ada... @ 1998-04-07 0:00 Guido Tesch 1998-04-09 0:00 ` Joe Gwinn 0 siblings, 1 reply; 43+ messages in thread From: Guido Tesch @ 1998-04-07 0:00 UTC (permalink / raw) High there. I have a serious problem with interfacing between Ada and C. In a C program, I allocate a lot of memory via malloc (more than one MB). When I run the Ada program that interfaces with the C stuff, I get a segmentation fault exactly at a point, where a subprocedure is called, before even the first code line of this procedure is touched. My guess is that the memory management from C and Ada do not work together when doing big mallocs, and that some portion of my Ada program code had been overwritten by C's mallocs. Do you have experiences with this kind of stuff? Could you tell me if I'm right and how to solve this ugly problem? Thanks in advance. Guido P.S.: Answers please via mailto:guido.tesch@gmd.de Thank you. -- //// 0(o o)0 -oOO--(_)--OOo-------------------------------------------------------- University of Bonn, Germany Guido E-Mail: tesch@informatik.uni-bonn.de Tesch URL: http://titan.informatik.uni-bonn.de/~tesch oooO Presently working at GMD, Sankt Augustin, Germany ( ) Oooo http://www.gmd.de/ Tel.: +49-2241-14-2714 ---\ (---( )-------------------------------------------------------- \_) ) / (_/ ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada... 1998-04-07 0:00 Urgent question: malloc and ada Guido Tesch @ 1998-04-09 0:00 ` Joe Gwinn 1998-04-10 0:00 ` Urgent question: malloc and ada...READ/NEW/FOLLOWUP Larry Kilgallen 1998-04-10 0:00 ` Urgent question: malloc and ada Robert Dewar 0 siblings, 2 replies; 43+ messages in thread From: Joe Gwinn @ 1998-04-09 0:00 UTC (permalink / raw) In article <352A79C2.15FB7483@nathan.gmd.de>, Guido Tesch <tesch@nathan.gmd.de> wrote: > Hi there. > > I have a serious problem with interfacing between Ada and C. In a C > program, I allocate a lot of memory via malloc (more than one MB). When > I run the Ada program that interfaces with the C stuff, I get a > segmentation fault exactly at a point, where a subprocedure is called, > before even the first code line of this procedure is touched. My guess > is that the memory management from C and Ada do not work together when > doing big mallocs, and that some portion of my Ada program code had been > overwritten by C's mallocs. > > Do you have experiences with this kind of stuff? Could you tell me if > I'm right and how to solve this ugly problem? You don't have any reason to believe that this is a malloc versus Ada question, based on your description. In my experience, the fastest way to resolve such a problem is to debug the Ada and C programs with an assembly-level debugger, which can see things as they truely are. Put a breakpoint just before the fatal subroutine jump, and single-step into the subroutine. The cause should become blindingly obvious at that point. Don't assume that the Ada and C compilers have generated correct assembly code, or that they agree on how C-Ada subroutine interfaces work, in exact detail. It sounds like you are calling Ada from C; this is difficult to impossible with Ada83, and better with Ada95, but is often tricky. Ada83 really expected to be on top, to be the main(), and it was often easier to call C from an Ada main than to call Ada from a C main. C may well not be setting the stack and registers up to Ada's liking. Or vica versa. In Ada83, some compilers allowed one to declare Ada procedures as interrupt routines, with minimal expectations of the environment from which they will be called, and one can in fact call such routines from C, although passing parameters is difficult. Some compilers also allowed one to say that an Ada procedure would be called from some foreign language; this is like the ISR case, except one could have parameters. And so on. Joe Gwinn ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP 1998-04-09 0:00 ` Joe Gwinn @ 1998-04-10 0:00 ` Larry Kilgallen 1998-04-12 0:00 ` Joe Gwinn 1998-04-10 0:00 ` Urgent question: malloc and ada Robert Dewar 1 sibling, 1 reply; 43+ messages in thread From: Larry Kilgallen @ 1998-04-10 0:00 UTC (permalink / raw) In article <gwinn-0904982253200001@d183.dial-5.cmb.ma.ultra.net>, gwinn@ma.ultranet.com (Joe Gwinn) writes: > detail. It sounds like you are calling Ada from C; this is difficult to > impossible with Ada83, and better with Ada95, but is often tricky. Ada83 > really expected to be on top, to be the main(), and it was often easier to > call C from an Ada main than to call Ada from a C main. Those limitations regarding which language was used for the main program may be true for some particular Ada83 implementation with which you are familiar, but they are not a characteristic of the Ada83 language itself. One problem I have heard discussed here is "elaboration", and DEC Ada for VMS has always done that via the LIB$INITIALIZE mechanism of the operating system, without requiring the main program be written in Ada. (There was a bug 10 years ago when sharable images (DLLs) were used, but bugs are bugs.) Since LIB$INITIALIZE is an "obvious" capability of the operating system, presumably GNAT for VMS either does the same obvious thing with LIB$INITIALIZE or does something different which also works, but at any rate does not ignore the issue. > C may well not be setting the stack and registers up to Ada's liking. Or > vica versa. This also should be a non-problem if the operating system (like VMS) mandates a calling standard. On less organized operating systems you may survive by buying all your compilers from the same source. Perhaps the main advantage of Ada95 is that it forces compiler developers to do the right thing, rather than trusting them :-). Larry Kilgallen ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP 1998-04-10 0:00 ` Urgent question: malloc and ada...READ/NEW/FOLLOWUP Larry Kilgallen @ 1998-04-12 0:00 ` Joe Gwinn 1998-04-14 0:00 ` Robert Dewar 0 siblings, 1 reply; 43+ messages in thread From: Joe Gwinn @ 1998-04-12 0:00 UTC (permalink / raw) In article <1998Apr10.073110.1@eisner>, Kilgallen@eisner.decus.org.nospam wrote: > In article <gwinn-0904982253200001@d183.dial-5.cmb.ma.ultra.net>, gwinn@ma.ultranet.com (Joe Gwinn) writes: > > > detail. It sounds like you are calling Ada from C; this is difficult to > > impossible with Ada83, and better with Ada95, but is often tricky. Ada83 > > really expected to be on top, to be the main(), and it was often easier to > > call C from an Ada main than to call Ada from a C main. > > Those limitations regarding which language was used for the main program > may be true for some particular Ada83 implementation with which you are > familiar, but they are not a characteristic of the Ada83 language itself. > One problem I have heard discussed here is "elaboration", and DEC Ada for > VMS has always done that via the LIB$INITIALIZE mechanism of the operating > system, without requiring the main program be written in Ada. (There was > a bug 10 years ago when sharable images (DLLs) were used, but bugs are bugs.) > Since LIB$INITIALIZE is an "obvious" capability of the operating system, > presumably GNAT for VMS either does the same obvious thing with LIB$INITIALIZE > or does something different which also works, but at any rate does not ignore > the issue. Even under VAX/VMS in the 1980s, it wasn't so easy to call Ada from C. I know because we did just that. There was a way to declare an Ada function as being called from non-Ada; this worked and we used it, but you lost much of the Ada environment. Actually, we were implementing an object-oriented communications system able to handle the full bandwidth of a large intelligence radar in Ada83 on VAX 8600s, and we used these non-Ada Ada functions as the OO methods, using a special assembly-coded invoker to call them by address (vice name). To get Ada83 and VMS to run that fast on the hardware of the day was quite the trick, requiring special kernel calls plus a shared-memory message passing infrastructure. DEC Ada83 didn't handle shared memory at all well, so we did an elaborate fan-dance so she never saw memory she didn't completely own - her eyes were covered whenever we needed to violate the closely-held assumptions of her upbringing. Sort of like when your mother covered your eyes so you wouldn't see something on the TV, because she didn't want to deal with the nightmares. Ada95 should allow one to do without such hacks, but it still isn't totally smooth, but the multiple-language problem isn't restricted to Ada, and never was. > > C may well not be setting the stack and registers up to Ada's liking. Or > > vica versa. > > This also should be a non-problem if the operating system (like VMS) mandates > a calling standard. On less organized operating systems you may survive > by buying all your compilers from the same source. Perhaps the main > advantage of Ada95 is that it forces compiler developers to do the right > thing, rather than trusting them :-). This was one clear advantage of VAX/VMS in its day, but few other vendors did any such thing. Under VMS, there was one common subroutine calling convention, so calling one language from another was much easier than normal. That said, we used to call all manner of languages one from another, sometimes directly, and sometimes by means of little assembly-coded wrappers ("bindings" in modern jargon), on all manner of computers. Ugly, but effective, so one didn't choose platforms just for the ability to call one language from another. Joe Gwinn ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP 1998-04-12 0:00 ` Joe Gwinn @ 1998-04-14 0:00 ` Robert Dewar 1998-04-16 0:00 ` Joe Gwinn 0 siblings, 1 reply; 43+ messages in thread From: Robert Dewar @ 1998-04-14 0:00 UTC (permalink / raw) iJoe said <<Ada95 should allow one to do without such hacks, but it still isn't totally smooth, but the multiple-language problem isn't restricted to Ada, and never was. >> Please give us some details as to what is not smooth. I find it hard to find any specific information in your message. What Ada 95 compiler have you used? What specific difficulties have you had in interfacing to other languages (in particular to C, Fortran or COBOL using the defined features in Ada 95). ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP 1998-04-14 0:00 ` Robert Dewar @ 1998-04-16 0:00 ` Joe Gwinn 1998-04-17 0:00 ` Robert Dewar 0 siblings, 1 reply; 43+ messages in thread From: Joe Gwinn @ 1998-04-16 0:00 UTC (permalink / raw) In article <dewar.892603771@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > Joe said > > <<Ada95 should allow one to do without such hacks, but it still isn't > totally smooth, but the multiple-language problem isn't restricted to Ada, > and never was. > >> > > Please give us some details as to what is not smooth. I find it hard to > find any specific information in your message. What Ada 95 compiler have > you used? What specific difficulties have you had in interfacing to other > languages (in particular to C, Fortran or COBOL using the defined features > in Ada 95). It's a lot of little things, too many to really list in any detail. Alignment and padding of and between various size fields is a big issue, especially if the processor hardware in the various participating machines have different data alignment requirements. All the gritty details needed to ensure that data structures defined in two unrelated languages and compilers are absolutely congruent, to the bit, always and forever. I have never seen any real pattern implicating any one language or compiler, although one's chances are better if all involved compilers came from one source, and simpler languages tend to cause less trouble. No high-order language really allows one to fully control the representation of complex data structures in memory, although some give it more lip service than others. Assembly code will never die; it may be ugly, but it always works, and it's unlikely to try to outsmart you. If you are trying to verify or improve GNAT's interface to C and/or UDP messages from other machines of different manufacture via communications, I would try to implement something that handles complex UDP messages sent between these three worlds, and see how it goes. I bet you will find lots to fix; we always do, but are forced to evade rather than really fix things, not having command of the Ada compiler. Then, when it all seems to work, add a field to the beginning of a message format, upgrade a compiler or two, and change a machine type or two. One thing that has improved noticably over the last decade is that hardware floating point formats are now pretty much standardized under IEEE Std 754. In the old days, you only rarely could afford to have floating point variables in messages sent between different kinds of machine as no two floating point formats were the same. Now, if the machines are of the same endian persuasion, 32-bit and 64-bit floats in messages work just fine. The other IEEE float formats aren't universally supported. Joe Gwinn ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP 1998-04-16 0:00 ` Joe Gwinn @ 1998-04-17 0:00 ` Robert Dewar 1998-04-18 0:00 ` Joe Gwinn 0 siblings, 1 reply; 43+ messages in thread From: Robert Dewar @ 1998-04-17 0:00 UTC (permalink / raw) Joe said <<It's a lot of little things, too many to really list in any detail. >> OK, so please list ONE specific case! We seem to get from you this general diatribe on how difficult things are, but it seems hard to get a specific example. In my experience many of the "problems" that people have are not language problems at all, but simply cases of people not knowing the language well enough. Yes, these features are quite tricky to learn, but if you want to be successful in using Ada 95 for handling low level interfacing, then you have to learn and understand the features in Ada 95 that accomplish this. So, please give ONE example from your "lot of little things", we will settle for not having the complete list if it is so long! ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP 1998-04-17 0:00 ` Robert Dewar @ 1998-04-18 0:00 ` Joe Gwinn 1998-04-18 0:00 ` Robert Dewar 0 siblings, 1 reply; 43+ messages in thread From: Joe Gwinn @ 1998-04-18 0:00 UTC (permalink / raw) In article <dewar.892815844@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > Joe said > > <<It's a lot of little things, too many to really list in any detail. > >> > > OK, so please list ONE specific case! We have lists. I'll see what I can publish when I return in a week. > We seem to get from you this general diatribe on how difficult things are, > but it seems hard to get a specific example. In my experience many of the > "problems" that people have are not language problems at all, but simply > cases of people not knowing the language well enough. Yes, these features > are quite tricky to learn, but if you want to be successful in using Ada 95 > for handling low level interfacing, then you have to learn and understand > the features in Ada 95 that accomplish this. Umm. Here we go again. No, not all developers have doctorates in anything, let alone computer science, but the problems of interfacing code written in different languages, or even same language but different compilers, have been with us for decades. This is an area where details are excruciatingly important. I am perplexed. Why do you think Ada, a capable but complex language, is any different? Why do you express surprise that people have problems here, and demand the evidence, as if to prepare for a federal court case? Also, I don't know that having the enitire list in detail would help people, because they will have a different combination of languages and compilers. What's more useful is the advice to focus on the interface details in your particular setup, because history has shown this area to be a rich source of trouble. > So, please give ONE example from your "lot of little things", we will settle > for not having the complete list if it is so long! I have to wonder if I will ever be able to provide enough details to satisfy you. Past history isn't encouraging. Joe Gwinn ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP 1998-04-18 0:00 ` Joe Gwinn @ 1998-04-18 0:00 ` Robert Dewar 1998-04-25 0:00 ` Joe Gwinn 0 siblings, 1 reply; 43+ messages in thread From: Robert Dewar @ 1998-04-18 0:00 UTC (permalink / raw) Joe says <<Umm. Here we go again. No, not all developers have doctorates in anything, let alone computer science, but the problems of interfacing code written in different languages, or even same language but different compilers, have been with us for decades. This is an area where details are excruciatingly important.>> The idea that you need a doctorate in computer science to understand a programming language like Ada is peculiar. I certainly have not found this a necessity myself! In fact anyone with a reasonable practical understanding of programming language semantics can perfectly well learn Ada in general, and these aspects in particular. I talk by email nearly every day to competent application programmers who have nothing like the formal credentials that Joe seems to imagine as necessary. Many of them understand these language aspects as well as I do. The idea that you need special qualification to do this is definitely odd and does not correspond to my experience at all. <<I am perplexed. Why do you think Ada, a capable but complex language, is any different? Why do you express surprise that people have problems here, and demand the evidence, as if to prepare for a federal court case?>> I don't know why you should be perplexed. Perhaps you simply don't know Ada 95 well enough to know that it is unique in being designed to interface with other languages. For example, there is no other language of which I am aware which has the capability of specifying that a particular type is to be represented in a manner compatible with some other specific language. It hardly needs a federal court case to be dissatisfied with your completely unsubstantiated claim of difficulties in Ada 95 without a single example. The reason an example is useful is we want to see whether it is genuinely a gap or problem in Ada 95, or whether it is a matter of you not knowing the language well enough (a possibility since you regard Ada as complex and impossible to learn without a PhD in computer science :-) <<Also, I don't know that having the enitire list in detail would help people, because they will have a different combination of languages and compilers. What's more useful is the advice to focus on the interface details in your particular setup, because history has shown this area to be a rich source of trouble.>> Absolutely, that is why the design of Ada 95 goes to such considerable extents to provide specific features to solve these problems. <<I have to wonder if I will ever be able to provide enough details to satisfy you. Past history isn't encouraging.>> I agree, it has been VERY hard to get you to discuss specific language issues in the past. You have always been more comfortable at the general "there are lots of problems, I know, I have been there" level. Fine, but that deadends the conversation if we don't have a specific example. So please contradict past history and cough up an example. Since you are now trying to find the single example that most supports your case from a supposedly long list, this should not be an unreasonable request! ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP 1998-04-18 0:00 ` Robert Dewar @ 1998-04-25 0:00 ` Joe Gwinn 1998-04-26 0:00 ` Robert Dewar 0 siblings, 1 reply; 43+ messages in thread From: Joe Gwinn @ 1998-04-25 0:00 UTC (permalink / raw) In article <dewar.892953117@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > Joe says > > <<Umm. Here we go again. No, not all developers have doctorates in > anything, let alone computer science, but the problems of interfacing code > written in different languages, or even same language but different > compilers, have been with us for decades. This is an area where details > are excruciatingly important.>> > > The idea that you need a doctorate in computer science to understand a > programming language like Ada is peculiar. I certainly have not found > this a necessity myself! In fact anyone with a reasonable practical > understanding of programming language semantics can perfectly well learn > Ada in general, and these aspects in particular. I talk by email nearly > every day to competent application programmers who have nothing like the > formal credentials that Joe seems to imagine as necessary. Many of them > understand these language aspects as well as I do. The idea that you > need special qualification to do this is definitely odd and does not > correspond to my experience at all. I guess I have yet to meet anybody who knows Ada well enough, and probably never will, but life goes on. > <<I am perplexed. Why do you think Ada, a capable but complex language, is > any different? Why do you express surprise that people have problems > here, and demand the evidence, as if to prepare for a federal court case?>> > > I don't know why you should be perplexed. Perhaps you simply don't know Ada 95 > well enough to know that it is unique in being designed to interface with other > languages. For example, there is no other language of which I am aware which > has the capability of specifying that a particular type is to be represented > in a manner compatible with some other specific language. You know, no language is perfect, not even Ada. Somehow, I doubt that a statement that people had lots of trouble interfacing C to fortran 77 would have been challenged. > It hardly needs a federal court case to be dissatisfied with your completely > unsubstantiated claim of difficulties in Ada 95 without a single example. > The reason an example is useful is we want to see whether it is genuinely > a gap or problem in Ada 95, or whether it is a matter of you not knowing > the language well enough (a possibility since you regard Ada as complex and > impossible to learn without a PhD in computer science :-) You know, just listening to the newsgroup traffic for a year would give one the idea that there might be an issue or two here. I recall lots of C/C++ to Ada interface questions. Do you think there might be a pattern in all those unsubstantiated postings? > <<Also, I don't know that having the entire list in detail would help > people, because they will have a different combination of languages and > compilers. What's more useful is the advice to focus on the interface > details in your particular setup, because history has shown this area to > be a rich source of trouble.>> > > Absolutely, that is why the design of Ada 95 goes to such considerable > extents to provide specific features to solve these problems. It takes two to tango. One could have the problem even if Ada were perfect in every way, which it's not, no more than any other language of similar complexity. Anyway, one has at least two languages involved in such interfaces. > <<I have to wonder if I will ever be able to provide enough details to > satisfy you. Past history isn't encouraging.>> > > I agree, it has been VERY hard to get you to discuss specific language > issues in the past. You have always been more comfortable at the general > "there are lots of problems, I know, I have been there" level. Fine, but > that deadends the conversation if we don't have a specific example. So > please contradict past history and cough up an example. Since you are now > trying to find the single example that most supports your case from a > supposedly long list, this should not be an unreasonable request! As I said, I will dig up a list, probably next week. It should by now be obvious that I am a system architect and manager, and no longer write much code, so I don't usually know the details of problems to the level I did when I wrote all the code, which seems to be the level you wish. Just because I report problems that others in my shop have experienced, and so do not myself know all details, does not mean that the problems didn't happen, or that they aren't serious. In fact, I only hear of the serious problems. Nor does it mean that certain patterns don't become obvious after decades in the business. It's time emough to see thinks rise up and then go to smoke and ashes a few times over. By the way, coders don't choose languages, managers do. Joe Gwinn ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP 1998-04-25 0:00 ` Joe Gwinn @ 1998-04-26 0:00 ` Robert Dewar 1998-04-26 0:00 ` Jonathan Guthrie 1998-05-01 0:00 ` Joe Gwinn 0 siblings, 2 replies; 43+ messages in thread From: Robert Dewar @ 1998-04-26 0:00 UTC (permalink / raw) Joe said <<I guess I have yet to meet anybody who knows Ada well enough, and probably never will, but life goes on.>> At the level we are talking about here, which is programmers who have a reasonable working understanding of the issues in interfacing to other languages, there are lots of Ada programmers who qualify. Indeed this is the kind of knowledge that every Ada programmer should have, and the great majority of Ada programmers are, in my experience, quite knowledgable in this area. I judge this from the kind of questions we get in our support activities. Sure there are some tricky points and good programmers are always working to improve their knowledge in all areas of the language. I suspect the fact that you can make this statement means you are trying to use Ada with insufficient expertise. Your continued problems in the interfacing area are additional evidence that this may be the case. Perhaps you should arrange for some appropriate training activities for your Ada programmers. We are not talking about needing a PhD in programming languages here, just the level of knowledge that any Ada programmer working on a serious Ada project should have. <<You know, no language is perfect, not even Ada. Somehow, I doubt that a statement that people had lots of trouble interfacing C to fortran 77 would have been challenged.>> Of course not, since neither C nor Fortran 77 have any provisions for interfacing to other languages, so it is indeed the case that there are problems in interfacing in a portable manner from C to Fortran 77. Note that problems in interfacing using other languages than Ada, languages that pay no attention to the difficult problems of interfacing, are unlikely to be indicative of the performance of Ada 95 in this area, a language which uniquely among commonly used languages *does* worry about the issue of interfacing to other languages. An interesting indication of this is that the validation suite for Ada contains C, Fortran, and COBOL code, to be used in tests of the interfacing capability. The interfacing tests involved here are 100% portable, and expected to run without modification to either the Ada or the C/Fortran/COBOL code in any tested environment supporting the relevant languages. <<It takes two to tango. One could have the problem even if Ada were perfect in every way, which it's not, no more than any other language of similar complexity. Anyway, one has at least two languages involved in such interfaces.>> This probably indicates a lack of knowledge about how Ada handles this problem (Joe indicates later that he is not familiar with the technical details). The approach in Ada is that the entire responsibility of correct interface is placed on the Ada compiler system. For example, when we write: type x is record a : Interfaces.C.int; b : Interfaces.C.char; end record; pragma Convention (C, x); the Ada compiler is responsible for laying out the type x identically to the corresponding C record in the particular environment in which the Ada compiler operates. Yes, this is a huge pain, but it is a pain for the Ada compiler implementor, who has to find out how to do this, *not* for the Ada programmer. <<It should by now be obvious that I am a system architect and manager, and no longer write much code, so I don't usually know the details of problems to the level I did when I wrote all the code, which seems to be the level you wish. Just because I report problems that others in my shop have experienced, and so do not myself know all details, does not mean that the problems didn't happen, or that they aren't serious. In fact, I only hear of the serious problems.>> The level at which I would like a report is indeed more detailed than your "we have problems" general claim. We want to see a specific instance of the kind of interfacing problems you are having to see which category it is in: 1. Lack of knowledge of Ada programmers involved 2. Incorrect Ada 95 implementation 3. Genuine problem in Ada 95 language definition You tend to assume 3, partly because of the strange logic that says "since I have had problems in the past with other languages, I am sure I will have problems with Ada 95 in the future." This is, as noted above, indeed strange logic, since one of the important design features in Ada 95 is precisely to recognize the kind of problems you have had in the past, and fix them. On one occasion in comp.lang.cobol, someone asked how to interface COBOL to C. This cannot be done portably in a direct manner, since neither C nor COBOL has anything to say about portable language interfacing, but I pointed out that an interesting and completely portable approach was to use an Ada 95 layer as glue, since Ada 95 can portably interface to both languages. I suspect 1 or perhaps 2 may be more likely to be the source of problems. <<By the way, coders don't choose languages, managers do.>> That's perfectly reasonable. Indeed "coders" often don't have the perspective to make a choice. What is important is that whoever makes the decision, no matter what their title be, have the kind of technical knowledge that is needed to make a sound decision. All too often managers don't know enough of the details to make sensible decisions. I have seen managers choose a programming language when they knew absolutely nothing about the language at all. By the way "coders" is a rather contemptous term for a manager to use. I trust you are not operating in an environment where you really have people coding who understand nothing in the programming process other than actual coding. That was a model used by many COBOL shops in the 60's and 70's (the very ones who give us the Y2K headaches today), and is largely discredited. Certainly in the kind of technical area for which Ada is used, I would look for programmers with excellent knowledge of both Ada and the entire programming process to be involved. <<You know, just listening to the newsgroup traffic for a year would give one the idea that there might be an issue or two here. I recall lots of C/C++ to Ada interface questions. Do you think there might be a pattern in all those unsubstantiated postings?>> I am always suspicious of people lumping C/C++ together in one breath as though they are one language. They are most definitely NOT one language. If you look at these posts, you will find the following clear pattern. In the case of C, the Ada 95 definition is adequate. The one remaining glitch of which I am aware, namely the issue of passing structs' by value (not such a common occurrence) is handled by the pragma C_Pass_By_Copy, implemented compatibly in GNAT and Intermetrics (i.e. including Green Hills). In the case of C++, no C++ standard was in effect at the time that Ada was standardized (indeed as I assume you know, the C++ standard is very recent). So there is no standardized method in the Ada 95 RM for interfacing directly to C++. In practice there is no problem because C and C++ can interoperate, and Ada and C can interoperate, so a portable solution can be created by using a C interface layer (this is the sort of knowledge that should be at hand in any work you do in this area). GNAT does provide a set of pragmas for direct interfacing to C++, but these are not a standard part of the language. The ARA technical committee has made some progress towards a common set of interfaces for C++, but this work is not yet complete. Quite a few of the posts you are talking about have to do with using these special GNAT features. This is an area that you cannot expect Ada programmers to be familiar with, and indeed we definitely spend time helping our supported customers use these GNAT-specific problems. But for most purposes the use of an intermediate C layer solves the problems. Whether this is true in your case (or whether your case involves C++ at all) remains to be seen pending some more technical details on the problems that you actually face. <<As I said, I will dig up a list, probably next week.>> We look forward to it. A list would be very instructive, but even ONE clear technical answer would help get this conversation out of the rather uninformative philosophical level onto a technical level. Robert Dewar ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP 1998-04-26 0:00 ` Robert Dewar @ 1998-04-26 0:00 ` Jonathan Guthrie 1998-04-26 0:00 ` Simon Wright ` (3 more replies) 1998-05-01 0:00 ` Joe Gwinn 1 sibling, 4 replies; 43+ messages in thread From: Jonathan Guthrie @ 1998-04-26 0:00 UTC (permalink / raw) In comp.lang.ada Robert Dewar <dewar@merv.cs.nyu.edu> wrote: > This probably indicates a lack of knowledge about how Ada handles this problem > (Joe indicates later that he is not familiar with the technical details). The > approach in Ada is that the entire responsibility of correct interface is > placed on the Ada compiler system. For example, when we write: > type x is record > a : Interfaces.C.int; > b : Interfaces.C.char; > end record; > pragma Convention (C, x); > the Ada compiler is responsible for laying out the type x identically to the > corresponding C record in the particular environment in which the Ada > compiler operates. How does the Ada compiler implemetor know what C compiler is used in that "particular environment in which the compiler operates"? Telepathy? I realize that, in the case of GNAT, (you assume) that compiler is going to be GCC and that the way that code is generated by that compiler is necessarily well understood by the GNAT team, but that information simply isn't available to the implementor in the general case. In fact, for those situations where the foreign language facility is most useful (that is, you have to use a pre-built library that somebody got from somewhere) the use of the foreign language facility may require information (what compiler options/pragmas were used) that is unavailable by any means. In particular, what happens if they're using GNAT under Linux and some C compiler other than GCC that organizes things differently than GCC does? I suspect that the case isn't handled particularly well. (Don't believe that such compilers exist? Well, as it happens I feel like writing a C compiler today...B-)) Or do you have pragma's for specifying which C compiler you need to interface with? (If that's true, how do you pass the validation suite without changing the pragma?) Note that I am not claiming this to be a deficiency in the Ada language specification. I believe that the problem simply isn't solvable in the general case. (Well, it IS solvable, but the effort isn't anything like worthwhile. I would expect that you have to provide a mechanism to allow the programmer to specify the layouts of structs, arrays, and so forth. Since figuring out the way things are laid out is the hard part, why bother?) Just out of curiousity, how DO you handle "pragma pack"? Do you provide equivalent pragmas for all the possible cases? -- Jonathan Guthrie (jguthrie@brokersys.com) Information Broker Systems +281-895-8101 http://www.brokersys.com/ 12703 Veterans Memorial #106, Houston, TX 77014, USA We sell Internet access and commercial Web space. We also are general network consultants in the greater Houston area. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP 1998-04-26 0:00 ` Jonathan Guthrie @ 1998-04-26 0:00 ` Simon Wright 1998-04-26 0:00 ` Larry Kilgallen 1998-04-26 0:00 ` Robert Dewar ` (2 subsequent siblings) 3 siblings, 1 reply; 43+ messages in thread From: Simon Wright @ 1998-04-26 0:00 UTC (permalink / raw) Jonathan Guthrie <jguthrie@brokersys.com> writes: > How does the Ada compiler implemetor know what C compiler is used in > that "particular environment in which the compiler operates"? > Telepathy? Well, one solution would be for the Ada vendor to specify it! In fact, given the need to match the C representations, I think the Ada vendor would have to. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP 1998-04-26 0:00 ` Simon Wright @ 1998-04-26 0:00 ` Larry Kilgallen 1998-04-27 0:00 ` Stephen Leake 0 siblings, 1 reply; 43+ messages in thread From: Larry Kilgallen @ 1998-04-26 0:00 UTC (permalink / raw) In article <x7vson01poa.fsf@pogner.demon.co.uk>, Simon Wright <simon@pogner.demon.co.uk> writes: > Jonathan Guthrie <jguthrie@brokersys.com> writes: > >> How does the Ada compiler implemetor know what C compiler is used in >> that "particular environment in which the compiler operates"? >> Telepathy? > > Well, one solution would be for the Ada vendor to specify it! In fact, > given the need to match the C representations, I think the Ada vendor > would have to. And, depending on the compiler one might have to specify particular compilation modes for which the alignment characteristics will be matched. I don't remember the details, but DEC C for Alpha allows one to generate code which naturally aligns elements on quadword boundaries or longword boundaries, depending on application needs. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP 1998-04-26 0:00 ` Larry Kilgallen @ 1998-04-27 0:00 ` Stephen Leake 0 siblings, 0 replies; 43+ messages in thread From: Stephen Leake @ 1998-04-27 0:00 UTC (permalink / raw) Larry Kilgallen wrote: > > In article <x7vson01poa.fsf@pogner.demon.co.uk>, Simon Wright <simon@pogner.demon.co.uk> writes: > > Jonathan Guthrie <jguthrie@brokersys.com> writes: > > > >> How does the Ada compiler implemetor know what C compiler is used in > >> that "particular environment in which the compiler operates"? > >> Telepathy? > > > > Well, one solution would be for the Ada vendor to specify it! In fact, > > given the need to match the C representations, I think the Ada vendor > > would have to. > > And, depending on the compiler one might have to specify particular > compilation modes for which the alignment characteristics will be > matched. I don't remember the details, but DEC C for Alpha allows > one to generate code which naturally aligns elements on quadword > boundaries or longword boundaries, depending on application needs. Borland C on Windows/Intel has a similar option, and it bit me once. I compiled my code with longword alignment (for floating point speed), but the Borland libraries were compiled with byte alignment. Bingo; system crash. So you don't even need inter-language complications to get bugs like this! It would be nice if the object files included this kind of information, so it could be checked at link time; anyone know if any object formats do? On the original topic, the Ada vendor must specify which C compiler(s) they support on the target of interest. This was true for Ada 83, and is still true for Ada 95. On the other hand, most CPUs I've used have a standard calling convention, so there isn't that much variation between compilers. Intel seems to be an exception; are there really other CPUs that have incompatible C compilers? -- Stephe ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP 1998-04-26 0:00 ` Jonathan Guthrie 1998-04-26 0:00 ` Simon Wright @ 1998-04-26 0:00 ` Robert Dewar 1998-04-30 0:00 ` Robert I. Eachus 1998-05-01 0:00 ` Urgent question: malloc and ada...READ/NEW/FOLLOWUP Fergus Henderson 3 siblings, 0 replies; 43+ messages in thread From: Robert Dewar @ 1998-04-26 0:00 UTC (permalink / raw) Jonathan says <<How does the Ada compiler implemetor know what C compiler is used in that "particular environment in which the compiler operates"? Telepathy? I realize that, in the case of GNAT, (you assume) that compiler is going to be GCC and that the way that code is generated by that compiler is necessarily well understood by the GNAT team, but that information simply isn't available to the implementor in the general case. >> First of all, multiple C compilers per se is not a problem unless they use incompatible data layouts or calling sequences. On most machines the data layout and calling sequence is pretty much fixed, with more or less official help from the official ABI. If there is more than one C compiler, then the Ada compiler implementor is expected to either specify what particular C compiler is to be used or to provide multiple possible selections (e.g. by using diffent convention names, as perhaps in pragma Convention (Borland_C, ...); In practice this has not proved necessary in any environment we have seen. You make an assumption in the quoted paragraph above which is quite incorrect, namely that GNAT is tailored to what GCC does. This is the wrong way of looking at things. In fact GNU C (that's actually what you really mean by GCC here) goes to great efforts to be 100% compatible in data layouts and calling sequences with whatever is the "standard" C compiler in a given environment. Indeed it is regarded as a bug if GNU C is not 100% compatible with the "standard" vendor compiler. Thus the right way to look at things is that both GNU C, and GNAT (with respect to pragma Convention C) make sure to be compatible with the standard C compiler conventions. As to the information not being available to the implementor, it can indeed be tricky to find out what needs to be known, but it is not as difficult as you might think, since on many machines the official ABI settles many problems. In the case of GNU C, bug reports over the years have corrected all the remaining minor discrepancies that have been discovered (remember I said it was considered a bug if there are any discrepancies). This indeed means that a lot of the critical work was already in place to meet the GNAT requirement, but the requirement for GNAT is very definitely that it must be compatible with the standard vendor C compiler (as well as GNU C). ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP 1998-04-26 0:00 ` Jonathan Guthrie 1998-04-26 0:00 ` Simon Wright 1998-04-26 0:00 ` Robert Dewar @ 1998-04-30 0:00 ` Robert I. Eachus 1998-04-30 0:00 ` Urgent question: malloc and ada Larry Kilgallen 1998-05-01 0:00 ` Urgent question: malloc and ada...READ/NEW/FOLLOWUP Fergus Henderson 3 siblings, 1 reply; 43+ messages in thread From: Robert I. Eachus @ 1998-04-30 0:00 UTC (permalink / raw) In article <6hvm8k$t3l$1@news.hal-pc.org> Jonathan Guthrie <jguthrie@brokersys.com> writes: > How does the Ada compiler implemetor know what C compiler is used in > that "particular environment in which the compiler operates"? > Telepathy? No, by the name used in the pragma. The conventions Ada, Intrinsic, Fortran, C, and COBOL are defined in the RM, as are the packages Interfaces.C, Interfaces.COBOL, and Interfaces.Fortran. Compilers are allowed to add support for other languages, and in the particular case mentioned above, they would choose one C compiler to correspond to the convention C, and others could be named Gcc, VisualC, etc. In practice, the compiler that corresponds to C is the one used to compile the OS. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada... 1998-04-30 0:00 ` Robert I. Eachus @ 1998-04-30 0:00 ` Larry Kilgallen 1998-05-01 0:00 ` Robert Dewar [not found] ` <matthew_heaney-ya023680003004981723000001@news.ni.net> 0 siblings, 2 replies; 43+ messages in thread From: Larry Kilgallen @ 1998-04-30 0:00 UTC (permalink / raw) In article <EACHUS.98Apr30171942@spectre.mitre.org>, eachus@spectre.mitre.org (Robert I. Eachus) writes: > No, by the name used in the pragma. The conventions Ada, Intrinsic, > Fortran, C, and COBOL are defined in the RM, as are the packages > Interfaces.C, Interfaces.COBOL, and Interfaces.Fortran. Compilers are > allowed to add support for other languages, and in the particular case > mentioned above, they would choose one C compiler to correspond to the > convention C, and others could be named Gcc, VisualC, etc. In practice, > the compiler that corresponds to C is the one used to compile the OS. I find it strange that even in comp.lang.ada a distinguished contributor would express the assumption that the operating system was written in C. Larry Kilgallen ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada... 1998-04-30 0:00 ` Urgent question: malloc and ada Larry Kilgallen @ 1998-05-01 0:00 ` Robert Dewar 1998-05-01 0:00 ` Charles Hixson ` (2 more replies) [not found] ` <matthew_heaney-ya023680003004981723000001@news.ni.net> 1 sibling, 3 replies; 43+ messages in thread From: Robert Dewar @ 1998-05-01 0:00 UTC (permalink / raw) Larry said <<I find it strange that even in comp.lang.ada a distinguished contributor would express the assumption that the operating system was written in C. >> Perhaps that is because the distinguished contributor lives in the real world, and not a wishful-thinking world! In practice the definition expressed here is a useful one, since of course it is almost always the case that the operating system involved will have substantial chunks written in C (probably it won't be 100% C, there will be C++, and perhaps assembly .....) It would be a nice excercise to rewrite the Linux kernel in Ada, and indeed the comparison of the effort involved, and the final results would make an interesting student research paper. This is by no means an out of scope effort. The core of the kernel is not a gigantic program. But until such a thing is done, I am afraid that Larry will continue to find the real world strange :-) ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada... 1998-05-01 0:00 ` Robert Dewar @ 1998-05-01 0:00 ` Charles Hixson 1998-05-02 0:00 ` Jonathan Guthrie 1998-05-02 0:00 ` Corey Minyard 1998-05-06 0:00 ` Robert I. Eachus 2 siblings, 1 reply; 43+ messages in thread From: Charles Hixson @ 1998-05-01 0:00 UTC (permalink / raw) To: Robert Dewar Actually, if someone were to rewrite the Linux kernel in Ada, it might be VERY useful. Ada is supposed to catch errors MUCH more readily, and an OS without internal errors would be extremely popular (at least with some people [like me]). I haven't checked the actual scope of the proposal, but if Linux were being maintained in Ada rather than in C, there would be a large increase in the number of interested (in Ada) people. Robert Dewar wrote: > > Larry said > > <<I find it strange that even in comp.lang.ada a distinguished contributor > would express the assumption that the operating system was written in C. > >> > > Perhaps that is because the distinguished contributor lives in the real > world, and not a wishful-thinking world! In practice the definition > expressed here is a useful one, since of course it is almost always > the case that the operating system involved will have substantial > chunks written in C (probably it won't be 100% C, there will be C++, > and perhaps assembly .....) > > It would be a nice excercise to rewrite the Linux kernel in Ada, and indeed > the comparison of the effort involved, and the final results would make > an interesting student research paper. This is by no means an out of scope > effort. The core of the kernel is not a gigantic program. > > But until such a thing is done, I am afraid that Larry will continue > to find the real world strange :-) -- Charles Hixson charleshixson@earthling.net (510) 464-7733 or chixso@mtc.dst.ca.us ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada... 1998-05-01 0:00 ` Charles Hixson @ 1998-05-02 0:00 ` Jonathan Guthrie 0 siblings, 0 replies; 43+ messages in thread From: Jonathan Guthrie @ 1998-05-02 0:00 UTC (permalink / raw) In comp.lang.ada Charles Hixson <charleshixson@earthling.net> wrote: > Actually, if someone were to rewrite the Linux kernel in Ada, it might > be VERY useful. Ada is supposed to catch errors MUCH more readily, and > an OS without internal errors would be extremely popular (at least with > some people [like me]). Ada might catch some errors more readily than C, but that doesn't necessarily translate into a kernel that works better if it's coded in Ada than if it's coded in C. As I pointed out in a previous message, my experience is that most errors that I make aren't those that can be found by the compiler. I would, however, like to switch to only languages that do GC internally. I do run into memory leaks and it's a pain managimng my own memory. For what it's worth, I have found the Linux kernel to be quite stable and reliable. (I wish I could say the same about sendmail and net3.) > I haven't checked the actual scope of the proposal, but if Linux were > being maintained in Ada rather than in C, there would be a large > increase in the number of interested (in Ada) people. Do I hear a volunteer? Of course, you won't get the "real" Linux converted to Ada until you convert Linus, but there's nothing stopping you from doing it to turn yourself into a building. If you restrict yourself to only those drivers you're interested in, it isn't even that big a job. Myself, if I were going to try to organize a net.project to promote Ada, it would be a RADIUS daemon. I happen to need a modular RADIUS daemon. While I'm on the subject, I've been reading this NG for a while because I've been interested in learning Ada. The only book I have is INTRODUCTION TO PROGRAMMING USING ADA by Dennis Volper and Martin D. Katz. (I got it from a publisher's overstock bookstore for $3.) This book seems to match my approach to learning new languages, but it has two problems: It's based on Ada 8x, and its exercises assume the availability of a library I don't have. I don't know where I could get the library, (it doesn't appear to be available except from the author, bummer) and I'd like to get a Ada 95 book, but I don't want to go out and blow $70 on a stinker. (As the saying goes, been there, done that.) If anyone feels the urge to send suggestions, by all means. (I've got the FAQ, so there's no need to send me that.) -- Jonathan Guthrie (jguthrie@brokersys.com) Information Broker Systems +281-895-8101 http://www.brokersys.com/ 12703 Veterans Memorial #106, Houston, TX 77014, USA We sell Internet access and commercial Web space. We also are general network consultants in the greater Houston area. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada... 1998-05-01 0:00 ` Robert Dewar 1998-05-01 0:00 ` Charles Hixson @ 1998-05-02 0:00 ` Corey Minyard 1998-05-06 0:00 ` Robert I. Eachus 2 siblings, 0 replies; 43+ messages in thread From: Corey Minyard @ 1998-05-02 0:00 UTC (permalink / raw) dewar@merv.cs.nyu.edu (Robert Dewar) writes: > > Perhaps that is because the distinguished contributor lives in the real > world, and not a wishful-thinking world! In practice the definition > expressed here is a useful one, since of course it is almost always > the case that the operating system involved will have substantial > chunks written in C (probably it won't be 100% C, there will be C++, > and perhaps assembly .....) The Linux kernel is almost all C with some assembly (mostly in inline asm statements, startup code, and kernel trap code). Linus tried to convert to compiling with C++, but he got so much flak he changed it back. For real-time Linux, there is some support for loading C++ modules. > > It would be a nice excercise to rewrite the Linux kernel in Ada, and indeed > the comparison of the effort involved, and the final results would make > an interesting student research paper. This is by no means an out of scope > effort. The core of the kernel is not a gigantic program. The core of the kernel is not itself gigantic, but add networking code and device drivers and it gets pretty big. The Linux 2.1.98 sources are about 11MB compressed. It would be a big job to rewrite the whole thing. Although we can always hope :-). In reality, the Linux kernel is finely tuned and very robust; so much optimization effort has gone into it that reproducing it in Ada would likely produce bad results that would make Ada look bad. It would be nice to be able to support Ada for real-time Linux modules, though. Maybe someday I'll look at that... -- Corey Minyard Internet: minyard@acm.org Work: minyard@nortel.ca UUCP: minyard@wf-rch.cirr.com ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada... 1998-05-01 0:00 ` Robert Dewar 1998-05-01 0:00 ` Charles Hixson 1998-05-02 0:00 ` Corey Minyard @ 1998-05-06 0:00 ` Robert I. Eachus 1998-05-12 0:00 ` Craig T. Spannring 2 siblings, 1 reply; 43+ messages in thread From: Robert I. Eachus @ 1998-05-06 0:00 UTC (permalink / raw) In article <dewar.894029184@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes: > Perhaps that is because the distinguished contributor lives in the real > world, and not a wishful-thinking world! In practice the definition > expressed here is a useful one, since of course it is almost always > the case that the operating system involved will have substantial > chunks written in C (probably it won't be 100% C, there will be C++, > and perhaps assembly .....) Nice to be referred to as "the distinguished contributor," But note, that in the real world I live in, I have worked on operating systems written for the most part in PL/I (Stratus VOS and Multics), and Assembler. But I have never worked on an OS written in C. (Worked on in the sense of "wrote or maintained part of the OS.") However, any modern expert who writes an operating system is going to use a C compiler for some purposes, such as device drivers. If nothing else there will be a "least common denominator" call interface to the OS that is expressed in C. That is the C compiler I had in mind, the one used to define the OS call interface. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada... 1998-05-06 0:00 ` Robert I. Eachus @ 1998-05-12 0:00 ` Craig T. Spannring 1998-05-12 0:00 ` Robert Dewar 0 siblings, 1 reply; 43+ messages in thread From: Craig T. Spannring @ 1998-05-12 0:00 UTC (permalink / raw) In article <EACHUS.98May6153727@spectre.mitre.org>, Robert I. Eachus <eachus@spectre.mitre.org> wrote: >In article <dewar.894029184@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes: > > Nice to be referred to as "the distinguished contributor," But >note, that in the real world I live in, I have worked on operating >systems written for the most part in PL/I (Stratus VOS and Multics), >and Assembler. But I have never worked on an OS written in C. >(Worked on in the sense of "wrote or maintained part of the OS.") >However, any modern expert who writes an operating system is going to >use a C compiler for some purposes, such as device drivers. If >nothing else there will be a "least common denominator" call interface >to the OS that is expressed in C. That is the C compiler I had in >mind, the one used to define the OS call interface. I'm a bit confused as to why you would say that any OS expert would use C for some purposes. My experiences with various operating systems has been that the OS's implementation language leaks up through the API's. Calling system functions in C on the Stratus made it clear that VOS was written in PL/I. Calling system functions in AmigaDOS made it clear that the OS was a BCPL program. Windows seems like a mix between Pascal and C. Unix is obviously written in C. I believe that C/C++ makes it more difficult to write robust code than languages such as Ada and Modula-2. (Please, no 'my language i s better than your language' debates. Been there, done that. I just find them boring now.) If a company with deep pockets and a vertical market were to start building a new machine with that premise that writing applications in C is unnecessarily difficult and they have a goal of making applications easy to write it seems logical that they would want to distance the application programmer as far from C as possible. Having no C in the OS is as far as possible. If you tried to limit your use of C to just the device drivers then you would just introduce large amounts of tedious details to manage in the interface between the device drivers and the rest of the OS. As far as defining the OS call interface with C, this seems like a very poor idea. The C compiler can make arbitrary and capricious choices on how it lays out data structures in memory. The C standard makes no indications of how a structure is laid out. BTW- Anyone that had a hand in VOS has to qualify as "distinguished". ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada... 1998-05-12 0:00 ` Craig T. Spannring @ 1998-05-12 0:00 ` Robert Dewar 0 siblings, 0 replies; 43+ messages in thread From: Robert Dewar @ 1998-05-12 0:00 UTC (permalink / raw) Craig says <<As far as defining the OS call interface with C, this seems like a very poor idea. The C compiler can make arbitrary and capricious choices on how it lays out data structures in memory. The C standard makes no indications of how a structure is laid out. >> The C standard goes as far as it possibly could in defining how data structures are laid out by default. No other language standard could say more unless it restricted itself to a subset of available architectures. As for the statement that any OS is likely to contain some C code at this stage, that is simply an empirical observation, not a moral judgment! ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <matthew_heaney-ya023680003004981723000001@news.ni.net>]
* Re: Urgent question: malloc and ada... [not found] ` <matthew_heaney-ya023680003004981723000001@news.ni.net> @ 1998-05-01 0:00 ` Robert Dewar 1998-05-01 0:00 ` Larry Kilgallen 0 siblings, 1 reply; 43+ messages in thread From: Robert Dewar @ 1998-05-01 0:00 UTC (permalink / raw) <<You mean there's a pragma Convention for BLISS? >> Well certainly there is in GNAT! And of course it is perfectly reasonable in a VMS environment, where indeed there is quite a bit of BLISS around (even in the operating system :-) ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada... 1998-05-01 0:00 ` Robert Dewar @ 1998-05-01 0:00 ` Larry Kilgallen 1998-05-02 0:00 ` Robert Dewar 0 siblings, 1 reply; 43+ messages in thread From: Larry Kilgallen @ 1998-05-01 0:00 UTC (permalink / raw) In article <dewar.894029393@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes: > <<You mean there's a pragma Convention for BLISS? >>> > > Well certainly there is in GNAT! And of course it is perfectly reasonable > in a VMS environment, where indeed there is quite a bit of BLISS around > (even in the operating system :-) Certainly more than C. On Alpha only, C is being used for some of the innards, particular for brand new modules. As far as _calls_ to the operating system are concerned, however, the System Service Dispatcher is written in VAX assembly language, on both VAX and Alpha, so that is the language to which one interfaces system service calls. Since there is a tight calling standard, however, it really does not cause trouble. I find it hard to understand the tower of babble some other operating systems have constructed through a lack of system-specific standards. Larry Kilgallen ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada... 1998-05-01 0:00 ` Larry Kilgallen @ 1998-05-02 0:00 ` Robert Dewar 1998-05-02 0:00 ` Jonathan Guthrie 1998-05-03 0:00 ` Larry Kilgallen 0 siblings, 2 replies; 43+ messages in thread From: Robert Dewar @ 1998-05-02 0:00 UTC (permalink / raw) Larry said <<Certainly more than C. On Alpha only, C is being used for some of the innards, particular for brand new modules. As far as _calls_ to the operating system are concerned, however, the System Service Dispatcher is written in VAX assembly language, on both VAX and Alpha, so that is the language to which one interfaces system service calls. Since there is a tight calling standard, however, it really does not cause trouble. I find it hard to understand the tower of babble some other operating systems have constructed through a lack of system-specific standards. >> Note here that Larry is agreeing with the proposed criterion for defining the standard C compiler *even* in the case of VMS, which is the one case in which you might have thought that C was not used in the operating system. So, just to recapture the interesting point (I forget who made it). The proposal is that in practice, a working definition of what the standard C compiler means is that it is the C compiler used for wrting the operating system. However, I don't see any analogous way of getting a feel for what the standard Fortran or COBOL compiler may be, and here you definitely need to find out from the vendor which Fortran compiler(s) or COBOL compiler(s) their Ada compiler interfaces to. Of course, as noted elsewhere in this thread, it is perfectly reasonable (and indeed expected) for an Ada compiler to have multiple calling conventions if there are incompatible other-language compilers. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada... 1998-05-02 0:00 ` Robert Dewar @ 1998-05-02 0:00 ` Jonathan Guthrie 1998-05-03 0:00 ` Robert Dewar 1998-05-03 0:00 ` Richard Kenner 1998-05-03 0:00 ` Larry Kilgallen 1 sibling, 2 replies; 43+ messages in thread From: Jonathan Guthrie @ 1998-05-02 0:00 UTC (permalink / raw) In comp.lang.ada Robert Dewar <dewar@merv.cs.nyu.edu> wrote: > Of course, as noted elsewhere in this thread, it is perfectly reasonable > (and indeed expected) for an Ada compiler to have multiple calling > conventions if there are incompatible other-language compilers. Actually, I was commenting more on the alignment of structs (which, as far as I know, can vary even on those systems with a single calling convention) than the calling convention. Calling conventions are usually reasonably well standardized, the alignment of structs is not. Yet your post implied that both are covered (as they would have to be) by the requirements. -- Jonathan Guthrie (jguthrie@brokersys.com) Information Broker Systems +281-895-8101 http://www.brokersys.com/ 12703 Veterans Memorial #106, Houston, TX 77014, USA We sell Internet access and commercial Web space. We also are general network consultants in the greater Houston area. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada... 1998-05-02 0:00 ` Jonathan Guthrie @ 1998-05-03 0:00 ` Robert Dewar 1998-05-03 0:00 ` Richard Kenner 1 sibling, 0 replies; 43+ messages in thread From: Robert Dewar @ 1998-05-03 0:00 UTC (permalink / raw) Jonathan says <<Actually, I was commenting more on the alignment of structs (which, as far as I know, can vary even on those systems with a single calling convention) than the calling convention. Calling conventions are usually reasonably well standardized, the alignment of structs is not. Yet your post implied that both are covered (as they would have to be) by the requirements. >> I was using calling sequence quite generally here. The alignment of structs is most CERTAINLY included, since part of what one does on a call is to pass references to various kinds of data, and of course the alignment and layout of this data must be clearly understood between callee and caller. So most definitely the convention in the ADa sense *does* cover alignment of structs. If two compilers differed in this respect, and an Ada compiler wished to interface to both, then it would have to provide for this, either by using separate calling conventions, or by using special pragmas. THe use of separate calling conventions is preferable, since it avoids the use of potentially non-portable pragmas. We still have not managed to coax out of Joe even one example of problems in interfacing in a portable manner, but clearly if this is a goal (and it was indeed a goal of the Ada 95 design), then it is better to stick to the mechanisms provided in the RM. We deviated from this in GNAT/VMS (providing the pragma Component_Alignment) since in this case, compatibility with DEC Ada 83 is much more of an issue than compatibility with other Ada 95 compilers, and indeed one would expect other Ada 985 compilers for VMS to be driven by the same considerations in any case. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada... 1998-05-02 0:00 ` Jonathan Guthrie 1998-05-03 0:00 ` Robert Dewar @ 1998-05-03 0:00 ` Richard Kenner 1998-05-03 0:00 ` Jonathan Guthrie 1 sibling, 1 reply; 43+ messages in thread From: Richard Kenner @ 1998-05-03 0:00 UTC (permalink / raw) In article <6ifdou$io3$1@news.hal-pc.org> Jonathan Guthrie <jguthrie@brokersys.com> writes: >Actually, I was commenting more on the alignment of structs (which, as >far as I know, can vary even on those systems with a single calling >convention) than the calling convention. Calling conventions are usually >reasonably well standardized, the alignment of structs is not. Yet your >post implied that both are covered (as they would have to be) by the >requirements. On most modern systems, details of how structures are supposed to be aligned are discussed in the same document that discusses the calling sequence. On older systems, there is often *no* documentation on this and so the appropriate thing to do is to follow whatever the specific compiler being interfaced with does, just like you would do with calling conventions. I see no difference between the two issues. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada... 1998-05-03 0:00 ` Richard Kenner @ 1998-05-03 0:00 ` Jonathan Guthrie 1998-05-03 0:00 ` Richard Kenner 1998-05-03 0:00 ` Robert Dewar 0 siblings, 2 replies; 43+ messages in thread From: Jonathan Guthrie @ 1998-05-03 0:00 UTC (permalink / raw) In comp.lang.ada Richard Kenner <kenner@lab.ultra.nyu.edu> wrote: > >Actually, I was commenting more on the alignment of structs (which, as > >far as I know, can vary even on those systems with a single calling > >convention) than the calling convention. Calling conventions are usually > >reasonably well standardized, the alignment of structs is not. Yet your > >post implied that both are covered (as they would have to be) by the > >requirements. > On most modern systems, details of how structures are supposed to be aligned > are discussed in the same document that discusses the calling sequence. <snippage> > I see no difference between the two issues. On many systems, the calling convention is carved in stone. Unfortunately, on every C compiler that I know well, it is possible to adjust the alignment of the fields in structs on a case-by-case basis. Those alignments do not have to correspond to any system convention or even make any sense. Of course, most of the compilers I know well are for Intel processors, but it's in the GCC documentation. In fact GNU C allows a lot more leeway in how you specify the alignment of the fields in a struct than the MS-DOS/Windows compilers I've used. I, for one, am a lot more likely to muck about with the struct alignment than I am to attempt to change the calling convention. In any case, that sounds pretty different to me. The statement has been made that the Ada compiler is required to deal with all the complexities of the Ada/C interface, I'm just trying to probe the limits and find out what they are. -- Jonathan Guthrie (jguthrie@brokersys.com) Information Broker Systems +281-895-8101 http://www.brokersys.com/ 12703 Veterans Memorial #106, Houston, TX 77014, USA We sell Internet access and commercial Web space. We also are general network consultants in the greater Houston area. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada... 1998-05-03 0:00 ` Jonathan Guthrie @ 1998-05-03 0:00 ` Richard Kenner 1998-05-03 0:00 ` Robert Dewar 1 sibling, 0 replies; 43+ messages in thread From: Richard Kenner @ 1998-05-03 0:00 UTC (permalink / raw) In article <6ihtmc$nf9$1@news.hal-pc.org> Jonathan Guthrie <jguthrie@brokersys.com> writes: >Unfortunately, on every C compiler that I know well, it is possible to >adjust the alignment of the fields in structs on a case-by-case basis. >Those alignments do not have to correspond to any system convention or even >make any sense. Right, but the same is true for Ada. If you are overriding the defaults in a structure layout, you do so the same way for C and Ada and need not bother with Convention, which basically tells the compiler what to do *by default*. >In any case, that sounds pretty different to me. The statement has been >made that the Ada compiler is required to deal with all the complexities >of the Ada/C interface, I'm just trying to probe the limits and find out >what they are. But when you explicitly specify a layout on either side, you are no longer taking about the Ada/C interface. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada... 1998-05-03 0:00 ` Jonathan Guthrie 1998-05-03 0:00 ` Richard Kenner @ 1998-05-03 0:00 ` Robert Dewar 1 sibling, 0 replies; 43+ messages in thread From: Robert Dewar @ 1998-05-03 0:00 UTC (permalink / raw) Jonathan said <<On many systems, the calling convention is carved in stone. Unfortunately, on every C compiler that I know well, it is possible to adjust the alignment of the fields in structs on a case-by-case basis. Those alignments do not have to correspond to any system convention or even make any sense. Of course, most of the compilers I know well are for Intel processors, but it's in the GCC documentation. In fact GNU C allows a lot more leeway in how you specify the alignment of the fields in a struct than the MS-DOS/Windows compilers I've used. >> Following up on my previous message .... the above makes no sense. The calling sequence includes the specifications for how structs are passed by reference, and thus how they are layed out and aligned. A calling sequence that is "carved in stone" must include these issues in the carving! Obviously if you use other than the default layout, by the use of the equiavelnt of pragmas or rep clauses, then no Ada compiler can telephaythically guess what you have done. However, every Ada compiler wlil implement sufficient flexibility so that you can use analogous statements in your Ada program to align and lay out your data in a compatible manner. Jonathan, I don't see any problem here at all. If you see one, let me make the same request I make of Joe, please give us an example of what you think is a problem case. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada... 1998-05-02 0:00 ` Robert Dewar 1998-05-02 0:00 ` Jonathan Guthrie @ 1998-05-03 0:00 ` Larry Kilgallen 1 sibling, 0 replies; 43+ messages in thread From: Larry Kilgallen @ 1998-05-03 0:00 UTC (permalink / raw) In article <dewar.894114612@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes: > Larry said > > <<Certainly more than C. On Alpha only, C is being used for some of the > innards, particular for brand new modules. As far as _calls_ to the > operating system are concerned, however, the System Service Dispatcher > is written in VAX assembly language, on both VAX and Alpha, so that is > the language to which one interfaces system service calls. Since there > is a tight calling standard, however, it really does not cause trouble. > I find it hard to understand the tower of babble some other operating > systems have constructed through a lack of system-specific standards. >>> > > > Note here that Larry is agreeing with the proposed criterion for defining > the standard C compiler *even* in the case of VMS, which is the one case > in which you might have thought that C was not used in the operating system. Not exactly, since in the case of VAX/VMS _no_ C compiler is used in the operating system. > So, just to recapture the interesting point (I forget who made it). The > proposal is that in practice, a working definition of what the standard > C compiler means is that it is the C compiler used for wrting the operating > system. Certainly "the standard C compiler endorsed by the manufacturer of the operating system" makes sense, because DEC sells a C compiler to use with VAX/VMS, even if they don't use it in the writing of the operating system. > However, I don't see any analogous way of getting a feel for what the > standard Fortran or COBOL compiler may be, and here you definitely need > to find out from the vendor which Fortran compiler(s) or COBOL compiler(s) > their Ada compiler interfaces to. That "endorsement" wording should work for Fortran and COBOL in a lot of cases. Larry Kilgallen ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP 1998-04-26 0:00 ` Jonathan Guthrie ` (2 preceding siblings ...) 1998-04-30 0:00 ` Robert I. Eachus @ 1998-05-01 0:00 ` Fergus Henderson 3 siblings, 0 replies; 43+ messages in thread From: Fergus Henderson @ 1998-05-01 0:00 UTC (permalink / raw) eachus@spectre.mitre.org (Robert I. Eachus) writes: >In article <6hvm8k$t3l$1@news.hal-pc.org> Jonathan Guthrie <jguthrie@brokersys.com> writes: > > > How does the Ada compiler implemetor know what C compiler is used in > > that "particular environment in which the compiler operates"? > > Telepathy? > > No, by the name used in the pragma. The conventions Ada, Intrinsic, >Fortran, C, and COBOL are defined in the RM, as are the packages >Interfaces.C, Interfaces.COBOL, and Interfaces.Fortran. Compilers are >allowed to add support for other languages, and in the particular case >mentioned above, they would choose one C compiler to correspond to the >convention C, and others could be named Gcc, VisualC, etc. In practice, >the compiler that corresponds to C is the one used to compile the OS. It would also be easy to implement a command-line option or configuration pragma to override the default meaning for the "C" convention (e.g. by default "C" might mean "VisualC", but the user could override it so that "C" would mean "gcc"). -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP 1998-04-26 0:00 ` Robert Dewar 1998-04-26 0:00 ` Jonathan Guthrie @ 1998-05-01 0:00 ` Joe Gwinn 1998-05-02 0:00 ` Larry Kilgallen 1998-05-05 0:00 ` Robert Dewar 1 sibling, 2 replies; 43+ messages in thread From: Joe Gwinn @ 1998-05-01 0:00 UTC (permalink / raw) In article <dewar.893595400@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > Joe said [snip] > <<By the way, coders don't choose languages, managers do.>> > > That's perfectly reasonable. Indeed "coders" often don't have the perspective > to make a choice. What is important is that whoever makes the decision, > no matter what their title be, have the kind of technical knowledge that > is needed to make a sound decision. All too often managers don't know enough > of the details to make sensible decisions. I have seen managers choose a > programming language when they knew absolutely nothing about the language > at all. So have I. Choice of language is only rarely a technical issue. Nor are managers likely to become more technical. Sorry. > By the way "coders" is a rather contemptous term for a manager to use. I > trust you are not operating in an environment where you really have people > coding who understand nothing in the programming process other than actual > coding. That was a model used by many COBOL shops in the 60's and 70's (the > very ones who give us the Y2K headaches today), and is largely discredited. > Certainly in the kind of technical area for which Ada is used, I would look > for programmers with excellent knowledge of both Ada and the entire programming > process to be involved. Call "coders" programmers if you like, or even software engineers; it makes little difference, and I've been called all of these, and worse. > <<You know, just listening to the newsgroup traffic for a year would give > one the idea that there might be an issue or two here. I recall lots of > C/C++ to Ada interface questions. Do you think there might be a pattern > in all those unsubstantiated postings?>> > > I am always suspicious of people lumping C/C++ together in one breath as though > they are one language. They are most definitely NOT one language. Of course not, but close enough for my purposes. There is after all a more than passing relationship between C and C++, and Ada95 is close to neither. > ... If you look > at these posts, you will find the following clear pattern. > > In the case of C, the Ada 95 definition is adequate. The one remaining > glitch of which I am aware, namely the issue of passing structs' by value > (not such a common occurrence) is handled by the pragma C_Pass_By_Copy, > implemented compatibly in GNAT and Intermetrics (i.e. including Green Hills). > > In the case of C++, no C++ standard was in effect at the time that Ada was > standardized (indeed as I assume you know, the C++ standard is very recent). > So there is no standardized method in the Ada 95 RM for interfacing directly > to C++. In practice there is no problem because C and C++ can interoperate, > and Ada and C can interoperate, so a portable solution can be created by > using a C interface layer (this is the sort of knowledge that should be > at hand in any work you do in this area). > > GNAT does provide a set of pragmas for direct interfacing to C++, but > these are not a standard part of the language. The ARA technical committee > has made some progress towards a common set of interfaces for C++, but > this work is not yet complete. > > Quite a few of the posts you are talking about have to do with using these > special GNAT features. This is an area that you cannot expect Ada > programmers to be familiar with, and indeed we definitely spend time > helping our supported customers use these GNAT-specific problems. > > But for most purposes the use of an intermediate C layer solves the > problems. Whether this is true in your case (or whether your case > involves C++ at all) remains to be seen pending some more technical > details on the problems that you actually face. I would have to point out that we need *portable* but *bulletproof* Ada95-C/C++ interfaces. With any chosen fixed set of compilers, one can usually get things to work well enough. If portability is required, things get much harder. In any case, it doesn't much matter what theoretical portability features are claimed, as this is a particularly difficult and bug-ridden area. There are two Ada-C/C++ issues here: Direct subroutine calling, and also passage of messages back and forth. > <<As I said, I will dig up a list, probably next week.>> > > We look forward to it. A list would be very instructive, but even ONE > clear technical answer would help get this conversation out of the rather > uninformative philosophical level onto a technical level. Doesn't seem too promising, does it? Joe Gwinn ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP 1998-05-01 0:00 ` Joe Gwinn @ 1998-05-02 0:00 ` Larry Kilgallen 1998-05-05 0:00 ` Robert Dewar 1 sibling, 0 replies; 43+ messages in thread From: Larry Kilgallen @ 1998-05-02 0:00 UTC (permalink / raw) In article <gwinn-0105982329270001@d153.dial-2.cmb.ma.ultra.net>, gwinn@ma.ultranet.com (Joe Gwinn) writes: > In article <dewar.893595400@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote: >> I am always suspicious of people lumping C/C++ together in one breath as > though >> they are one language. They are most definitely NOT one language. > > Of course not, but close enough for my purposes. There is after all a > more than passing relationship between C and C++, and Ada95 is close to > neither. In a discussion of managers who don't know anything about choosing a language, C and C++ decisions are equivalent in the vast majority of cases. The manager thinks the language being used is C++ because that is the compiler which was purchased. The worst defect of C++ may be the ability to code in C. Cultural difference make this less of a problem for Ada compilers that have the ability to drop into assembly language. Larry Kilgallen ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP 1998-05-01 0:00 ` Joe Gwinn 1998-05-02 0:00 ` Larry Kilgallen @ 1998-05-05 0:00 ` Robert Dewar 1 sibling, 0 replies; 43+ messages in thread From: Robert Dewar @ 1998-05-05 0:00 UTC (permalink / raw) Joe says <<I would have to point out that we need *portable* but *bulletproof* Ada95-C/C++ interfaces. With any chosen fixed set of compilers, one can usually get things to work well enough. If portability is required, things get much harder. In any case, it doesn't much matter what theoretical portability features are claimed, as this is a particularly difficult and bug-ridden area.>> Obviously the RM does not try to address C++ directly (how could it, there was no such standard language in 1995). However, in practice you can almost always create a C wrapper to solve this problem in a completely portable manner. You keep claiming that this is impossible, but it does not add to the convincing nature of your argument to simply repeat this claim without any proof or details. We need an example to understand what you are talking about! <<> We look forward to it. A list would be very instructive, but even ONE > clear technical answer would help get this conversation out of the rather > uninformative philosophical level onto a technical level. Doesn't seem too promising, does it?>> Not until you cough up your promised example! We are still waiting. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada... 1998-04-09 0:00 ` Joe Gwinn 1998-04-10 0:00 ` Urgent question: malloc and ada...READ/NEW/FOLLOWUP Larry Kilgallen @ 1998-04-10 0:00 ` Robert Dewar 1998-04-12 0:00 ` Joe Gwinn 1 sibling, 1 reply; 43+ messages in thread From: Robert Dewar @ 1998-04-10 0:00 UTC (permalink / raw) Joe says (of interfacing C and Ada) <<and better with Ada95, but is often tricky >> It would be interesting to know in more detail what "tricky" things you have run in to. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Urgent question: malloc and ada... 1998-04-10 0:00 ` Urgent question: malloc and ada Robert Dewar @ 1998-04-12 0:00 ` Joe Gwinn 1998-04-12 0:00 ` Enumeration Types (was: Urgent question: malloc and ada) Matthew Heaney 0 siblings, 1 reply; 43+ messages in thread From: Joe Gwinn @ 1998-04-12 0:00 UTC (permalink / raw) In article <dewar.892208692@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > Joe says > > (of interfacing C and Ada) > > <<and better with Ada95, but is often tricky > >> > > It would be interesting to know in more detail what "tricky" things you > have run in to. Most of the trouble has been in passing data structures (records in Ada, structs in C/C++) from one world to the other. Pragma interface C has worked mostly as expected, but getting the data across the divide undamaged has not. This was where the rep spec on an enumeration type problem first surfaced. These data structures are most often used for message handling, which is how the three worlds of our system talk to each other. One world is Ada95, and the other two are different flavors of C/C++ in different boxes under different operating systems. One kind of box and operating system houses Ada95 and one kind of C, and the other kind of box and operating system houses the other kind of C/C++. I don't know how much of the details of what has caused recent trouble is universal, but I do know that passing data between languages and compilers has always been a rich source of trouble, for all languages and compilers, for my entire career, so I don't expect that it will ever change. Joe Gwinn ^ permalink raw reply [flat|nested] 43+ messages in thread
* Enumeration Types (was: Urgent question: malloc and ada) 1998-04-12 0:00 ` Joe Gwinn @ 1998-04-12 0:00 ` Matthew Heaney 1998-04-13 0:00 ` Mark A Biggar 0 siblings, 1 reply; 43+ messages in thread From: Matthew Heaney @ 1998-04-12 0:00 UTC (permalink / raw) In article <gwinn-1204981927580001@d13.dial-1.cmb.ma.ultra.net>, gwinn@ma.ultranet.com (Joe Gwinn) wrote: >Most of the trouble has been in passing data structures (records in Ada, >structs in C/C++) from one world to the other. Pragma interface C has >worked mostly as expected, but getting the data across the divide >undamaged has not. This was where the rep spec on an enumeration type >problem first surfaced. One "solution" is to not use enumeration types with rep clauses at all - just use an integer. It seems that the ability to put a representation clause on an enumeration type was a feature only included in the langauge to make it consistant; after all, you can choose the representation of other types, so why not enumeration types too? But it causes all kinds of problems. You'll have lots o' problems if you have a value with a bit pattern not among the legal values (possible because you moved the data over an external interface, and there was some noise during transmission). I find it simpler to avoid that mess altogether and use just integer types across an interface, and writing my own mapping function (array) from integer value to enumeration literal. In practice, using an integer type instead of an enumeration is only marginally less safe. Consider this: type ET is (Red, Green, Blue); for ET use (Red => 1, Green => 3, Blue => 7); for ET'Size use 8; procedure Op (O : ET); Now consider this: type IT is new Interfaces.Unsigned_8; Red : constant IT := 1; Green : constant IT := 3; Blue : constant IT := 7; procedure Op (O : IT); From a client's point of view, there is no difference between these types (though a case statement now requires an others branch). You call procedure Op the same way in both cases. You can make the argument, "But with the integer version, the client can pass the value 2." But this can only happen because of deliberate misuse, ie Op (2); Here, he's being naughty, and using an integer literal. What he should do is Op (Red); just like he'd do using the enumeration literal. And no, you can't even accidently mix this type up with other integer types, because IT is its own type. You'd have to deliberately convert one integer type into the other. All told, I feel the ability to give an enumeration type a rep clause is an unnecessary, error-prone feature of the Ada language. An enumeration type is at too high a level of abstraction to accomodate such a low-level feature. Giving a rep clause to an enumeration type causes all kinds of other headaches for users and compiler-writers alike, such as using the type to index an array, or taking the successor or predecessor of a value, when type rep clause has holes. Tuck wrote a thoughtful post on this topic a few weeks back. I've included it below. Also, note that there is no such thing as rep "spec." The proper term is rep "clause." >Joe Gwinn (gwinn@res.ray.com) wrote: >: In article <EKrsrr.LD7.0.-s@inmet.camb.inmet.com>, >: stt@houdini.camb.inmet.com (Tucker Taft) wrote: > >: ... >: > As far as enumeration types, as others have pointed out, the Ada 95 >: > standard requires that the internal codes for enumeration types are >: > contiguous and start at zero, so you are not in any danger if you leave >: > out your "confirming" representation clauses. It would be nice if >: > our front end recognized "confirming" enumeration representation >: > clauses, but as usual, there are many possible "optimizations" >: > and this one never made it to the top of the list. >: > One might argue that this is not really an optimization, but >: > it does require special code to recognize, and so represents >: > yet another "special case" that you have to decide the priority >: > of recognizing. > >: The key issue was that we had no way of knowing the dire consequences of >: this innocent looking bit of standard Ada, until we had gone a fair >: distance down that wrong road. > >If you ask anyone who knows me well, you will know that I consider >the enumeration representation clause anything but "innocent looking" ;-). >For what it is worth, we will soon be releasing a new front end >that recognizes the special case of a confirming enumeration >representation clause. > >[ASIDE: > >Although the ability to specify the representation of an enumeration >type initially sounds perfectly reasonable, the fundamental problem is that >Ada also allows such "holey" enumeration types to be used as the >type for a for-loop index, an array index, an entry family index, >or the 'Succ/'Pred attributes. This results in surprising implicit >inefficiencies, something that violates one of the general Ada >language design principles. Your enumeration rep clause simply reconfirmed >the default representation, but suppose it didn't? You would be >stuck with the overhead you managed to eliminate by simply commenting >out the rep clause. Of course, the compiler could recognize various >other specials cases, such as contiguous representation starting at >something other than zero, or evenly distributed "holey" representation >(e.g., even numbers only), or simply not "too" sparse, or ... > >Pretty soon handling these enumeration representation clauses >the way the "innocent" user would "expect" becomes a major artificial >intelligence challenge. During the Ada 9X design process, when we >found one of our new language ideas evoving into this kind of complex >AI pattern matching problem for the compiler, we knew we were on the >wrong track. The user should be designing the algorithms, using >the basic primitives of the language. The primitives shouldn't themselves >be at such a level that the compiler is effectively trying to take over >part of the programming problem. > >Note that in C and C++, allowing the user to specify the values for >enumeration literals creates no similar problem, because there is >no operation that depends on the logical "position" of an enumeration >literal. All semantics of enumeration values in C/C++ depends on the >underlying "code," not the position. > >So in retrospect, I believe enumeration representation >clauses in Ada are a mistake. If a user wants to name >particular values, they should simply use named integer >constants, or perhaps better, named private-type constants. They can build >up various maps of their own if they want to translate to/from some kind >of "holey" representation from/to a contiguous representation. > >END OF ASIDE] > >: ... One wonders what other surprises lay in >: wait. > >In general, the Ada language design philosophy eschewed "innocent" >looking features that were in fact expensive at run-time. >However, in the specific case of enumeration representation clauses, >this useful language design philosophy was not completely followed. >Other cases I know of are interactions between finalization, >exception handling, and abort, where the combination of features >forces some or all of these three to incur more run-time overhead >than you might expect. > >One "innocent" looking construct I once found was: > > (others => Default_Value(Segment)) > >used to initialize a segment of a load module to some default value. >This called the function Default_Value once for each byte of the >segment, and the segment was often 100K bytes or more. > >: ... > >: Joe Gwinn > >-- >-Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ >Intermetrics, Inc. Burlington, MA USA Extra text needed because of my stupid newsreader. Sorry. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Enumeration Types (was: Urgent question: malloc and ada) 1998-04-12 0:00 ` Enumeration Types (was: Urgent question: malloc and ada) Matthew Heaney @ 1998-04-13 0:00 ` Mark A Biggar 0 siblings, 0 replies; 43+ messages in thread From: Mark A Biggar @ 1998-04-13 0:00 UTC (permalink / raw) Matthew Heaney wrote: > In practice, using an integer type instead of an enumeration is only > marginally less safe. Consider this: > > type ET is (Red, Green, Blue); > for ET use (Red => 1, Green => 3, Blue => 7); > for ET'Size use 8; > > procedure Op (O : ET); > > Now consider this: > > type IT is new Interfaces.Unsigned_8; > > Red : constant IT := 1; > Green : constant IT := 3; > Blue : constant IT := 7; > > procedure Op (O : IT); > > From a client's point of view, there is no difference between these types > (though a case statement now requires an others branch). You call > procedure Op the same way in both cases. > > You can make the argument, "But with the integer version, the client can > pass the value 2." But this can only happen because of deliberate misuse, > ie > > Op (2); > > Here, he's being naughty, and using an integer literal. What he should do is > > Op (Red); > > just like he'd do using the enumeration literal. > > And no, you can't even accidently mix this type up with other integer > types, because IT is its own type. You'd have to deliberately convert one > integer type into the other. Actually you can do even better as follows: package SomePackage is type IT is private; Red : constant IT; Green : constant IT; Blue : constant IT; procedure Op (O : IT); private type IT is new Interfaces.Unsigned_8; Red : constant IT := 1; Green : constant IT := 3; Blue : constant IT := 7; end SomePackage; This eliminates the Op(2) problem while keeping all the properties of your example. -- Mark Biggar mark.a.biggar@lmco.com ^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, other threads:[~1998-05-12 0:00 UTC | newest] Thread overview: 43+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1998-04-07 0:00 Urgent question: malloc and ada Guido Tesch 1998-04-09 0:00 ` Joe Gwinn 1998-04-10 0:00 ` Urgent question: malloc and ada...READ/NEW/FOLLOWUP Larry Kilgallen 1998-04-12 0:00 ` Joe Gwinn 1998-04-14 0:00 ` Robert Dewar 1998-04-16 0:00 ` Joe Gwinn 1998-04-17 0:00 ` Robert Dewar 1998-04-18 0:00 ` Joe Gwinn 1998-04-18 0:00 ` Robert Dewar 1998-04-25 0:00 ` Joe Gwinn 1998-04-26 0:00 ` Robert Dewar 1998-04-26 0:00 ` Jonathan Guthrie 1998-04-26 0:00 ` Simon Wright 1998-04-26 0:00 ` Larry Kilgallen 1998-04-27 0:00 ` Stephen Leake 1998-04-26 0:00 ` Robert Dewar 1998-04-30 0:00 ` Robert I. Eachus 1998-04-30 0:00 ` Urgent question: malloc and ada Larry Kilgallen 1998-05-01 0:00 ` Robert Dewar 1998-05-01 0:00 ` Charles Hixson 1998-05-02 0:00 ` Jonathan Guthrie 1998-05-02 0:00 ` Corey Minyard 1998-05-06 0:00 ` Robert I. Eachus 1998-05-12 0:00 ` Craig T. Spannring 1998-05-12 0:00 ` Robert Dewar [not found] ` <matthew_heaney-ya023680003004981723000001@news.ni.net> 1998-05-01 0:00 ` Robert Dewar 1998-05-01 0:00 ` Larry Kilgallen 1998-05-02 0:00 ` Robert Dewar 1998-05-02 0:00 ` Jonathan Guthrie 1998-05-03 0:00 ` Robert Dewar 1998-05-03 0:00 ` Richard Kenner 1998-05-03 0:00 ` Jonathan Guthrie 1998-05-03 0:00 ` Richard Kenner 1998-05-03 0:00 ` Robert Dewar 1998-05-03 0:00 ` Larry Kilgallen 1998-05-01 0:00 ` Urgent question: malloc and ada...READ/NEW/FOLLOWUP Fergus Henderson 1998-05-01 0:00 ` Joe Gwinn 1998-05-02 0:00 ` Larry Kilgallen 1998-05-05 0:00 ` Robert Dewar 1998-04-10 0:00 ` Urgent question: malloc and ada Robert Dewar 1998-04-12 0:00 ` Joe Gwinn 1998-04-12 0:00 ` Enumeration Types (was: Urgent question: malloc and ada) Matthew Heaney 1998-04-13 0:00 ` Mark A Biggar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox