* Which is right here - GNAT or OA ? @ 1999-05-30 0:00 Vladimir Olensky 1999-05-30 0:00 ` Florian Weimer ` (3 more replies) 0 siblings, 4 replies; 57+ messages in thread From: Vladimir Olensky @ 1999-05-30 0:00 UTC (permalink / raw) ---------------------------------- -- Which is right here - GNAT or OA ? --------------------------------- Recently I found some time to prepare for "AdaPower" some "touch and feel" examples (just brushing up my old exercises) on using controlled types for user defined GB which could be useful for people learning Ada. It is one of the ways to attract new people to Ada by explaining very simply some things that may seem very difficult. I mentioned about my simple user GB examples few months ago in GB thread but then I had no time to prepare them for open use. Then there was nice article about smart pointers by Mathew Heaney describing the same issue and I did not feel like adding anything else to this subject. Then AdaPower come to the existence (thanks to David Button) and I felt that it is better late than never. While working on that examples I also was preparing some introductory examples where I tried to put light on some things that may be unclear to the beginners. One of these intro examples is the effect of using Ada.Unchecked_Deallocation for pointers referencing different types of objects and objects allocated differently. (one may have a list of objects that are allocated differently and he/she wants that the same operations on the items of this list would have the same effect) To my surprise I found that GNAT 3.11p and OA (ObjectAda Special Edition version 7.1.424) give different results for the same test under Windows 98. Here is this example : ------------------------------------------------------ -- Author: Vladimir Olensky, May 1999 -- -- This example shows what happens when you are -- trying to deallocate static tagged object ( non controlled) --------------------------------------------------------- with Ada.Unchecked_Deallocation; with Ada.Text_Io; use Ada.Text_Io; with Ada.Integer_Text_Io; use Ada.Integer_Text_Io; procedure Tst_A4 is Type Q is record ID:Integer:=0; end record; type Q_A is access all Q; procedure Free is new Ada.Unchecked_Deallocation(Q,Q_A); -- statically declared object q1: aliased Q; q_ptr:Q_A; begin q1.ID:=10; q_ptr:=q1'Access; Put(" Object ID = "); Put( (q_ptr.all.ID),2); New_Line; Put_line("-----------------------------------"); -- Statement_1: free(q_ptr); ------------------- q1.ID:=20; Put(" Object ID = "); -- Statement_2: Put( (q1.ID),2); ------------------- New_Line; Put(" q_ptr Object ID = "); -- Statement_3: Put( (q_ptr.all.ID),2); ---------------------------------- New_Line; end Tst_A4; ******************************************* In this test we have: GNAT: - executing statement_1 with no problems. after that we have: 1. q_ptr=null 2. q1 continue to exists As a result GNAT is executing Statement_2 with no problems and printing "Object ID = 20" and then raising CONSTRAINT_ERROR exception at Statement_3 (it should be so as q_ptr=null) OA: - raising exception at Statement_1: For me the right behavior of the Ada.Unchecked_Deallocation for pointer to statically allocated object (regardless of what RM is saying now) would be not to try to deallocate static object of any type - tagged or not tagged, controlled or uncontrolled and assign null value to pointer for which Ada.Unchecked_Deallocation was invoked. Why there is no such thing in RM Section 13.11.2 after paragraph 9 ? Were there any reasons not to describe this case? To me GNAT behavior is better than OA though is not consistent. ( for controlled types GNAT behaves differently - it raises PROGRAM_ERROR : EXCEPTION_ACCESS_VIOLATION). RM Section 13.11.2 does not describe clearly and explicitly this case so there is no wonder that the two best compiles behave differently. It is interesting if similar test is included in Ada compiles validation procedures. It would be interesting to hear comments regarding this issue. Regards, Vladimir_Olensky ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Which is right here - GNAT or OA ? 1999-05-30 0:00 Which is right here - GNAT or OA ? Vladimir Olensky @ 1999-05-30 0:00 ` Florian Weimer 1999-05-31 0:00 ` Vladimir Olensky 1999-06-01 0:00 ` Which is right here - GNAT or OA ? Tucker Taft 1999-05-30 0:00 ` Robert Dewar ` (2 subsequent siblings) 3 siblings, 2 replies; 57+ messages in thread From: Florian Weimer @ 1999-05-30 0:00 UTC (permalink / raw) "Vladimir Olensky" <vladimir_olensky@yahoo.com> writes: > RM Section 13.11.2 does not describe clearly and explicitly this case > so there is no wonder that the two best compiles behave differently. Well, actually it does (see RM 13.11.2(16)): | The execution of a call to an instance of Unchecked_Deallocation is | erroneous if the object was created other than by an allocator for an | access type whose pool is Name'Storage_Pool. So in fact, there's no contradiction, although the two compilers behave differently. I don't think the language designers could have specified anything but erroneous execution in this case. For example, it is very complicated to detect that the value of an Access attribute of an aliased record component is not a valid argument for a given instance of Ada.Unchecked_Deallocation if the record itself has been created by an allocator. Simple heuristics based on the machine address of the object in question clearly do not work here. Another but related thing surprises me---it's AARM 12.5.4(4.a): | If no _modifier applies to the formal, then the actual type may be | either a pool-specific or a general access-to-variable type. I can't imagine any reason why an access-to-variable type should be allowed as an actual parameter for a formal access type without an `all' modifier. If this was changed, an access-to-variable would not be allowed as a parameter in an instantiation of Ada.Unchecked_Deallocation, which seems quite reasonable to me. (I don't claim that the language definition inadequate here, I simply can't make sense out of it, which is very likely my own fault. ;) ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Which is right here - GNAT or OA ? 1999-05-30 0:00 ` Florian Weimer @ 1999-05-31 0:00 ` Vladimir Olensky 1999-05-31 0:00 ` Robert Dewar 1999-06-01 0:00 ` Which is right here - GNAT or OA ? Tucker Taft 1 sibling, 1 reply; 57+ messages in thread From: Vladimir Olensky @ 1999-05-31 0:00 UTC (permalink / raw) Florian Weimer wrote in message ... >"Vladimir Olensky" <vladimir_olensky@yahoo.com> writes: > >I don't think the language designers could have specified anything >but erroneous execution in this case. For example, it is very >complicated to detect that the value of an Access attribute of an >aliased record component is not a valid argument for a given instance >of Ada.Unchecked_Deallocation if the record itself has been created by >an allocator. Simple heuristics based on the machine address of the >object in question clearly do not work here. As a matter of fact this is amazingly simple. If I can do this check at a run time myself why RTS can not do the same ? The cost of this is one additional hidden field in the type representation which is set to needed value during object creation. Soon I demonstrate this simple technique in set of "talking" examples that are almost ready to be posted to AdaPower. The same thing could be done by the compiler itself. There even will be no need to have additional public run time attributes. Compiler or allocator sets this field during object creation and RTS can check this field and do what needed depending on value of this field upon object deallocation request. This could be very handy. > >Another but related thing surprises me---it's AARM 12.5.4(4.a): > >| If no _modifier applies to the formal, then the actual type may be >| either a pool-specific or a general access-to-variable type. > >I can't imagine any reason why an access-to-variable type should be >allowed as an actual parameter for a formal access type without an >`all' modifier. If this was changed, an access-to-variable would not be >allowed as a parameter in an instantiation of Ada.Unchecked_Deallocation, >which seems quite reasonable to me. (I don't claim that the language >definition inadequate here, I simply can't make sense out of it, which >is very likely my own fault. ;) Yes, very interesting, I agree, it does not go all along the line with Ada strong type checking. In some circumstances it may cause the same result that was demonstrated in my small demo. Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Which is right here - GNAT or OA ? 1999-05-31 0:00 ` Vladimir Olensky @ 1999-05-31 0:00 ` Robert Dewar 1999-06-05 0:00 ` Vladimir Olensky 0 siblings, 1 reply; 57+ messages in thread From: Robert Dewar @ 1999-05-31 0:00 UTC (permalink / raw) In article <928174549.336.98@news.remarQ.com>, "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: > As a matter of fact this is amazingly simple. No, doing this without adding unacceptable overhead is not simple, and in fact is simply not practical. > If I can do this > check at a run time myself why RTS can not do the same ? Because the cost is too high > The cost of this is one additional hidden field in the type > representation which is set to needed value during object > creation. Yes, and that cost is much too high, for example, if you have a simple linked list type, you could be talking about adding a storage overhead of 20-25%. Surely you must realize your method is completely obvious! The fact that the RM makes this situation erroneous is an explicit indication that the designers of the language have considered your solution and rejected it as introducing excessive overhead. The design is very sensitive to avoiding unnecessary storage use. FOr example, the confusing difference between: A : aliased constant String (1 .. 80) := " 80 chars ..."; A : aliased constant String := " 80 chars ..."; is solely to save the 8 bytes that would otherwise be required for the bounds in the first case. > Soon I demonstrate this simple technique in set of "talking" examples that > are almost ready to be posted to AdaPower. > The same thing could be done by the compiler itself. There even will be no > need to have additional public run time attributes. > Compiler or allocator sets this field during object creation and RTS can > check this field and do what needed depending on value of this field upon > object deallocation request. This could be very handy. > > > > >Another but related thing surprises me---it's AARM 12.5.4(4.a): > > > >| If no _modifier applies to the formal, then the actual type may be > >| either a pool-specific or a general access-to-variable type. > > > >I can't imagine any reason why an access-to-variable type should be > >allowed as an actual parameter for a formal access type without an > >`all' modifier. If this was changed, an access-to-variable would not be > >allowed as a parameter in an instantiation of Ada.Unchecked_Deallocation, > >which seems quite reasonable to me. (I don't claim that the language > >definition inadequate here, I simply can't make sense out of it, which > >is very likely my own fault. ;) > > Yes, very interesting, I agree, it does not go all along the line with Ada > strong type checking. > In some circumstances it may cause the same result that was demonstrated in > my small demo. > > Regards, > > Vladimir Olensky > > Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Which is right here - GNAT or OA ? 1999-05-31 0:00 ` Robert Dewar @ 1999-06-05 0:00 ` Vladimir Olensky 1999-06-05 0:00 ` Florian Weimer 1999-06-05 0:00 ` Vladimir Olensky 0 siblings, 2 replies; 57+ messages in thread From: Vladimir Olensky @ 1999-06-05 0:00 UTC (permalink / raw) Robert Dewar wrote in message <7iuqkc$ln6$1@nnrp1.deja.com>... >> The cost of this is one additional hidden field in the type >> representation which is set to needed value during object >> creation. > >Yes, and that cost is much too high, for example, if you have >a simple linked list type, you could be talking about adding >a storage overhead of 20-25%. I fully agree about additional cost and it may be even higher. But for types which size is more than 100 bytes the cost will be less than 4%. So if compiler could provide such runtime supports for objects marked for example as TRACED (just contrary to Modula-3 UNTRACED to exclude selected objects from GB process) than it could reduce the list of situations when Ada program peforms erroneous execution. I do not think that this is bad. >Surely you must realize your method is completely obvious! The >fact that the RM makes this situation erroneous is an explicit >indication that the designers of the language have considered >your solution and rejected it as introducing excessive overhead. Of course I realize that it is very obvious. It is first_come_to_mind solution for user built types in situations when there is no compiler support for that and I agree that it is not very suitable to be built into compiler. Compiler implementation could be handled completely differently. Each program has several memory areas (at least three - CODE, DATA and STACK). Compiler can same create special record with the fields CODE_START, CODE_END, STACK_START, STACK_END, PROGRAM_STATIC_DATA1_START, PROGRAM_STATIC_DATA1_END, PROGRAM_STATIC_DATA2_START, PROGRAM_STATIC_DATA2_END etc. Compiler and linker have all the information to be able to do this. When Free(X) is invoked then RTS could do something like this (in reality it may be much more complex): If (X_referenced_ object_Address NOT in CODE_ADDRESS_RANGE) and then (X_referenced_ object_Address NOT in STACK_ADDRES_RANGE) and then (X_referenced_ object_Address NOT in STATIC_DATA_ADDRESS_RANGE) and then (all other necessary checks) then Deallocate_Referenced_Object; -- or raise name_exception here to be close to RM X:=null; else X:=null; end; Such solution have very little overhead and it is not very difficult to be implemented. Such thing could be turned on/off by compiler pragma in order not to introduce anything in language definition. Doing so it is possible reduce the number of situation when Ada program can perform erroneous execution (with unpredictable effect). Again there is nothing new in this. Similar technique was used earlier in assembler programming for many purposes. (e.g. old DOS TSR programs used to calculate it's code size (CODE_END-CODE_START) to allocate themselves into computer memory) >The design is very sensitive to avoiding unnecessary storage >use. For example, the confusing difference between: > > A : aliased constant String (1 .. 80) := " 80 chars ..."; > A : aliased constant String := " 80 chars ..."; > >is solely to save the 8 bytes that would otherwise be required >for the bounds in the first case. This is indeed very interesting example. I think it ( and a bit of assembler code) could be placed in AdaPower in section named something like "Ada Tips and Tricks". ----------------------------------------------------------- procedure Ada_Rts is a : aliased constant String (1 .. 10) := "1234567890"; b : aliased constant String := "1234567890"; begin null; end Ada_Rts; ---------------------------------------------------------- gcc2_compiled.: ___gnu_compiled_ada: ..text LC0: ..ascii "1234567890\0" ..data _a.0: ..ascii "1234567890" ..text ..align 4 _b.1: ..long 1 ..long 10 ..ascii "1234567890" ..space 2 ..align 4 ..globl __ada_ada_rts __ada_ada_rts: pushl %ebp movl %esp,%ebp movl %ebp,%esp popl %ebp ret --------------------------------------------------- Such optimization is extremely important for embedded applications. In practice there exist general use applications running on top of different OSs. For them small overhead does not make much difference. Executable size for the above example with GNAT 3.11p for Windows NT is 110 kb. So adding to it some amount of code won't make any difference. Another thing that is worth to the importance of how compiler and linker work together in order to provide minimum executable size by cutting off unused code. For example Windows demo Keylook that was built using GNAT with -O3 has size of 378 Kbytes. And this was using only thin Win32 bindings. MS VC98 simple Win32 application with menus ,dialogs (direct calls to Win APIs - without MFC) has size of only 28 kb. Building simple application using Claw & GNAT results in executable size above 1.5Mb. Simple Win32 application that uses MFC (MS OOP Win32 libraries) has size of 252 kb when MFC libraries are statically linked to the executable. When MFC is used as shared DLL the exe size is 28 kb. This comparison shows where one should be talking about size overhead. It seems that GCC linker links everything contained in packages WITHed to main program. This is problem of the compiler-linker cooperation in producing smallest possible code. I understand that GNAT here has more difficult situation with GCC linker than other compiler vendors with their own linkers. Please take me right. I am not complaining about GNAT. I just trying to show that when we are talking about overhead and cost of additional memory usage to perform some system tasks we should have broader view on things. One thing is when we are talking about embedded systems where Ada is running sometimes on a bare hardware or it is using small size RTS tailored to particular requirements . When we are talking about general purpose Win32 app ( or Unix app maybe) that uses a lot of standard libraries then situation is different. Of course I know about Gnatelim and I played with it some time ago. I found it not very convenient for me. I tried it with test application that uses Claw . It can take several iterations and results in hour or more of waste time to obtain some small reduction of file size. STRIP in GNAT3.10 was much more convenient. I think that this work should be performed by compiler-linker tandem. Please do not tell me that I am complaining ! This is just my personal considerations that may be different from other's. That was not me who started talking about memory overhead. -------------------------------------------------------------- > Share what you know. Learn what you don't. I like this phrase and I completely agree with it. It is very constructive. It could be used as motto for c.l.a. Best regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Which is right here - GNAT or OA ? 1999-06-05 0:00 ` Vladimir Olensky @ 1999-06-05 0:00 ` Florian Weimer 1999-06-05 0:00 ` Vladimir Olensky 1 sibling, 0 replies; 57+ messages in thread From: Florian Weimer @ 1999-06-05 0:00 UTC (permalink / raw) "Vladimir Olensky" <vladimir_olensky@yahoo.com> writes: > When Free(X) is invoked then RTS could do something like this (in reality > it may be much more complex): [Heuristics based on the internal access value representation snipped] > Such solution have very little overhead and it is not very difficult to > be implemented. Maybe that's true, but it does not work. Consider the following situation: type A is record X: Integer; end record; type B is record Y: aliased A; end record; type B_Access is access B; Z: B_Access := new B; Your heuristics fails for Z.Y'Access, because this access value references an object which has been created indirectly by an allocator. On all architectures I can imagine, the internal machine representation of Z.Y'Access will look very like that of an access to an object which has been directly created by an allocator, although the value of Z.Y'Access certainly isn't a valid argument for Ada.Unchecked_Deallocation. Of course, it is possible to ensure that Ada.Unchecked_Deallocation raises an exception if it encounters an access-to-variable, but this requires some non-trivial changes. A few possible implementations come to my mind: colored pointers, fat pointers, hidden record fields (your suggestion; problematic with scalar types and possibly with records with representation clauses, also some space concerns), colored tags for tagged records, support from a garbage collector. They all don't seem very appealing to me and probably won't handle all kinds of Ada objects consistently (except perhaps garbage collection ;). One very reasonable way to solve this kind of problem was already pointed out: Use an abstract data type which hides allocation and deallocation details in the implementation. This way, you never have to call Ada.Unchecked_Deallocation directly (outside the implementation, of course), and you can't accidently deallocate an object which isn't located in a storage pool. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Which is right here - GNAT or OA ? 1999-06-05 0:00 ` Vladimir Olensky 1999-06-05 0:00 ` Florian Weimer @ 1999-06-05 0:00 ` Vladimir Olensky 1999-06-05 0:00 ` Robert Dewar 1 sibling, 1 reply; 57+ messages in thread From: Vladimir Olensky @ 1999-06-05 0:00 UTC (permalink / raw) Vladimir Olensky wrote in message <928529202.956.79@news.remarQ.com>... >If (X_referenced_ object_Address NOT in CODE_ADDRESS_RANGE) and then > (X_referenced_ object_Address NOT in STACK_ADDRES_RANGE) and then > (X_referenced_ object_Address NOT in STATIC_DATA_ADDRESS_RANGE) and >then > (all other necessary checks) then > Deallocate_Referenced_Object; -- or raise name_exception here to be >close to RM > X:=null; >else > X:=null; >end; Sorry, I clicked my mouse in the wrong place. I should be: If (X_referenced_ object_Address NOT in CODE_ADDRESS_RANGE) and then (X_referenced_ object_Address NOT in STACK_ADDRES_RANGE) and then (X_referenced_ object_Address NOT in STATIC_DATA_ADDRESS_RANGE) and then (all other necessary checks) then Deallocate_Referenced_Object; X:=null; else X:=null; -- or raise name_exception here to be close to RM end; Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Which is right here - GNAT or OA ? 1999-06-05 0:00 ` Vladimir Olensky @ 1999-06-05 0:00 ` Robert Dewar 1999-06-07 0:00 ` Ada safety road Was: Which is right Vladimir Olensky 0 siblings, 1 reply; 57+ messages in thread From: Robert Dewar @ 1999-06-05 0:00 UTC (permalink / raw) In article <928569312.951.42@news.remarQ.com>, "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: > > Vladimir Olensky wrote in message <928529202.956.79@news.remarQ.com>> <<simple scheme based on address range comparisons snipped>> Obviously you cannot require such a scheme, because of course it is inapplicable in many environments, especially with multi-threading. Even in environments where it might be practical, it's more expensive than you think, because some of these ranges are tasks specific data. In any case, this kind of approach is certainly completely familiar, and it would not be invalid for a compiler to implement it, but it seems a waste of time and space to me to attempt to guard against this kind of logic error in a language that does not even handle the uninitialized variable problem completely (and that too is of course quite a deliberate decision). It is certainly not something we would consider adding to GNAT in any environments. Generally the notion of erroneous in the RM is that you should detect it if it is free or cheap, but NOT add extra code for this kind of detection. Yes, it could be under some kind of debugging pragma, but if you are going to move in that direction, you want to go much further, and in particular handle the uninitialized variable problem, and other, much more common, and much more worrisome cases of erroneous access. Deallocation of static stuff is in fact a pretty easy error to guard against, since most typically this is done in well controlled finalization routines in any case, and it is just a matter of having the discipline to worry about this problem and take proper care of it when you write the finalization routine. And to repeat, since you keep repeating the subject, both GNAT and OA are right here, and do what the RM intends! Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Ada safety road Was: Which is right ... 1999-06-05 0:00 ` Robert Dewar @ 1999-06-07 0:00 ` Vladimir Olensky 1999-06-06 0:00 ` Robert Dewar ` (2 more replies) 0 siblings, 3 replies; 57+ messages in thread From: Vladimir Olensky @ 1999-06-07 0:00 UTC (permalink / raw) Robert Dewar wrote in message <7jb1l9$694$1@nnrp1.deja.com>... >And to repeat, since you keep repeating the subject, both >GNAT and OA are right here, and do what the RM intends! Sorry, It just didn't come up to my mind to change the subject. Even original subject was not very adequate to what I had in mind I really did not had intention on insisting which is better in following RM. I had other things in mind. I was just thinking about different aspects of providing some general kind of "foolproofness" to program written in Ada in places where RM define program behavior as erroneous. I think nobody would like to be on a plane that performed erroneous flight """' ' ' ^~\_+. Anyone would prefer to be accidentally on board of the wrong flight instead. One good aspect of Ada is that when it is impossible to provide compiler solution to some problems (due to implementation cost and some other reasons that may not be very obvious) LRM at least honestly specifies situations when erroneous execution is possible. But I see one problem here. All this information is scattered around RM. I think that to facilitate safety programming such info should be gathered into one paper with explanations why it was not possible to overcome such situations and it should contain many examples covering different aspects that leads to erroneous execution. There should be no indirect references ("other then ...."). Everything should be directly described and should be as simple as possible. I see it as some kind of "Ada safety programming roadmap". And of course such paper should be easily available online for all interested in it. So far I have not seen such document available online . If you crossing mine field and you do not have good map with red marks on it all your life depends on your luck :-) Such type of documents are usually top level documents in design of any safety critical system (at least it was in my experience). I recently put together all that staff from RM and I should mention that this list is not very short. So I was wondering if it is possible to do something on compiler level to make this list shorter. Almost five ears left since adoption of Ada 95 standard. Computing power has increased almost tenfold since then (CPU speed, memory access time, memory density etc.). Some things that were costly to implement then may have much less cost now. Here I would like to add one more thing. In many disputes Ada is described as mostly reliable language which allows to catch almost all errors at compile time and others at a run time by raising exceptions. This can create some kind of trap for those starting to use Ada ( to forget about cases of erroneous execution or not to pay attention to them) (e.g. typical comparisons between C&C++ and Ada pointers from which the reader may have wrong impression that Ada fully safe in this respect and as a result not to pay proper attention to that issue. For me the most safe in this area is Modula-3 for very well known reasons). Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-07 0:00 ` Ada safety road Was: Which is right Vladimir Olensky @ 1999-06-06 0:00 ` Robert Dewar 1999-06-07 0:00 ` Pascal F. Martin 1999-06-08 0:00 ` Robert A Duff 1999-06-06 0:00 ` Larry Kilgallen 1999-06-10 0:00 ` Ada safety road Was: Which is right Peter Amey 2 siblings, 2 replies; 57+ messages in thread From: Robert Dewar @ 1999-06-06 0:00 UTC (permalink / raw) In article <928703068.617.98@news.remarQ.com>, "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: > I was just thinking about different aspects of providing some > general kind of "foolproofness" to program written in Ada in places where RM > define program behavior as erroneous. > I think nobody would like to be on a plane that performed > erroneous flight > """' ' ' ^~\_+. > Anyone would prefer to be accidentally on board of the wrong > flight instead. Don't worry, safety critical software of this type is certified, and typically written in a small safe subset of Ada. It would be VERY unusual to allow Unchecked_Deallocation *at all* in such an application, and if it was allowed, it would have to verified that all possible calls were safe. It is VERY important for Ada programmers to be aware of the situations which lead to erroneous programs. You can easily search through the RM to find all such cases. In fact I will repeat again my thought here. This is a VERY marginal case of erroneousness. If you want to get into the business of writing a "checkout" compiler that spends extra time and space to check for as many erroneous situations as possible, this is not at the top of the list for cases that are useful to check! Remember though, that runtime checks, while very useful, are not a panacea. I don't want to be on a plane that executes erroneous code, but I also don't want the captain to get a message saying that Constraint_Error was raised at such and such a location :-) (in fact run time checks are in my experience usually turned off for safety critical code, since they cause trouble with deactivated code in verification protocols). Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-06 0:00 ` Robert Dewar @ 1999-06-07 0:00 ` Pascal F. Martin 1999-06-07 0:00 ` Vladimir Olensky 1999-06-08 0:00 ` Robert A Duff 1 sibling, 1 reply; 57+ messages in thread From: Pascal F. Martin @ 1999-06-07 0:00 UTC (permalink / raw) In article <7jf1ik$8v6$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes: > In article <928703068.617.98@news.remarQ.com>, > "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: > >> I was just thinking about different aspects of providing some >> general kind of "foolproofness" to program written in Ada in > places where RM >> define program behavior as erroneous. >> I think nobody would like to be on a plane that performed >> erroneous flight >> """' ' ' ^~\_+. >> Anyone would prefer to be accidentally on board of the wrong >> flight instead. > > [...] > > I don't want to be on a plane that executes erroneous code, > but I also don't want the captain to get a message saying > that Constraint_Error was raised at such and such a location :-) I remember that the first Ariane 5 rocket had been lost when an Ada program did hit a runtime check ! The exception was not the cause of the problem (it was a design error), but it made the rocket crash. Sometime, it make sense to ignore errors and continue on. Constraint_Error is for developpers, not for users, and a program cannot be in "debug mode" forevever. -- Pascal F. Martin. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-07 0:00 ` Pascal F. Martin @ 1999-06-07 0:00 ` Vladimir Olensky 0 siblings, 0 replies; 57+ messages in thread From: Vladimir Olensky @ 1999-06-07 0:00 UTC (permalink / raw) Pascal F. Martin wrote in message ... >In article <7jf1ik$8v6$1@nnrp1.deja.com>, > Robert Dewar <robert_dewar@my-deja.com> writes: >> In article <928703068.617.98@news.remarQ.com>, >> "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: >> >>> I was just thinking about different aspects of providing some >>> general kind of "foolproofness" to program written in Ada in >> places where RM >>> define program behavior as erroneous. >>> I think nobody would like to be on a plane that performed >>> erroneous flight >>> """' ' ' ^~\_+. >>> Anyone would prefer to be accidentally on board of the wrong >>> flight instead. >> >> [...] >> >> I don't want to be on a plane that executes erroneous code, >> but I also don't want the captain to get a message saying >> that Constraint_Error was raised at such and such a location :-) > >I remember that the first Ariane 5 rocket had been lost when >an Ada program did hit a runtime check ! The exception was not >the cause of the problem (it was a design error), but it made >the rocket crash. > >Sometime, it make sense to ignore errors and continue on. >Constraint_Error is for developpers, not for users, and >a program cannot be in "debug mode" forevever. I remember that report. Some parameters went out of the limits that were set for Ariane 4. These limits were not changed for Ariane 5 though it was equipped with the new engines and operation conditions during launch time were quite different. But needed software tests for new operational conditions were not performed properly and we have seen the results. I fully agree that most of the run time checks are usually used in debug mode and they serve for application testing. In release mode most of them are usually turned off. So most of the developing systems provide ability to set parameters for each mode independently and create any additional configuration profile if needed. The more could be done in debug mode the less possibility that something could sneak into release mode. Anyway it was just a joke with some hyperbolic meaning. Record extracted from the plane black box just confirms that: """' ' ' ^~\_+. Regards, Vladimir Olensky. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-06 0:00 ` Robert Dewar 1999-06-07 0:00 ` Pascal F. Martin @ 1999-06-08 0:00 ` Robert A Duff 1 sibling, 0 replies; 57+ messages in thread From: Robert A Duff @ 1999-06-08 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > It is VERY important for Ada programmers to be aware of the > situations which lead to erroneous programs. You can easily > search through the RM to find all such cases. But it's not so easy to search through an Ada program to find all such cases. Some of them are global properties of the program. Of the two problems: programmers not knowing the language, and programmers who do know the language making mistakes anyway, I think the latter is the one to worry about most. The former can be solved by education; the latter has no known (complete) solution. > In fact I will repeat again my thought here. This is a VERY > marginal case of erroneousness. If you want to get into the > business of writing a "checkout" compiler that spends extra > time and space to check for as many erroneous situations as > possible, this is not at the top of the list for cases that > are useful to check! I agree. - Bob -- Change robert to bob to get my real email address. Sorry. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-07 0:00 ` Ada safety road Was: Which is right Vladimir Olensky 1999-06-06 0:00 ` Robert Dewar @ 1999-06-06 0:00 ` Larry Kilgallen 1999-06-07 0:00 ` Keith Thompson 1999-06-10 0:00 ` Ada safety road Was: Which is right Peter Amey 2 siblings, 1 reply; 57+ messages in thread From: Larry Kilgallen @ 1999-06-06 0:00 UTC (permalink / raw) In article <928703068.617.98@news.remarQ.com>, "Vladimir Olensky" <vladimir_olensky@yahoo.com> writes: > But I see one problem here. All this information is scattered around RM. In order to be definitive, the RM should not duplicate information in various locations, and thus cannot be in the ideal exposition format for all purposes. > I think that to facilitate safety programming such info should be gathered > into one paper > with explanations why it was not possible to overcome such situations and > it should contain many examples covering different aspects that leads to > erroneous execution. There should be no indirect references ("other then > ...."). Everything should be directly described and should be as simple as > possible. > I see it as some kind of "Ada safety programming roadmap". And of course > such paper should be easily available online for all interested in it. So > far I have not seen such document available online . Perhaps it is in a published book, or in one yet to be written -- perhaps by you. In another area, "Concurrency in Ada" has won high praise, even though it is a real book rather than just some ephemeral web site. Larry Kilgallen ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-06 0:00 ` Larry Kilgallen @ 1999-06-07 0:00 ` Keith Thompson 1999-06-07 0:00 ` Hyman Rosen ` (3 more replies) 0 siblings, 4 replies; 57+ messages in thread From: Keith Thompson @ 1999-06-07 0:00 UTC (permalink / raw) kilgallen@eisner.decus.org (Larry Kilgallen) writes: > In article <928703068.617.98@news.remarQ.com>, "Vladimir Olensky" <vladimir_olensky@yahoo.com> writes: > > But I see one problem here. All this information is scattered > > around RM. > > In order to be definitive, the RM should not duplicate information in > various locations, and thus cannot be in the ideal exposition format > for all purposes. The RM already has several "informative" annexes, which are not strictly part of the standard. Annexes K (attributes) and L (pragmas) are particularly useful, even though (or rather *because*) they duplicate information scattered around the RM. An informative annex listing all occurrences of erroneous execution and bounded errors would have been useful. As I was writing this, I realized we already have the next best thing. The entry for "erroneous" in the RM's index refers to all the places in the RM where the term is used; likewise for "bounded error". This brings up a pet peeve of mine: the word "erroneous" was a poor choice of terminology. It's an existing English word with a well-defined meaning. When I use the word in an Ada context, I very often have to explain the Ada-specific meaning. It also fails to make it clear that it's the execution of a construct that's erroneous, not the construct itself. Norman Cohen, in his book "Ada as a Second Language", uses the phrase "unbounded error", which is much clearer. Another good term is "undefined behavior", used by the C and C++ standards for (essentially) the same concept. If we could keep people from using the word "erroneous" outside the phrase "erroneous execution", there wouldn't be as much of a problem, but that's not going to happen. -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> San Diego Supercomputer Center <http://www.sdsc.edu> <*> One of the great tragedies of ancient history is that Helen of Troy lived before the invention of the champagne bottle. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-07 0:00 ` Keith Thompson @ 1999-06-07 0:00 ` Hyman Rosen 1999-06-08 0:00 ` Robert A Duff 1999-06-08 0:00 ` Robert A Duff ` (2 subsequent siblings) 3 siblings, 1 reply; 57+ messages in thread From: Hyman Rosen @ 1999-06-07 0:00 UTC (permalink / raw) Keith Thompson <kst@cts.com> writes: > This brings up a pet peeve of mine: the word "erroneous" was a poor > choice of terminology. ... > Another good term is "undefined behavior", used by the C and C++ > standards for (essentially) the same concept. If you follow the C++ newsgroups, you'll soon see that the same sort of people who are confused about "erroneous" are confused about "undefined" as well. They tend to mix it up with "implementation-defined", and get quite indignant when no one offers them any sympathy :-) For waht it's worth, I like "erroneous" better - it conveys to me the sense that I have done something wrong, whereas "undefined" conveys to me the sense that the language has forgotten something. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-07 0:00 ` Hyman Rosen @ 1999-06-08 0:00 ` Robert A Duff 1999-06-08 0:00 ` Keith Thompson ` (2 more replies) 0 siblings, 3 replies; 57+ messages in thread From: Robert A Duff @ 1999-06-08 0:00 UTC (permalink / raw) Hyman Rosen <hymie@prolifics.com> writes: > If you follow the C++ newsgroups, you'll soon see that the same sort of > people who are confused about "erroneous" are confused about "undefined" > as well. They tend to mix it up with "implementation-defined", and get > quite indignant when no one offers them any sympathy :-) Yeah, and I think the lesson for language designers is to try pretty hard to avoid language features with unpredictable semantics. It's not feasible to *completely* avoid them, but Ada comes pretty close, and I would prefer to get a little bit closer still. > For waht it's worth, I like "erroneous" better - it conveys to me the > sense that I have done something wrong, whereas "undefined" conveys to > me the sense that the language has forgotten something. But there's a huge difference between doing something wrong and having the compiler nicely point that out (either at compile time or at run time), and having totally unpredictable behavior, and "erroneous" doesn't capture that distinction in its normal English sense. There are few enough erroneous cases in Ada, that it would have been reasonable to spell it out in a long phrase every time. Something like, "If <RM-ese for dangling pointer>, the program is incorrect. The implementation is not required to detect this error, neither at compile time nor at run time. If this error occurs, execution is totally unpredictable." And then put some verbiage in chapter 1 about how awful "totally unpredictable" really is. - Bob -- Change robert to bob to get my real email address. Sorry. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-08 0:00 ` Robert A Duff @ 1999-06-08 0:00 ` Keith Thompson 1999-06-09 0:00 ` Robert Dewar 1999-06-09 0:00 ` dennison 1999-06-08 0:00 ` Ada safety road Was: Which is right Robert Dewar 1999-06-09 0:00 ` dennison 2 siblings, 2 replies; 57+ messages in thread From: Keith Thompson @ 1999-06-08 0:00 UTC (permalink / raw) Robert A Duff <bobduff@world.std.com> writes: [...] > There are few enough erroneous cases in Ada, that it would have been > reasonable to spell it out in a long phrase every time. Something like, > "If <RM-ese for dangling pointer>, the program is incorrect. The > implementation is not required to detect this error, neither at compile > time nor at run time. If this error occurs, execution is totally > unpredictable." And then put some verbiage in chapter 1 about how awful > "totally unpredictable" really is. The folks over in comp.std.c have a good term term for this: "nasal demons". This originated when someone observed that when the compiler encounters a construct with undefined behavior, it is legal for it to make demons fly out of your nose. See also the entry for "nasal demons" in The Jargon File and/or _The New Hacker's Dictionary_. Note that there's no implication that the compiler is *required* to make demons fly out of your nose. It's important to remember that one possible consequence of undefined behavior (or erroneous execution) is for the implementation to silently do exactly what you naively expected it to do. This is often the nastiest possibility, since any problems may not show up until years later. This is why the authors of Ada (both 83 and 95) made such an effort to minimize the number of cases where this can happen, and to clearly document the cases that couldn't reasonably be avoided. -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> San Diego Supercomputer Center <http://www.sdsc.edu> <*> One of the great tragedies of ancient history is that Helen of Troy lived before the invention of the champagne bottle. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-08 0:00 ` Keith Thompson @ 1999-06-09 0:00 ` Robert Dewar 1999-06-09 0:00 ` Tucker Taft 1999-06-09 0:00 ` dennison 1 sibling, 1 reply; 57+ messages in thread From: Robert Dewar @ 1999-06-09 0:00 UTC (permalink / raw) In article <yeclndu44z8.fsf@king.cts.com>, Keith Thompson <kst@cts.com> wrote: > This is why the authors of Ada (both 83 and 95) made such an > effort to minimize the number of cases where this can happen, > and to clearly document the cases that couldn't reasonably be > avoided. I think more could have been done, particularly in the area of uninitialized variables. For simple variables, I like the CDL approach which says that there must not exist any static paths through the program allowing a simple variable to be undefined (i.e. no ud chain can reach from a reference to a declaration with no initialization). This worked very well in CDL in practice (CDL = Koster's Compiler Definition Language). Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-09 0:00 ` Robert Dewar @ 1999-06-09 0:00 ` Tucker Taft 1999-06-09 0:00 ` Robert Dewar 0 siblings, 1 reply; 57+ messages in thread From: Tucker Taft @ 1999-06-09 0:00 UTC (permalink / raw) Robert Dewar wrote: > > In article <yeclndu44z8.fsf@king.cts.com>, > Keith Thompson <kst@cts.com> wrote: > > This is why the authors of Ada (both 83 and 95) made such an > > effort to minimize the number of cases where this can happen, > > and to clearly document the cases that couldn't reasonably be > > avoided. > > I think more could have been done, particularly in the area > of uninitialized variables. Using an uninitialized variable is *not* erroneous in Ada 95. > ... For simple variables, I like the > CDL approach which says that there must not exist any static > paths through the program allowing a simple variable to be > undefined (i.e. no ud chain can reach from a reference to a > declaration with no initialization). This worked very well > in CDL in practice (CDL = Koster's Compiler Definition > Language). I presume that Ada 95 compilers that try to properly avoid unpredictable behavior when an uninitialized variable is used do this kind of tracking to determine whether the variable *might* be uninitialized, and hence might be outside its declared range. Both GNAT and AdaMagic-based Ada 95 compilers seem to produce "uninitialized variable" warnings these days. At least in the AdaMagic-based compilers, that information is used to "bound" possible errors associated with using uninitialized variables, to avoid the dreaded erroneous/nose-demon situation. -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-09 0:00 ` Tucker Taft @ 1999-06-09 0:00 ` Robert Dewar 0 siblings, 0 replies; 57+ messages in thread From: Robert Dewar @ 1999-06-09 0:00 UTC (permalink / raw) In article <375E9592.32DA0709@averstar.com>, Tucker Taft <stt@averstar.com> wrote: > Robert Dewar wrote: > Using an uninitialized variable is *not* erroneous in Ada 95. OK, pedagogically correct, but let's see what the RM says 11 If the representation of the object does not represent a value of the object's type, the semantics of operations on such representations is implementation-defined, but does not by itself lead to erroneous or unpredictable execution, or to other objects becoming abnormal. OK, suppose that I have an implementation for the Alpha, where the normal code for division by a small constant uses a jump table depending on the constant value, and I do not feel like doing a constraint check, e.g. subtype q is range 1 .. 5; qv : q; x : integer := ... r : integer := x / qv; Now in my compiler documentation, the effect is implementation defined, so let me define it. When the division operation is executed, a four byte address is computed by loading the value from a table ..... control is then passed to the code at this four byte address. If the value is valid, the code will do the required division, if the value is invalid, you must inspect the generated object code to determine the actual code that will be executed. Very well defined! Completely predictable! Not erroneous! Completely RM compliant! But not very helpful :-( I perfectly well understand the attempt in the RM to cut back on erroneousness here, but I am afraid it is a bit bogus in this case. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-08 0:00 ` Keith Thompson 1999-06-09 0:00 ` Robert Dewar @ 1999-06-09 0:00 ` dennison 1999-06-09 0:00 ` Entamology of "Nasal Demons" dennison 1 sibling, 1 reply; 57+ messages in thread From: dennison @ 1999-06-09 0:00 UTC (permalink / raw) In article <yeclndu44z8.fsf@king.cts.com>, Keith Thompson <kst@cts.com> wrote: > The folks over in comp.std.c have a good term term for this: "nasal > demons". This originated when someone observed that when the compiler > encounters a construct with undefined behavior, it is legal for it to > make demons fly out of your nose. See also the entry for "nasal > demons" in The Jargon File and/or _The New Hacker's Dictionary_. That's interesting. I wonder if that came about indepedently from c.l.a.'s "nasal monkeys", or if one influenced the other. -- T.E.D. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Entamology of "Nasal Demons" 1999-06-09 0:00 ` dennison @ 1999-06-09 0:00 ` dennison 0 siblings, 0 replies; 57+ messages in thread From: dennison @ 1999-06-09 0:00 UTC (permalink / raw) In article <7jm185$mhf$1@nnrp1.deja.com>, dennison@telepath.com wrote: > In article <yeclndu44z8.fsf@king.cts.com>, > Keith Thompson <kst@cts.com> wrote: > > > The folks over in comp.std.c have a good term term for this: "nasal > > demons". This originated when someone observed that when the compiler > > encounters a construct with undefined behavior, it is legal for it to > > make demons fly out of your nose. See also the entry for "nasal > > demons" in The Jargon File and/or _The New Hacker's Dictionary_. > > That's interesting. I wonder if that came about indepedently from > c.l.a.'s "nasal monkeys", or if one influenced the other. I just went and looked it up myself. The earliest reference I could find to "making X fly out of Y's nose" was from a posting by Richard A. O'Keefe <ok@cs.rmit.edu.au> on 1995/08/04 in comp.lang.c.moderated. It may go back further than that, because dejanews doesn't keep messages much older than that. The first mention in comp.lang.ada was about 2 months later by Dan.Pop@mail.cern.ch (Dan Pop) in a thread crossposted from several other language newsgroups, including comp.lang.c. This is the post I saw. It did indeed mention "demons", not "monkeys". I must have been watching Wizard of Oz at the time. :-) The term "nasal demons" seems to have first appeared in another thread crossposted to c.l.a and c.l.c about 3 months later by Todd Knarr <tknarr@xmission.com> Deja is quite handy for wasting time in this manner. :-) -- T.E.D. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-08 0:00 ` Robert A Duff 1999-06-08 0:00 ` Keith Thompson @ 1999-06-08 0:00 ` Robert Dewar 1999-06-09 0:00 ` dennison 2 siblings, 0 replies; 57+ messages in thread From: Robert Dewar @ 1999-06-08 0:00 UTC (permalink / raw) In article <wcc674yh8ut.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: > Hyman Rosen <hymie@prolifics.com> writes: > Yeah, and I think the lesson for language designers is to try > pretty hard to avoid language features with unpredictable > semantics. It is easy to get in semantic knots on this issue. For example, it is reasonable to require a compiler to implement semantics where it is not predictable from the language what semantics will be implemented, but it is unreasonable to require a compiler to implement unpredictable semantics (subtle but important difference). Once at an Algol-68 meeting, Gerhard Goos asked exactly what undefined meant. Someone replied that it meant "unimaginable chaos", whereupon, Gerhard enquired as to just exactly how he was expected to implement "unimaginable chaos" in his compiler :-) Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-08 0:00 ` Robert A Duff 1999-06-08 0:00 ` Keith Thompson 1999-06-08 0:00 ` Ada safety road Was: Which is right Robert Dewar @ 1999-06-09 0:00 ` dennison 2 siblings, 0 replies; 57+ messages in thread From: dennison @ 1999-06-09 0:00 UTC (permalink / raw) In article <wcc674yh8ut.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: > But there's a huge difference between doing something wrong and having > the compiler nicely point that out (either at compile time or at run > time), and having totally unpredictable behavior, and "erroneous" > doesn't capture that distinction in its normal English sense. > > There are few enough erroneous cases in Ada, that it would have been > reasonable to spell it out in a long phrase every time. Something like, > time nor at run time. If this error occurs, execution is totally > unpredictable." And then put some verbiage in chapter 1 about how awful > "totally unpredictable" really is. I think we used to use the term "nasal monkeys" on c.l.a., to imply that in this situation the compiler was free to cause monkeys to fly out of the user's nose. Perhaps the RM should use that term. :-) -- T.E.D. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-07 0:00 ` Keith Thompson 1999-06-07 0:00 ` Hyman Rosen @ 1999-06-08 0:00 ` Robert A Duff 1999-06-08 0:00 ` Robert Dewar 1999-06-14 0:00 ` Ada safety road Franco Mazzanti 3 siblings, 0 replies; 57+ messages in thread From: Robert A Duff @ 1999-06-08 0:00 UTC (permalink / raw) Keith Thompson <kst@cts.com> writes: > The RM already has several "informative" annexes, which are not > strictly part of the standard. Annexes K (attributes) and L (pragmas) > are particularly useful, even though (or rather *because*) they > duplicate information scattered around the RM. Annexes K and L are automatically generated from the scattered text defining the various attributes and pragmas throughout the RM. > As I was writing this, I realized we already have the next best thing. > The entry for "erroneous" in the RM's index refers to all the places > in the RM where the term is used; likewise for "bounded error". In general, when I thought it would be useful to have a list of something-or-others gathered together in one place, I chose to put it in the index. This is compact enough that I could freely put in lots of useful lists, without worrying about making the document too big. There is at least one bug, unfortunately: the list under "configuration pragma" is missing pragma Discard_Names. > This brings up a pet peeve of mine: the word "erroneous" was a poor > choice of terminology. ... I agree. How many times have I had confusing discussions with non-Ada people, because they thought "erroneous" and "illegal" just mean "wrong", as opposed to a very particular kind of wrongness?! - Bob -- Change robert to bob to get my real email address. Sorry. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-07 0:00 ` Keith Thompson 1999-06-07 0:00 ` Hyman Rosen 1999-06-08 0:00 ` Robert A Duff @ 1999-06-08 0:00 ` Robert Dewar 1999-06-07 0:00 ` Keith Thompson 1999-06-08 0:00 ` Robert A Duff 1999-06-14 0:00 ` Ada safety road Franco Mazzanti 3 siblings, 2 replies; 57+ messages in thread From: Robert Dewar @ 1999-06-08 0:00 UTC (permalink / raw) In article <yecwvxfrb96.fsf@king.cts.com>, Keith Thompson <kst@cts.com> wrote: > This brings up a pet peeve of mine: the word "erroneous" was a > poor choice of terminology. It's an existing English word > with a well-defined meaning. When I use the word in an Ada > context, I very often have to explain the Ada-specific > meaning. The RM is *full* of ordinary english words used in a formal manner. You have to make clear that you are speaking this formal terminology when you do, and you should speak it only to the initiated :-) There are many cases where this can cause trouble, for example how many people think a generic package is a package (it is NOT, and this is critical in understanding the RM). Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-08 0:00 ` Robert Dewar @ 1999-06-07 0:00 ` Keith Thompson 1999-06-08 0:00 ` Robert A Duff 1 sibling, 0 replies; 57+ messages in thread From: Keith Thompson @ 1999-06-07 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > In article <yecwvxfrb96.fsf@king.cts.com>, > Keith Thompson <kst@cts.com> wrote: > > This brings up a pet peeve of mine: the word "erroneous" was a > > poor choice of terminology. It's an existing English word > > with a well-defined meaning. When I use the word in an Ada > > context, I very often have to explain the Ada-specific > > meaning. > > The RM is *full* of ordinary english words used in a formal > manner. You have to make clear that you are speaking this > formal terminology when you do, and you should speak it only > to the initiated :-) Agreed. I've just found that "erroneous" is the single most troublesome example, probably because its normal English meaning is so clearly applicable the same Ada code to which the technical term applies. -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> San Diego Supercomputer Center <http://www.sdsc.edu> <*> One of the great tragedies of ancient history is that Helen of Troy lived before the invention of the champagne bottle. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-08 0:00 ` Robert Dewar 1999-06-07 0:00 ` Keith Thompson @ 1999-06-08 0:00 ` Robert A Duff 1 sibling, 0 replies; 57+ messages in thread From: Robert A Duff @ 1999-06-08 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > The RM is *full* of ordinary english words used in a formal > manner. You have to make clear that you are speaking this > formal terminology when you do, and you should speak it only > to the initiated :-) There aren't many examples that are as misleading as "erroneous". I object to calling that type in Standard "Integer", as if God created only a few billion of them. And then we have to invent a new name, "universal integer" for God's integers. Sheesh. > There are many cases where this can cause trouble, for example > how many people think a generic package is a package (it is > NOT, and this is critical in understanding the RM). This doesn't bother me -- this is the way English works, and the RM is not being naughty here. A would-be king is not a king. A retired plumber is not a plumber. A bogus doctor is not a doctor. A former president is not a president. A non-partisan is not a partisan. On the other hand, "template" would be clearer than "generic". In fact, the very first paragraph of chapter 12 says, "A generic unit is template..." ;-) - Bob -- Change robert to bob to get my real email address. Sorry. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road 1999-06-07 0:00 ` Keith Thompson ` (2 preceding siblings ...) 1999-06-08 0:00 ` Robert Dewar @ 1999-06-14 0:00 ` Franco Mazzanti 1999-06-15 0:00 ` Franco Mazzanti 3 siblings, 1 reply; 57+ messages in thread From: Franco Mazzanti @ 1999-06-14 0:00 UTC (permalink / raw) Keith Thompson wrote: > > kilgallen@eisner.decus.org (Larry Kilgallen) writes: > > In article <928703068.617.98@news.remarQ.com>, "Vladimir Olensky" <vladimir_olensky@yahoo.com> writes: > > > But I see one problem here. All this information is scattered > > > around RM. > > > > In order to be definitive, the RM should not duplicate information in > > various locations, and thus cannot be in the ideal exposition format > > for all purposes. > > The RM already has several "informative" annexes, which are not > strictly part of the standard. Annexes K (attributes) and L (pragmas) > are particularly useful, even though (or rather *because*) they > duplicate information scattered around the RM. An informative annex > listing all occurrences of erroneous execution and bounded errors > would have been useful. > > As I was writing this, I realized we already have the next best thing. > The entry for "erroneous" in the RM's index refers to all the places > in the RM where the term is used; likewise for "bounded error". > > This brings up a pet peeve of mine: the word "erroneous" was a poor > choice of terminology. It's an existing English word with a > well-defined meaning. When I use the word in an Ada context, I very > often have to explain the Ada-specific meaning. It also fails to make > it clear that it's the execution of a construct that's erroneous, not > the construct itself. Norman Cohen, in his book "Ada as a Second > Language", uses the phrase "unbounded error", which is much clearer. > Another good term is "undefined behavior", used by the C and C++ > standards for (essentially) the same concept. > ... Some time ago I did that job of collecting from all the RM all this kind of information related to erroneous executions. It took a long time, and it has been a much harder job rather than what initially expected, but in the end I think I succeded in getting the whole picture. If anybody is interested, the report can downloaded by anonymous ftp from: ftp://rep1.iei.pi.cnr.it/pub/mazzanti/publications/EEG.ps (it is an IEI report) Some printed copies are also available under request. It is almost two years old, so some details concerning new or recently revised Ada Commentaries may be absent. Any comments on that report are still welcome. Franco Mazzanti Istituto di Elaborazione della Informazione Via S.Maria 46, 56126 Pisa, ITALY Tel: +39050-593447/593400, Fax: +39-50-554342 e-mail: mazzanti@iei.pi.cnr.it ------------------------------------------------------------ ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road 1999-06-14 0:00 ` Ada safety road Franco Mazzanti @ 1999-06-15 0:00 ` Franco Mazzanti 1999-06-16 0:00 ` Vladimir Olensky 0 siblings, 1 reply; 57+ messages in thread From: Franco Mazzanti @ 1999-06-15 0:00 UTC (permalink / raw) > Some time ago I did that job of collecting from all the RM all this > kind of information related to erroneous executions. It took a long > time, > and it has been a much harder job rather than what initially expected, > but in the end I think I succeded in getting the whole picture. > If anybody is interested, the report can downloaded by anonymous ftp > from: > ftp://rep1.iei.pi.cnr.it/pub/mazzanti/publications/EEG.ps > (it is an IEI report) > Thanks to Jim Hopper, now a pdf version of the same report is also available: ftp://rep1.iei.pi.cnr.it/pub/mazzanti/publications/EEG.pdf Franco Mazzanti ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road 1999-06-15 0:00 ` Franco Mazzanti @ 1999-06-16 0:00 ` Vladimir Olensky 0 siblings, 0 replies; 57+ messages in thread From: Vladimir Olensky @ 1999-06-16 0:00 UTC (permalink / raw) Franco Mazzanti wrote in message <37660F7A.870D2A3A@tin.it>... > >> Some time ago I did that job of collecting from all the RM all this >> kind of information related to erroneous executions. It took a long >> time, >> and it has been a much harder job rather than what initially expected, >> but in the end I think I succeded in getting the whole picture. >> If anybody is interested, the report can downloaded by anonymous ftp >> from: >> ftp://rep1.iei.pi.cnr.it/pub/mazzanti/publications/EEG.ps >> (it is an IEI report) >> > >Thanks to Jim Hopper, now a pdf version of the same report is also >available: > ftp://rep1.iei.pi.cnr.it/pub/mazzanti/publications/EEG.pdf > >Franco Mazzanti I looked through your report and I was really impressed. This is what I had in mind (and may be even more) talking about such kind of document in my previous posts. This is very comprehensive document and it is really Ada safety roadmap. Your report and ISO N359 document can provide great help to those using Ada in making their software more reliable. Best regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-07 0:00 ` Ada safety road Was: Which is right Vladimir Olensky 1999-06-06 0:00 ` Robert Dewar 1999-06-06 0:00 ` Larry Kilgallen @ 1999-06-10 0:00 ` Peter Amey 1999-06-10 0:00 ` Markus Kuhn 2 siblings, 1 reply; 57+ messages in thread From: Peter Amey @ 1999-06-10 0:00 UTC (permalink / raw) Vladimir Olensky wrote: > > Robert Dewar wrote in message <7jb1l9$694$1@nnrp1.deja.com>... > > >And to repeat, since you keep repeating the subject, both > >GNAT and OA are right here, and do what the RM intends! > > Sorry, It just didn't come up to my mind to change the subject. > Even original subject was not very adequate to what I had in mind > I really did not had intention on insisting which is better in following RM. > > I had other things in mind. > > I was just thinking about different aspects of providing some > general kind of "foolproofness" to program written in Ada in places where RM > define program behavior as erroneous. > I think nobody would like to be on a plane that performed erroneous flight > """' ' ' ^~\_+. > Anyone would prefer to be accidentally on board of the wrong flight instead. > > One good aspect of Ada is that when it is impossible to provide compiler > solution to some problems (due to implementation cost and some other reasons > that may not be very obvious) LRM at least honestly specifies situations > when erroneous execution is possible. > > But I see one problem here. All this information is scattered around RM. > > I think that to facilitate safety programming such info should be gathered > into one paper > with explanations why it was not possible to overcome such situations and > it should contain many examples covering different aspects that leads to > erroneous execution. There should be no indirect references ("other then > ...."). Everything should be directly described and should be as simple as > possible. > I see it as some kind of "Ada safety programming roadmap". And of course > such paper should be easily available online for all interested in it. So > far I have not seen such document available online . > If you crossing mine field and you do not have good map with red marks on it > all your life depends on your luck :-) > Such type of documents are usually top level documents in design of any > safety critical system (at least it was in my experience). > [snip] > Regards, > > Vladimir Olensky There certainly has been some work in this area. At a pragmatic level there is the Ada HRG which has produced (under auspices of ISO) a guidance document on the use of Ada in high-intergrity systems. The document identifies language features and combinations of features which are most likely to complicate reasoning about the behaviour of Ada programs; clearly this includes behaviour which might be erroneous. At a more rigorous level, the SPARK language makes it possible to construct programs which can be shown, prior to execution, to be free from _any_ erroneous behaviour; this includes proving that the program will not raise any predefined exceptions. Peter -- --------------------------------------------------------------------------- __ Peter Amey, Product Manager ) Praxis Critical Systems Ltd / 20, Manvers Street, Bath, BA1 1PX / 0 Tel: +44 (0)1225 466991 (_/ Fax: +44 (0)1225 469006 http://www.praxis-cs.co.uk/ -------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-10 0:00 ` Ada safety road Was: Which is right Peter Amey @ 1999-06-10 0:00 ` Markus Kuhn 1999-06-11 0:00 ` Vladimir Olensky 0 siblings, 1 reply; 57+ messages in thread From: Markus Kuhn @ 1999-06-10 0:00 UTC (permalink / raw) Peter Amey <pna@praxis-cs.co.uk> writes: |> There certainly has been some work in this area. At a pragmatic level |> there is the Ada HRG which has produced (under auspices of ISO) a |> guidance document on the use of Ada in high-intergrity systems. The |> document identifies language features and combinations of features which |> are most likely to complicate reasoning about the behaviour of Ada |> programs; clearly this includes behaviour which might be erroneous. This document is freely available from http://www.dkuug.dk/JTC1/SC22/WG9/n359.pdf Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/> ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-10 0:00 ` Markus Kuhn @ 1999-06-11 0:00 ` Vladimir Olensky 1999-06-12 0:00 ` Robert Dewar 0 siblings, 1 reply; 57+ messages in thread From: Vladimir Olensky @ 1999-06-11 0:00 UTC (permalink / raw) Markus Kuhn wrote in message <7jo1d2$kno$1@pegasus.csx.cam.ac.uk>... >Peter Amey <pna@praxis-cs.co.uk> writes: >|> There certainly has been some work in this area. At a pragmatic level >|> there is the Ada HRG which has produced (under auspices of ISO) a >|> guidance document on the use of Ada in high-intergrity systems. The >|> document identifies language features and combinations of features which >|> are most likely to complicate reasoning about the behaviour of Ada >|> programs; clearly this includes behaviour which might be erroneous. > >This document is freely available from > > http://www.dkuug.dk/JTC1/SC22/WG9/n359.pdf > I looked through it and found it very useful. I was talking exactly about such kind of document (may be more comprehensive though). What is interesting it was published only 30 days ago (99-05-11). It itself contains a lot of useful references. What is good that it is an official Ada ISO document. This document (and it's home) should be referenced from each Ada related site. Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-11 0:00 ` Vladimir Olensky @ 1999-06-12 0:00 ` Robert Dewar 1999-06-12 0:00 ` JP Thornley 1999-06-13 0:00 ` Vladimir Olensky 0 siblings, 2 replies; 57+ messages in thread From: Robert Dewar @ 1999-06-12 0:00 UTC (permalink / raw) In article <929128919.557.95@news.remarQ.com>, "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: > I was talking exactly about such kind of document (may be more > comprehensive though). I am really not sure how this document could be more comprehensive. Perhaps you miss the point, which is that it is VERY specifically aimed at safety critical programming in Ada, and is not for a moment a general style document. In fact safety-critical programming is a rather specialized area, so although I agree this document is very valuable, I am not quite sure I share your view of its universal applicability! Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-12 0:00 ` Robert Dewar @ 1999-06-12 0:00 ` JP Thornley 1999-06-13 0:00 ` Vladimir Olensky 1999-06-16 0:00 ` William Dale 1999-06-13 0:00 ` Vladimir Olensky 1 sibling, 2 replies; 57+ messages in thread From: JP Thornley @ 1999-06-12 0:00 UTC (permalink / raw) In article: <7jsdkf$v3p$1@nnrp1.deja.com> Robert Dewar <robert_dewar@my-deja.com> writes: (with reference to the HRG Guidance) > it is VERY specifically aimed at safety critical programming > in Ada Definitely not so - and if this becomes the accepted idea then a number of programmers are likely to ignore a very useful document. (Particularly if they take Robert's other comments to mean that safety-critical programming is an arcane art with little connection to the 'real-world'). The Guide is _aimed at_ producers of high integrity software, where the software supplier is (usually) required to demonstrate the integrity of the software to a third party (who may be a certification authority or, perhaps, a knowledgeable customer). It is _useful to_ anyone who wants to make consistent use of one or more of the verification methods referenced in the Guide as it helps them to avoid language features that are difficult to verify by the chosen techniques. (All of the usual techniques are included in the Guide.) In another message, "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: > What is interesting it was published only 30 days ago (99-05-11). Yes, but that is simply the latest in a long line of minor revisions. The document has been largely unchanged for over a year - an earlier draft was published in Ada Letters last year (may have been around April/May) and there are some detailed changes from that version, but nothing major. Phil Thornley -- ------------------------------------------------------------------------ | JP Thornley EMail jpt@diphi.demon.co.uk | | phil.thornley@acm.org | ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-12 0:00 ` JP Thornley @ 1999-06-13 0:00 ` Vladimir Olensky 1999-06-16 0:00 ` William Dale 1 sibling, 0 replies; 57+ messages in thread From: Vladimir Olensky @ 1999-06-13 0:00 UTC (permalink / raw) JP Thornley wrote in message <489533776wnr@diphi.demon.co.uk>... >In article: <7jsdkf$v3p$1@nnrp1.deja.com> Robert Dewar ><robert_dewar@my-deja.com> writes: > >(with reference to the HRG Guidance) > >> it is VERY specifically aimed at safety critical programming >> in Ada > >Definitely not so - and if this becomes the accepted idea then a number >of programmers are likely to ignore a very useful document. >(Particularly if they take Robert's other comments to mean that >safety-critical programming is an arcane art with little connection to >the 'real-world'). > >The Guide is _aimed at_ producers of high integrity software, where the >software supplier is (usually) required to demonstrate the integrity of >the software to a third party (who may be a certification authority or, >perhaps, a knowledgeable customer). > >It is _useful to_ anyone who wants to make consistent use of one or more >of the verification methods referenced in the Guide as it helps them to >avoid language features that are difficult to verify by the chosen >techniques. (All of the usual techniques are included in the Guide.) Suport all said above. > >In another message, "Vladimir Olensky" <vladimir_olensky@yahoo.com> >wrote: >> What is interesting it was published only 30 days ago (99-05-11). > >Yes, but that is simply the latest in a long line of minor revisions. >The document has been largely unchanged for over a year - an earlier >draft was published in Ada Letters last year (may have been around >April/May) and there are some detailed changes from that version, but >nothing major. I've seen N350 also. To my point of view one of the problems with it was that it was not widely advertised. The other thing is an erroneous idea that writing reliable software is VERY specialized area. Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-12 0:00 ` JP Thornley 1999-06-13 0:00 ` Vladimir Olensky @ 1999-06-16 0:00 ` William Dale 1999-06-19 0:00 ` JP Thornley 1999-06-21 0:00 ` Robert A Duff 1 sibling, 2 replies; 57+ messages in thread From: William Dale @ 1999-06-16 0:00 UTC (permalink / raw) JP Thornley wrote: > > In article: <7jsdkf$v3p$1@nnrp1.deja.com> Robert Dewar > <robert_dewar@my-deja.com> writes: > > (with reference to the HRG Guidance) > > > it is VERY specifically aimed at safety critical programming > > in Ada > > Definitely not so - and if this becomes the accepted idea then a number > of programmers are likely to ignore a very useful document. > (Particularly if they take Robert's other comments to mean that > safety-critical programming is an arcane art with little connection to > the 'real-world'). > > The Guide is _aimed at_ producers of high integrity software, where the > software supplier is (usually) required to demonstrate the integrity of > the software to a third party (who may be a certification authority or, > perhaps, a knowledgeable customer). > > It is _useful to_ anyone who wants to make consistent use of one or more > of the verification methods referenced in the Guide as it helps them to > avoid language features that are difficult to verify by the chosen > techniques. (All of the usual techniques are included in the Guide.) > I hope the document covers the system trade-offs of going through such rigorous and costly certifications when a simple hardware addition would make the system safe. Too often the software effort is forced to shoulder the entire burden of system safety. Gutting language features to make software certifiable is often coupled with irrational fear of new features and technology. Many times it still does not make for a "safe" system. When safety certified applications sit on top of untested operating systems and amidst other COTS applications disaster is possible, maybe probible. [snip] -- "The difference between hardware and software is that the more you play with hardware, the more likely you are to break it, but the more you play with software the more likely you are to FIX it." Bill Dale LMMS mailto:william.dale.jr@lmco.com mailto:N2RHV@amsat.org ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-16 0:00 ` William Dale @ 1999-06-19 0:00 ` JP Thornley 1999-06-21 0:00 ` Robert A Duff 1 sibling, 0 replies; 57+ messages in thread From: JP Thornley @ 1999-06-19 0:00 UTC (permalink / raw) In article: <37682F64.59E2@lmco.com> William Dale <william.dale.jr@lmco.com> writes: [with reference to the HRG Guidance) > I hope the document covers the system trade-offs of going through > such rigorous and costly certifications when a simple hardware addition > would make the system safe. Well, since I said that: "The Guide is _aimed at_ producers of high integrity software, where the software supplier is (usually) required to demonstrate the integrity of the software", it is difficult to see why anyone would expect to see discussions of system safety and the choice of hardware solutions in the Guide. > > Too often the software effort is forced to shoulder the entire > burden of system safety. Gutting language features to make software > certifiable is often coupled with irrational fear of new features > and technology. The Guide makes no recommendations based on the newness of language features. What it does is to analyse the interaction between the verification techniques used for software and the features of Ada 95, pointing out those language features that will make each technique either difficult or impossible to apply. > > Many times it still does not make for a "safe" system. When safety > certified applications sit on top of untested operating systems > and amidst other COTS applications disaster is possible, > maybe probible. But surely no application can be certified other than as part of a complete system - which must include the operating system/other COTS components. Safety is an attribute of a system, never of software. > > Bill Dale > > Phil Thornley -- ------------------------------------------------------------------------ | JP Thornley EMail jpt@diphi.demon.co.uk | | phil.thornley@acm.org | ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-16 0:00 ` William Dale 1999-06-19 0:00 ` JP Thornley @ 1999-06-21 0:00 ` Robert A Duff 1 sibling, 0 replies; 57+ messages in thread From: Robert A Duff @ 1999-06-21 0:00 UTC (permalink / raw) William Dale <william.dale.jr@lmco.com> writes: >... Gutting language features to make software > certifiable is often coupled with irrational fear of new features > and technology. ... and sometimes with a rational fear of new features and technology. ;-) > "The difference between hardware and software is that the more you play > with hardware, the more likely you are to break it, but the more you > play with software the more likely you are to FIX it." Hmm. Unfortunately, that's not always true. - Bob -- Change robert to bob to get my real email address. Sorry. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-12 0:00 ` Robert Dewar 1999-06-12 0:00 ` JP Thornley @ 1999-06-13 0:00 ` Vladimir Olensky 1999-06-12 0:00 ` Matthew Heaney ` (2 more replies) 1 sibling, 3 replies; 57+ messages in thread From: Vladimir Olensky @ 1999-06-13 0:00 UTC (permalink / raw) Robert Dewar wrote in message <7jsdkf$v3p$1@nnrp1.deja.com>... >In article <929128919.557.95@news.remarQ.com>, > "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: >> I was talking exactly about such kind of document (may be more >> comprehensive though). > >I am really not sure how this document could be more >comprehensive. Perhaps you miss the point, which is that >it is VERY specifically aimed at safety critical programming >in Ada, and is not for a moment a general style document. > >In fact safety-critical programming is a rather specialized >area, so although I agree this document is very valuable, >I am not quite sure I share your view of its universal >applicability! > Please read more carefully other people posts prior to making claims that someone has missed the point. Many people have heard this more than once :-( It seems that we have here one person who thinks that he never misses the point :-) Let's join the club :-) As a matter of fact I was talking "about such kind of document " that I had in mind when I did not know about N359. To my point of view this document (N359) is extremely valuable and every self-respected engineer who has something to do with Ada (or intends to do) should have it at hand. This document could be considered as general guidance for writing reliable software in Ada (and not only in Ada). Unfortunately N350 which is a draft of N359 has not been advertised across Ada WEB sites so it seems that not too many Ada people were aware of it. Otherwise I would get Markus Kuhn response with reference to N359 from someone else next after I mentioned about "such kind of document". I could not agree that writing reliable software is specialized area. Just contrary I think that this is universal area. Remember how many people are complaining that something is unreliable for example - Windows NT. But a lot of people just forget that any OS should protect itself. If some application is doing something wrong WinNT just kills it (and no problems any more). So complains should be about badly (or not very professional) written applications. So much mentioned "blue dreaded screen" is usually cased (in 99.9%) by third party device drivers or services that have access to protected OS resources and are doing something wrong. So writing reliable software is indeed universal area and this means that person/team that is doing something should know all things that can cause unpredictable behavior (in Programming Language and used OS). This also means that they should know as much as possible about how "not to do" in order to provide reliability. This is universal law as well. In order not to make mistakes one should learn other's mistakes or summary of such experience. In real life this is of course a little bit different . Some people are not even able to learn their own mistakes. Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-13 0:00 ` Vladimir Olensky @ 1999-06-12 0:00 ` Matthew Heaney 1999-06-13 0:00 ` Vladimir Olensky 1999-06-13 0:00 ` Robert Dewar 1999-06-13 0:00 ` Robert Dewar 2 siblings, 1 reply; 57+ messages in thread From: Matthew Heaney @ 1999-06-12 0:00 UTC (permalink / raw) On 13 Jun 1999 01:10, "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: > To my point of view this document (N359) is extremely valuable and > every self-respected engineer who has something to do with Ada (or > intends to do) should have it at hand. I haven't read the document, so maybe it's time. Can someone post a full citation, with instructions about how to get a copy? Thanks, Matt ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-12 0:00 ` Matthew Heaney @ 1999-06-13 0:00 ` Vladimir Olensky 0 siblings, 0 replies; 57+ messages in thread From: Vladimir Olensky @ 1999-06-13 0:00 UTC (permalink / raw) Matthew Heaney wrote in message ... >On 13 Jun 1999 01:10, "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: > >> To my point of view this document (N359) is extremely valuable and >> every self-respected engineer who has something to do with Ada (or >> intends to do) should have it at hand. > >I haven't read the document, so maybe it's time. Can someone post a >full citation, with instructions about how to get a copy? N359 ISO/IEC DTR 15942. Programming Languages -- Guide for the Use of the Ada Programming Language in High Integrity Systems This document is freely available from http://www.dkuug.dk/JTC1/SC22/WG9/n359.pdf This reference was originally posted by Markus Kuhn. Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-13 0:00 ` Vladimir Olensky 1999-06-12 0:00 ` Matthew Heaney @ 1999-06-13 0:00 ` Robert Dewar 1999-06-13 0:00 ` Vladimir Olensky 1999-06-13 0:00 ` Robert Dewar 2 siblings, 1 reply; 57+ messages in thread From: Robert Dewar @ 1999-06-13 0:00 UTC (permalink / raw) In article <929221844.567.59@news.remarQ.com>, "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: > Unfortunately N350 which is a draft of N359 has not been > advertised across Ada WEB sites so it seems that not too many > Ada people were aware of it. Otherwise I would get Markus Kuhn > response with reference to N359 from someone else next after I > mentioned about "such kind of document". I think it was publicized at an appropriate level. This was basically work in progress by one of the Rapporteur Groups of WG9, and it is not appropriate to put it out for any kind of official public comment before it has been submitted to WG9. Most certainly the HRG has been quite open in the way it proceeds, at quite an appropriate level, but posting drafts to CLA is certainly NOT appropriate in my view. Each country decides for itself the extent to which it will subject such ISO documents to general review. In the case of the USA, there were several experts in the area of high integrity programming participating in the HRG, and I think there was adequate input. > I could not agree that writing reliable software is > specialized area. No, but writing high integrity software *IS* more specialized. If you decide that reliable = high integrity then you reduce the discussion of special concerns of high integrity programming to general discussions of good style for writing reliable Ada programs, and I think this is far too much of a dilution of the intentions here. > Just contrary I think that this is universal area. Concern for reliability is universal. Use of restricted subsets of Ada for high integrity programs is NOT a universal area at all. > Remember how many people are complaining that something is > unreliable for > example - Windows NT. No one for a moment would claim OR EXPECT Windows NT to qualify as high integrity software, and indeed it would be out of the question for high integrity software to be based on the use of NT in my view. Indeed only a VERY simple operating executive could reach the level of being certified as high integrity software. Remember that one important aspect of high integrity software is that in general it must be verified at the object machine instruction level (because we also do not have trusted Ada compilers, and indeed we do not know how to build a trusted Ada compiler). To verify a program like NT at this level (with its 5-10 million lines of code) is out of the question at our current level of technology. A typical productivity level for high integrity code is, according to several people in the field (this is not from my personal experience) of the order of 1-2 machine instructions per person day. That means that the 10 million lines of code in NT might take 10 million person days = 50,000 person years = a very long time to get a product out (and perhaps 10 billion dollars). Quite a bit even for Microsoft, but of course such calculations are bogus, since these things don't scale, and we just don't know how to build high integrity programs this large (look at Dave Parnas' statements concering SDI, this was a substantial part of his concerns about the credibility of the software component of this system as originally proposed). Now please do not misunderstand, I think everyone should read the HRG report (I would assume that any Ada professional should always read all official documents from ISO WG9), and there may be useful things to be learned from the document that have wider applicability. But I think you have to be careful not to go in the direction that Vladimir does, confusing the specific focus of this document with the generalized need for realiability. Remember that the WHOLE of the Ada language was carefully designed to be compatible with the goal of writing highly reliable programs. There is almost NO feature mentioned in the RM that does not have a legitimate use in reliable Ada programs. I am worried that people will start looking at the recommendations in the HRG report for restricting the use of Ada for high integrity programming (a realistic and necessary step) and make the mistake of thinking that this means that these features are generally unsafe if your goal is to write reliable programs. Robert Dewar Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-13 0:00 ` Robert Dewar @ 1999-06-13 0:00 ` Vladimir Olensky 0 siblings, 0 replies; 57+ messages in thread From: Vladimir Olensky @ 1999-06-13 0:00 UTC (permalink / raw) Robert Dewar wrote in message <7jvc2j$o68$1@nnrp1.deja.com>... >In article <929221844.567.59@news.remarQ.com>, > "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: > >No, but writing high integrity software *IS* more specialized. > >If you decide that > > reliable = high integrity > >then you reduce the discussion of special concerns of high >integrity programming to general discussions of good style >for writing reliable Ada programs, and I think this is far >too much of a dilution of the intentions here. > >> Just contrary I think that this is universal area. > >Concern for reliability is universal. >Use of restricted subsets of Ada for high integrity programs >is NOT a universal area at all. ************ I am not trying to set the rule that "reliable = high integrity". There are a lot of intermediate levels between them. N359 just helps to choose appropriate approach for particular design goal. Again I would like to stress that there should not be a black and white approaches. ************* >> Remember how many people are complaining that something is >> unreliable for >> example - Windows NT. > >No one for a moment would claim OR EXPECT Windows NT to qualify >as high integrity software, and indeed it would be out of the >question for high integrity software to be based on the use >of NT in my view. Indeed only a VERY simple operating executive >could reach the level of being certified as high integrity >software. > >Remember that one important aspect of high integrity software >is that in general it must be verified at the object machine >instruction level (because we also do not have trusted Ada >compilers, and indeed we do not know how to build a trusted >Ada compiler). To verify a program like NT at this level (with >its 5-10 million lines of code) is out of the question at our >current level of technology. > >A typical productivity level for high integrity code is, >according to several people in the field (this is not from >my personal experience) of the order of 1-2 machine instructions >per person day. > >That means that the 10 million lines of code in NT might take >10 million person days = 50,000 person years = a very long >time to get a product out (and perhaps 10 billion dollars). >Quite a bit even for Microsoft, but of course such calculations >are bogus, since these things don't scale, and we just don't >know how to build high integrity programs this large (look at >Dave Parnas' statements concering SDI, this was a substantial >part of his concerns about the credibility of the software >component of this system as originally proposed). *************** Here I was just saying that in many cases some people blame OS instead of blaming badly written applications (especially in OS flames). As for me I am using WinNT as an equipment control center that runs (7 days 24 hours) a dozen of applications controlling different pieces of equipment along with number of "run and stop" applications. It never crashed during last three years ( it was put into operation three years ago). ********** >Now please do not misunderstand, I think everyone should read >the HRG report (I would assume that any Ada professional should >always read all official documents from ISO WG9), and there may >be useful things to be learned from the document that have wider >applicability. > >But I think you have to be careful not to go in the direction >that Vladimir does, confusing the specific focus of this >document with the generalized need for realiability. ********** Direction is to fully understand all strong and weak sides and to chose consciously what is needed for particular purpose. ************ >Remember that the WHOLE of the Ada language was carefully >designed to be compatible with the goal of writing highly >reliable programs. There is almost NO feature mentioned in >the RM that does not have a legitimate use in reliable Ada >programs. ******* I mentioned once about some kind of trap here. Some people may have wrong im pression that Ada is so reliable itself that there is no need of careful consideration of potentially unsafe features. Sometimes even safe features can cause problems. I have an impression that developers of Arian 5 were caught in such kind of trap and as result they did not do what was needed. *********** >I am worried that people will start looking at the >recommendations in the HRG report for restricting the >use of Ada for high integrity programming (a realistic and >necessary step) and make the mistake of thinking that this >means that these features are generally unsafe if your goal >is to write reliable programs. There are people and people. Some take any written paper as direct instructions. Others understand that it is just summary of other people knowledge and experience. Such kind of documents could help to safely use some potentially unsafe features. Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-13 0:00 ` Vladimir Olensky 1999-06-12 0:00 ` Matthew Heaney 1999-06-13 0:00 ` Robert Dewar @ 1999-06-13 0:00 ` Robert Dewar 1999-06-13 0:00 ` Vladimir Olensky 1999-06-13 0:00 ` swhalen 2 siblings, 2 replies; 57+ messages in thread From: Robert Dewar @ 1999-06-13 0:00 UTC (permalink / raw) In article <929221844.567.59@news.remarQ.com>, "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: > > Robert Dewar wrote in message <7jsdkf$v3p$1@nnrp1.deja.com>... > >In article <929128919.557.95@news.remarQ.com>, > > "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: > >> I was talking exactly about such kind of document (may be more > >> comprehensive though). > > > >I am really not sure how this document could be more > >comprehensive. Perhaps you miss the point, which is that > >it is VERY specifically aimed at safety critical programming > >in Ada, and is not for a moment a general style document. > > > >In fact safety-critical programming is a rather specialized > >area, so although I agree this document is very valuable, > >I am not quite sure I share your view of its universal > >applicability! > > Please read more carefully other people posts prior to making > claims that > someone has missed the point. > Many people have heard this more than once :-( > It seems that we have here one person who thinks that he never > misses the point :-) > Let's join the club :-) > > As a matter of fact I was talking "about such kind of document " that I had > in mind when I did not know about N359. > I could not agree that writing reliable software is > specialized area. > Just contrary I think that this is universal area. There is a big difference between high integrity software (yes, most certainly safety critical is a little too restrictive) and the general notion of reliable software. All software should be written in a reliable manner, and using techniques that promote reliability. The danger of making the jump from high integrity to realiable with such facility, is that the next thing you know, managers decide that the kind of restrictions that are suggested in the HRG document are appropriate for general purpose programming if "realiability" is important. Since reliability is ALWAYS important this will mean that we get more of the disease of arbitrarily forbidding critical Ada constructs under the illusion that it helps! I have more than once run into situations where people write a chunk of a program in C because some nitwit manager has forbidden the use of (e.g.) unchecked conversion completely. Validimir, it was you who said you thought the HRG document could be more comprehensive -- what did you mean? Remember that the HRG has a very restrictive mandate. As it's name implies it is in the specific business of looking at issues related to Annex H, the Safety and Security annex of the standard. It is not at all the case that the document at hand is in any sense a general prescription for all Ada programming, and if people read it with this (mis)understanding, then it is a pity, because this very valuable (in context) document may end up resulting in some significant negative effects. So there's the question Vladimir -- to make your position VERY clear, explain your criticism of the HRG document, namely that it is not comprehensive, by giving examples where you think it is lacking. My point of view is that this document is an excellent AND complete summary statement of what is needed for high integrity programming in Ada. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-13 0:00 ` Robert Dewar @ 1999-06-13 0:00 ` Vladimir Olensky 1999-06-13 0:00 ` swhalen 1 sibling, 0 replies; 57+ messages in thread From: Vladimir Olensky @ 1999-06-13 0:00 UTC (permalink / raw) Robert Dewar wrote in message <7jvakl$nqi$1@nnrp1.deja.com>... >In article <929221844.567.59@news.remarQ.com>, > "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: >> As a matter of fact I was talking "about such kind of >document " that I had >> in mind when I did not know about N359. >> I could not agree that writing reliable software is >> specialized area. >> Just contrary I think that this is universal area. >There is a big difference between high integrity software >(yes, most certainly safety critical is a little too >restrictive) and the general notion of reliable software. > >All software should be written in a reliable manner, and using >techniques that promote reliability. > >The danger of making the jump from high integrity to realiable >with such facility, is that the next thing you know, managers >decide that the kind of restrictions that are suggested in the >HRG document are appropriate for general purpose programming >if "realiability" is important. Since reliability is ALWAYS >important this will mean that we get more of the disease of >arbitrarily forbidding critical Ada constructs under the >illusion that it helps! >I have more than once run into situations where people write >a chunk of a program in C because some nitwit manager has >forbidden the use of (e.g.) unchecked conversion completely. There are managers and managers. We have here one saying that tells that "manager_position + manager_knowledge=CONSTANT" that just confirms what you said above. Of course it is not an universal law but it has some connection to reality. And of course it is easily explained. > >Remember that the HRG has a very restrictive mandate. As it's >name implies it is in the specific business of looking at issues >related to Annex H, the Safety and Security annex of the >standard. It is not at all the case that the document at hand is >in any sense a general prescription for all Ada programming, and >if people read it with this (mis)understanding, then it is a >pity, because this very valuable (in context) document may end >up resulting in some significant negative effects. > I think that there should not be black and white approach. There should be just full understanding and feeling of all things that may cause problems. Clearly defined design goals also help to define appropriate approach to resolve them. Here one association comes up to my mind - combination of M3 opaque types and UNSAFE modules that help to avoid black and white approach. > >Validimir, it was you who said you thought the HRG document >could be more comprehensive -- what did you mean? >So there's the question Vladimir -- to make your position VERY >clear, explain your criticism of the HRG document, namely that >it is not comprehensive, by giving examples where you think it >is lacking. I was not criticizing N359 at all. Instead I stated that it is an excellent document. When I didn't new about it I was thinking that there is a need in document that covers all aspects of possible erroneous execution of Ada program (including some number of examples). Check my previous posts. So I was talking not about HRG document. I was talking what I had in mind. When I was given reference to N359 I found that it is up to almost all my expectation about such paper. One should not expect more from ISO official document. It is not a tutorial it is a guidance. Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada safety road Was: Which is right ... 1999-06-13 0:00 ` Robert Dewar 1999-06-13 0:00 ` Vladimir Olensky @ 1999-06-13 0:00 ` swhalen 1 sibling, 0 replies; 57+ messages in thread From: swhalen @ 1999-06-13 0:00 UTC (permalink / raw) Robert Dewar (robert_dewar@my-deja.com) wrote: : : There is a big difference between high integrity software : (yes, most certainly safety critical is a little too : restrictive) and the general notion of reliable software. : : All software should be written in a reliable manner, and using : techniques that promote reliability. : : The danger of making the jump from high integrity to... [snip] : I have more than once run into situations where people write : a chunk of a program in C because some nitwit manager has : forbidden the use of (e.g.) unchecked conversion completely. Many excellent points and much useful information in this thread. I agree with those who believe that the 359 document should be "pushed" more widely in the Ada community. I take your point that over emphasis of "high integrity" processes like those described in the 359 document can lead to unintended consequences or needless expense or even failed projects. However, in many systems there are portions of the system that MUST be more reliable and robust and trusted than the rest of the system. The techniques and processes described in the "high integrity" document may be entirely appropriate for a small portion of a larger system. By applying the "high integrity" processes and $$$ to a small portion of a larger system, you can greatly increase overall reliablity and improve the value of the system, even if the system is not in one of the categories of systems we typically think of as requiring "high integrity". Steve -- {===--------------------------------------------------------------===} Steve Whalen swhalen@netcom.com {===--------------------------------------------------------------===} ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Which is right here - GNAT or OA ? 1999-05-30 0:00 ` Florian Weimer 1999-05-31 0:00 ` Vladimir Olensky @ 1999-06-01 0:00 ` Tucker Taft 1 sibling, 0 replies; 57+ messages in thread From: Tucker Taft @ 1999-06-01 0:00 UTC (permalink / raw) Florian Weimer wrote: > ... > Another but related thing surprises me---it's AARM 12.5.4(4.a): > > | If no _modifier applies to the formal, then the actual type may be > | either a pool-specific or a general access-to-variable type. > > I can't imagine any reason why an access-to-variable type should be > allowed as an actual parameter for a formal access type without an > `all' modifier. If this was changed, an access-to-variable would not be > allowed as a parameter in an instantiation of Ada.Unchecked_Deallocation, > which seems quite reasonable to me. (I don't claim that the language > definition inadequate here, I simply can't make sense out of it, which > is very likely my own fault. ;) You may be parsing the sentence incorrectly. It is saying that the actual type may be a (pool-specific or general) access-to-variable type. It certainly must be an access-to-variable type, unless the "constant" modifier is present. By omitting the "all" modifier, you are allowing either kind of access-to-variable type, pool-specific or general. Within the generic unit, the formal type is considered pool-specific. This works because the capabilities of a pool-specific access type are a subset of the capabilities of a general access type. This is analogous to the way "limited" is used in generic formal types. If present, either a limited or a non-limited actual type is used. If the word "limited" is absent, then only a non-limited actual type may be used. In general, a formal type specifies the minimum set of properties required. It is safe to provide an actual type with more properties than what is presumed for the formal. -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Which is right here - GNAT or OA ? 1999-05-30 0:00 Which is right here - GNAT or OA ? Vladimir Olensky 1999-05-30 0:00 ` Florian Weimer @ 1999-05-30 0:00 ` Robert Dewar 1999-05-31 0:00 ` Vladimir Olensky 1999-06-01 0:00 ` dennison 1999-05-31 0:00 ` David Botton 1999-06-03 0:00 ` Matthew Heaney 3 siblings, 2 replies; 57+ messages in thread From: Robert Dewar @ 1999-05-30 0:00 UTC (permalink / raw) In article <928083159.436.79@news.remarQ.com>, "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: This is definitely an RTFM case. The RM says 16 Evaluating a name that denotes a nonexistent object is erroneous. The execution of a call to an instance of Unchecked_Deallocation is erroneous if the object was created other than by an allocator for an access type whose pool is Name'Storage_Pool. So this programs is erroneous, and given that, OA and GNAT behave identically, namely they give unpredictable results. No other definition would make sense in the language, you don't want lots of elaborate checks going for an "unchecked" feature! Note that you have to be careful in the ase of controlled objects not to try to free statically allocated stuff. This is a user responsibility in writing the Finalize routine! Various tools will detect an attempt to free something that has never been allocated. For example the gnatmem tool supplied with GNAT will immediately detect that your program here is wrong. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Which is right here - GNAT or OA ? 1999-05-30 0:00 ` Robert Dewar @ 1999-05-31 0:00 ` Vladimir Olensky 1999-05-31 0:00 ` Robert Dewar 1999-06-01 0:00 ` dennison 1 sibling, 1 reply; 57+ messages in thread From: Vladimir Olensky @ 1999-05-31 0:00 UTC (permalink / raw) Robert Dewar wrote in message <7is6pt$8cd$1@nnrp1.deja.com>... >In article <928083159.436.79@news.remarQ.com>, > "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: > >Note that you have to be careful in the ase of controlled >objects not to try to free statically allocated stuff. This >is a user responsibility in writing the Finalize routine! > That's right and the very purpose of this small example (one among some others) was to to illustrate why it is necessary distinguish between statically allocated and dynamically allocated objects when using controlled types for user defined automatic objects deallocation (GB) to provide proper program behavior. I doing this in other examples and this one is explaining why it is necessary. I mentioned that I am doing such checks few months ago in the thread related to Garbage Collection that arise from time to time here. At that time I was wondering if it possible for compiler itself to provide some additional compile time info so that RTS could perform such check later without necessity to do it manually. I still think that it is possible and that this is one of the necessary steps on the way of implementing full featured GB. Even without system GB it can make life easier for programmers. As I mentioned I did this stuff long time ago and now I want to put some pieces of code to Adapower as "touch and feel" ready to use examples of using controlled types. "Touch and feel" is one the best ways to explain things. Someone who wants to know can try "touch and feel" example see the output read short explanations end comments and as a result he/she will have internal feeling related to that subject. >So this programs is erroneous, and given that, OA and >GNAT behave identically, namely they give unpredictable >results. As I explained in the first message and in here above it erroneous on purpose. It helps to explain why one should check if the variable is static prior to attempt do deallocate it doing finalization (what is being done in my other examples related to use of controlled types) . I only thought that both GNAT and OA will raise exception at the same Statement_1. OA is raising exception at -- Statement_1: ( free(q_ptr)); but GNAT performing it without any complains and after that pointer to that record get NULL value but object continue to exists. So at -- Statement_2: Put( (q1.ID),2) GNAT is extracting field from the record and printing it without no problems. Statement_3 was to show that when q_ptr has NULL value exception should be raised here. ------------------- Regards, Vladimir Ylensky ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Which is right here - GNAT or OA ? 1999-05-31 0:00 ` Vladimir Olensky @ 1999-05-31 0:00 ` Robert Dewar 0 siblings, 0 replies; 57+ messages in thread From: Robert Dewar @ 1999-05-31 0:00 UTC (permalink / raw) In article <928136551.707.11@news.remarQ.com>, "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: > As I explained in the first message and in here above it > erroneous on purpose. Sorry, Vladimir, but your message is still in the archives, we don't have to rely on memory a) it made no mention of erreoneous b) it complained that the RM does not handle this case (it does, quite clearly) c) it complained that the behavior of OA and GNAT were different, and asked which is right (the subject of this thread is your invention). The complaint is invalid and the question is meaningless. You cannot make any comments or complaints about the behavior of an erroneous program execution or expect any consistency d) it suggested a semantics quite different from the RM for this case, one which would in fact be entirely impractical and certainly undesirable. > It helps to explain why one should check if the variable is > static prior to attempt do deallocate This is highly misleading, you must do this check NOT because different compilers happen to do different things, but because it is erroneous not to do this check, as the RM clearly states. The results of experiments with erroneous programs cannot possibly have any legitimate influence whatsoever on how you code your program. > I only thought that both GNAT and OA will raise exception at > the same Statement_1. That would tend to indicate that you do not understand what erroneous means. Erroneous is a well defined technical term, it does not just mean wrong, or improper. To expect or think that compilers should or will behave consistently on erroneous programs is to misunderstand the definition of erroneous. > Statement_3 was to show that when q_ptr has NULL value > exception should be raised here. Nope! You cannot make ANY statement WHATSOEVER about expectations form an erroneous program execution. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Which is right here - GNAT or OA ? 1999-05-30 0:00 ` Robert Dewar 1999-05-31 0:00 ` Vladimir Olensky @ 1999-06-01 0:00 ` dennison 1 sibling, 0 replies; 57+ messages in thread From: dennison @ 1999-06-01 0:00 UTC (permalink / raw) In article <7is6pt$8cd$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> wrote: > So this programs is erroneous, and given that, OA and > GNAT behave identically, namely they give unpredictable > results. Yikes. I hope I haven't set a bad trend here in posting a couple of queries about why Gnat and OA don't handle the same constructs in the same way. A fair bit about Ada is still implementation dependent. And of course whenever you (ab)use UNCHECKED_anything, all bets are off. There are certianly situations where its OK for different compilers to behave differently. -- T.E.D. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Which is right here - GNAT or OA ? 1999-05-30 0:00 Which is right here - GNAT or OA ? Vladimir Olensky 1999-05-30 0:00 ` Florian Weimer 1999-05-30 0:00 ` Robert Dewar @ 1999-05-31 0:00 ` David Botton 1999-06-01 0:00 ` dennison 1999-06-03 0:00 ` Matthew Heaney 3 siblings, 1 reply; 57+ messages in thread From: David Botton @ 1999-05-31 0:00 UTC (permalink / raw) Thank you for the compliments! I am a big believer in learning through example. If you or any one tried to post new articles, or e-mail me yesterday (5/30/99) from 8am to 10pm EST, I lost it and never saw it. There was a glitch in some code I was writing to burn spam up that ended up burning up all the mail. Sorry. David Botton In article <928083159.436.79@news.remarQ.com>, "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: > Recently I found some time to prepare for "AdaPower" some > "touch and feel" examples (just brushing up my old exercises) on > using controlled types for user defined GB which could be useful > for people learning Ada. It is one of the ways to attract new > people to Ada by explaining very simply some things > that may seem very difficult. > > I mentioned about my simple user GB examples few months ago in GB > thread but then I had no time to prepare them for open use. > Then there was nice article about smart pointers by > Mathew Heaney describing the same issue and I did not feel like > adding anything else to this subject. > Then AdaPower come to the existence (thanks to David Button) > and I felt that it is better late than never. > Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Which is right here - GNAT or OA ? 1999-05-31 0:00 ` David Botton @ 1999-06-01 0:00 ` dennison 0 siblings, 0 replies; 57+ messages in thread From: dennison @ 1999-06-01 0:00 UTC (permalink / raw) In article <7iu2oj$gvh$1@nnrp2.deja.com>, David Botton <dbotton@my-deja.com> wrote: > If you or any one tried to post new articles, or e-mail me yesterday > (5/30/99) from 8am to 10pm EST, I lost it and never saw it. There was a > glitch in some code I was writing to burn spam up that ended up burning > up all the mail. Sorry. For just that reason, my filter doesn't delete email tagged as "spam". It just tosses it in a "junk" drawer, to be perused at my leisure. Every now and then an important message makes its way in there. -- T.E.D. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Which is right here - GNAT or OA ? 1999-05-30 0:00 Which is right here - GNAT or OA ? Vladimir Olensky ` (2 preceding siblings ...) 1999-05-31 0:00 ` David Botton @ 1999-06-03 0:00 ` Matthew Heaney 3 siblings, 0 replies; 57+ messages in thread From: Matthew Heaney @ 1999-06-03 0:00 UTC (permalink / raw) "Vladimir Olensky" <vladimir_olensky@yahoo.com> writes: > ---------------------------------- > -- Which is right here - GNAT or OA ? > --------------------------------- Both are, because the language doesn't specify what happens when you try to deallocate an object on the stack. Your code is erroneous. > I mentioned about my simple user GB examples few months ago in GB > thread but then I had no time to prepare them for open use. Then > there was nice article about smart pointers by Mathew Heaney > describing the same issue and I did not feel like adding anything else > to this subject. My philosophy is to declare the type in such a way so that the user has to use the type's allocator, and can't declare the object on the stack: type T (<>) is limited private; type T_Access is access all T; function New_T return T_Access; procedure Free (O : in out T_Access); procedure Op1 (O : access T); Using this technique, the problem you describe cannot happen. ^ permalink raw reply [flat|nested] 57+ messages in thread
end of thread, other threads:[~1999-06-21 0:00 UTC | newest] Thread overview: 57+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-05-30 0:00 Which is right here - GNAT or OA ? Vladimir Olensky 1999-05-30 0:00 ` Florian Weimer 1999-05-31 0:00 ` Vladimir Olensky 1999-05-31 0:00 ` Robert Dewar 1999-06-05 0:00 ` Vladimir Olensky 1999-06-05 0:00 ` Florian Weimer 1999-06-05 0:00 ` Vladimir Olensky 1999-06-05 0:00 ` Robert Dewar 1999-06-07 0:00 ` Ada safety road Was: Which is right Vladimir Olensky 1999-06-06 0:00 ` Robert Dewar 1999-06-07 0:00 ` Pascal F. Martin 1999-06-07 0:00 ` Vladimir Olensky 1999-06-08 0:00 ` Robert A Duff 1999-06-06 0:00 ` Larry Kilgallen 1999-06-07 0:00 ` Keith Thompson 1999-06-07 0:00 ` Hyman Rosen 1999-06-08 0:00 ` Robert A Duff 1999-06-08 0:00 ` Keith Thompson 1999-06-09 0:00 ` Robert Dewar 1999-06-09 0:00 ` Tucker Taft 1999-06-09 0:00 ` Robert Dewar 1999-06-09 0:00 ` dennison 1999-06-09 0:00 ` Entamology of "Nasal Demons" dennison 1999-06-08 0:00 ` Ada safety road Was: Which is right Robert Dewar 1999-06-09 0:00 ` dennison 1999-06-08 0:00 ` Robert A Duff 1999-06-08 0:00 ` Robert Dewar 1999-06-07 0:00 ` Keith Thompson 1999-06-08 0:00 ` Robert A Duff 1999-06-14 0:00 ` Ada safety road Franco Mazzanti 1999-06-15 0:00 ` Franco Mazzanti 1999-06-16 0:00 ` Vladimir Olensky 1999-06-10 0:00 ` Ada safety road Was: Which is right Peter Amey 1999-06-10 0:00 ` Markus Kuhn 1999-06-11 0:00 ` Vladimir Olensky 1999-06-12 0:00 ` Robert Dewar 1999-06-12 0:00 ` JP Thornley 1999-06-13 0:00 ` Vladimir Olensky 1999-06-16 0:00 ` William Dale 1999-06-19 0:00 ` JP Thornley 1999-06-21 0:00 ` Robert A Duff 1999-06-13 0:00 ` Vladimir Olensky 1999-06-12 0:00 ` Matthew Heaney 1999-06-13 0:00 ` Vladimir Olensky 1999-06-13 0:00 ` Robert Dewar 1999-06-13 0:00 ` Vladimir Olensky 1999-06-13 0:00 ` Robert Dewar 1999-06-13 0:00 ` Vladimir Olensky 1999-06-13 0:00 ` swhalen 1999-06-01 0:00 ` Which is right here - GNAT or OA ? Tucker Taft 1999-05-30 0:00 ` Robert Dewar 1999-05-31 0:00 ` Vladimir Olensky 1999-05-31 0:00 ` Robert Dewar 1999-06-01 0:00 ` dennison 1999-05-31 0:00 ` David Botton 1999-06-01 0:00 ` dennison 1999-06-03 0:00 ` Matthew Heaney
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox