* Recommendation of safe subset of Ada to use? @ 2018-05-05 21:23 joakimds 2018-05-05 21:32 ` gorgelo ` (2 more replies) 0 siblings, 3 replies; 13+ messages in thread From: joakimds @ 2018-05-05 21:23 UTC (permalink / raw) Jere gave the following example in the other thread about how to get Ada across the chasm: 1. Dangling references: Keeping a reference to an object past its lifetime Ada: *********************************************** with Ada.Text_IO; use Ada.Text_IO; procedure jdoodle is type Integer_Access is access all Integer; function Inner(Value : aliased in out Integer) return Integer_Access is begin return Value'Access; end Inner; function Outer return Integer_Access is Value : aliased Integer := 0; begin return Inner(Value); end Outer; Ptr : Integer_Access := Outer; -- !!! Dangling reference begin Put_Line("Hello World"); end jdoodle; *********************************************** Hello World gcc -c jdoodle.adb gnatbind -x jdoodle.ali gnatlink jdoodle.ali -o jdoodle It's a 20 line application that demonstrates a dangling pointer in Ada. That's not supposed to be able to happen unless one goes outside of Ada's type system by using Unchecked_Deallocation, Unchecked_Conversion or System.Address_To_Access_Conversion. I've tried the example with the GNAT compiler and it does not detect the issue. I do not believe this is a GNAT bug. Aliased parameters were part of the solution to be able to safely reference elements in containers and thereby avoid unnecessary copying. By making this possible was a hole in Adas type system introduced? It means that one cannot safely use all the features of Ada and be sure of memory safety instead one should stick to a subset of Ada. One subset that comes to mind is SPARK. Another is for example sticking to Ada95 or Ada 2005. Or maybe one should just ban usage of aliased parameters but then what should one do with the standard containers that one probably uses throughout one's application. I am confused. Anybody that can shed light? /Joakim ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Recommendation of safe subset of Ada to use? 2018-05-05 21:23 Recommendation of safe subset of Ada to use? joakimds @ 2018-05-05 21:32 ` gorgelo 2018-05-06 7:43 ` Jeffrey R. Carter 2018-05-07 15:54 ` onox 2018-05-08 0:06 ` Randy Brukardt 2 siblings, 1 reply; 13+ messages in thread From: gorgelo @ 2018-05-05 21:32 UTC (permalink / raw) G.B. wrote in the other thread the following on this topic: > 1. Dangling references: Keeping a reference to an object past its lifetime > > Ada: > *********************************************** > with Ada.Text_IO; use Ada.Text_IO; > > procedure jdoodle is > type Integer_Access is access all Integer; > > function Inner(Value : aliased in out Integer) return Integer_Access is > begin > return Value'Access; > end Inner; > > function Outer return Integer_Access is > Value : aliased Integer := 0; > begin > return Inner(Value); > end Outer; > > Ptr : Integer_Access := Outer; -- !!! Dangling reference > begin > Put_Line("Hello World"); > end jdoodle; Anything that can be done to prevent the above effect should be welcome, if it is representative of what the 2012 RM allows. Or is this new *aliased* parameter thing some I-know-what-I-am-doing Ada? So, do explicitly *aliased* parameters indeed break all accessiblity rules of Ada? I noticed that it is mentioned in the RM alongside parameters that are passed by reference already because their type is a by-reference type. I'd expect then, that one would drop *aliased* for those kinds of type, thus 27. with Ada.Text_IO; use Ada.Text_IO; 28. 29. procedure jdoodle2 is 30. type T is tagged 31. record 32. Data : Integer; 33. end record; 34. 35. type T_Access is access all T; 36. 37. function Inner(Value : in out T) return T_Access is 38. begin 39. return Value'Access; | >>> non-local pointer cannot point to local object 40. end Inner; 41. 42. function Outer return T_Access is 43. Value : aliased T := T'(Data => 0); 44. begin 45. return Inner(Value); 46. end Outer; 47. 48. Ptr : T_Access := Outer; 49. begin 50. Put_Line("Hello World"); 51. end jdoodle2; The same dangling pointer effect reappears, however, when I put *aliased* back, for no apparent reason: function Inner(Value : aliased in out T) return T_Access is begin return Value'Access; end Inner; ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Recommendation of safe subset of Ada to use? 2018-05-05 21:32 ` gorgelo @ 2018-05-06 7:43 ` Jeffrey R. Carter 2018-05-06 8:45 ` Niklas Holsti ` (2 more replies) 0 siblings, 3 replies; 13+ messages in thread From: Jeffrey R. Carter @ 2018-05-06 7:43 UTC (permalink / raw) On 05/05/2018 11:32 PM, gorgelo@hotmail.com wrote: >> with Ada.Text_IO; use Ada.Text_IO; >> >> procedure jdoodle is >> type Integer_Access is access all Integer; >> >> function Inner(Value : aliased in out Integer) return Integer_Access is >> begin >> return Value'Access; >> end Inner; >> >> function Outer return Integer_Access is >> Value : aliased Integer := 0; >> begin >> return Inner(Value); >> end Outer; >> >> Ptr : Integer_Access := Outer; -- !!! Dangling reference >> begin >> Put_Line("Hello World"); >> end jdoodle; This seems to violate ARM 3.10.2(29): the accessibility level of Value (the object passed by reference to Inner) is deeper than that of the access type Integer_Access. I cannot find an exception to this for aliased parameters. -- Jeff Carter "It is the German who is so uncourteous to his verbs." A Scandal in Bohemia 122 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Recommendation of safe subset of Ada to use? 2018-05-06 7:43 ` Jeffrey R. Carter @ 2018-05-06 8:45 ` Niklas Holsti 2018-05-06 8:52 ` gorgelo 2018-05-06 13:15 ` Jere 2 siblings, 0 replies; 13+ messages in thread From: Niklas Holsti @ 2018-05-06 8:45 UTC (permalink / raw) On 18-05-06 10:43 , Jeffrey R. Carter wrote: > On 05/05/2018 11:32 PM, gorgelo@hotmail.com wrote: >>> with Ada.Text_IO; use Ada.Text_IO; >>> >>> procedure jdoodle is >>> type Integer_Access is access all Integer; >>> function Inner(Value : aliased in out Integer) return >>> Integer_Access is >>> begin >>> return Value'Access; >>> end Inner; >>> function Outer return Integer_Access is >>> Value : aliased Integer := 0; >>> begin >>> return Inner(Value); >>> end Outer; >>> Ptr : Integer_Access := Outer; -- !!! Dangling reference >>> begin >>> Put_Line("Hello World"); >>> end jdoodle; > > This seems to violate ARM 3.10.2(29): the accessibility level of Value > (the object passed by reference to Inner) is deeper than that of the > access type Integer_Access. I cannot find an exception to this for > aliased parameters. My GNAT complains: > gcc -c -g -gnat12 jdoodle.adb jdoodle.adb:8:16: non-local pointer cannot point to local object gnatmake: "jdoodle.adb" compilation error However, this is GNAT GPL 2012 (don't ask me why I still use this...) -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Recommendation of safe subset of Ada to use? 2018-05-06 7:43 ` Jeffrey R. Carter 2018-05-06 8:45 ` Niklas Holsti @ 2018-05-06 8:52 ` gorgelo 2018-05-06 13:15 ` Jere 2 siblings, 0 replies; 13+ messages in thread From: gorgelo @ 2018-05-06 8:52 UTC (permalink / raw) Thanks for the feedback. I have reported the issue to AdaCore. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Recommendation of safe subset of Ada to use? 2018-05-06 7:43 ` Jeffrey R. Carter 2018-05-06 8:45 ` Niklas Holsti 2018-05-06 8:52 ` gorgelo @ 2018-05-06 13:15 ` Jere 2018-05-06 13:47 ` Jere 2 siblings, 1 reply; 13+ messages in thread From: Jere @ 2018-05-06 13:15 UTC (permalink / raw) On Sunday, May 6, 2018 at 3:43:11 AM UTC-4, Jeffrey R. Carter wrote: > On 05/05/2018 11:32 PM, gorgelo wrote: > >> with Ada.Text_IO; use Ada.Text_IO; > >> > >> procedure jdoodle is > >> type Integer_Access is access all Integer; > >> > >> function Inner(Value : aliased in out Integer) return Integer_Access is > >> begin > >> return Value'Access; > >> end Inner; > >> > >> function Outer return Integer_Access is > >> Value : aliased Integer := 0; > >> begin > >> return Inner(Value); > >> end Outer; > >> > >> Ptr : Integer_Access := Outer; -- !!! Dangling reference > >> begin > >> Put_Line("Hello World"); > >> end jdoodle; > > This seems to violate ARM 3.10.2(29): the accessibility level of Value (the > object passed by reference to Inner) is deeper than that of the access type > Integer_Access. I cannot find an exception to this for aliased parameters. > > -- > Jeff Carter > "It is the German who is so uncourteous to his verbs." > A Scandal in Bohemia > 122 How would you interpret 3.10.2 (7/4)? It just says it doesn't have the same accessibility level as the master. I haven't found anything to suggest what the accessibility level should be at that point. I'll admit, I haven't grasped what the full meaning is. 3.10.2 (7/4): An entity or view defined by a declaration and created as part of its elaboration has the same accessibility level as the innermost master of the declaration except in the cases of renaming and derived access types described below. Other than for an explicitly aliased parameter of a function or generic function, a formal parameter of a callable entity has the same accessibility level as the master representing the invocation of the entity. The other question is what is the purpose of the aliased keyword for function parameters? My impression from reading emails here and some of the rationale was that it was so they could more easily take access values from containers. 3.10.2(29) would seem to go against that since most access types are defined at library level and a lot of containers are declared inside of some function whether that be main (they don't have to be I know, they can be declared at library level as well). ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Recommendation of safe subset of Ada to use? 2018-05-06 13:15 ` Jere @ 2018-05-06 13:47 ` Jere 2018-05-06 21:28 ` Brad Moore 0 siblings, 1 reply; 13+ messages in thread From: Jere @ 2018-05-06 13:47 UTC (permalink / raw) On Sunday, May 6, 2018 at 9:15:42 AM UTC-4, Jere wrote: > On Sunday, May 6, 2018 at 3:43:11 AM UTC-4, Jeffrey R. Carter wrote: > > On 05/05/2018 11:32 PM, gorgelo wrote: > > >> with Ada.Text_IO; use Ada.Text_IO; > > >> > > >> procedure jdoodle is > > >> type Integer_Access is access all Integer; > > >> > > >> function Inner(Value : aliased in out Integer) return Integer_Access is > > >> begin > > >> return Value'Access; > > >> end Inner; > > >> > > >> function Outer return Integer_Access is > > >> Value : aliased Integer := 0; > > >> begin > > >> return Inner(Value); > > >> end Outer; > > >> > > >> Ptr : Integer_Access := Outer; -- !!! Dangling reference > > >> begin > > >> Put_Line("Hello World"); > > >> end jdoodle; > > > > This seems to violate ARM 3.10.2(29): the accessibility level of Value (the > > object passed by reference to Inner) is deeper than that of the access type > > Integer_Access. I cannot find an exception to this for aliased parameters. > > > > -- > > Jeff Carter > > "It is the German who is so uncourteous to his verbs." > > A Scandal in Bohemia > > 122 > > How would you interpret 3.10.2 (7/4)? It just says it doesn't have the same > accessibility level as the master. I haven't found anything to suggest > what the accessibility level should be at that point. I'll admit, I > haven't grasped what the full meaning is. Trying to piece this together from the RM: 6.4.1 (6.4/3): In a function call, the accessibility level of the actual object for each explicitly aliased parameter shall not be statically deeper than the accessibility level of the master of the call (see 3.10.2). The only reference to how the accessibility level of the master was determined that I could fine was in 6.10.2 (10.1/3): 10.1/3 The accessibility level of the result of a function call is that of the master of the function call, which is determined by the point of call as follows: 10.2/3 If the result is used (in its entirety) to directly initialize part of an object, the master is that of the object being initialized. In the case where the initialized object is a coextension (see below) that becomes a coextension of another object, the master is that of the eventual object to which the coextension will be transferred. 10.3/3 If the result is of an anonymous access type and is the operand of an explicit conversion, the master is that of the target type of the conversion; 10.4/3 If the result is of an anonymous access type and defines an access discriminant, the master is the same as that for an object created by an anonymous allocator that defines an access discriminant (even if the access result is of an access-to-subprogram type). 10.5/3 If the call itself defines the result of a function to which one of the above rules applies, these rules are applied recursively; 10.6/3 In other cases, the master of the call is that of the innermost master that evaluates the function call. I know this is meant to define the level for the result, but it also is the only part that I could find that defines the level of the master of the call. Here it would seem that 10.6/3 would apply? Reading the RM is rough! Any help out there? ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Recommendation of safe subset of Ada to use? 2018-05-06 13:47 ` Jere @ 2018-05-06 21:28 ` Brad Moore 2018-05-08 0:19 ` Randy Brukardt 0 siblings, 1 reply; 13+ messages in thread From: Brad Moore @ 2018-05-06 21:28 UTC (permalink / raw) On Sunday, May 6, 2018 at 7:48:02 AM UTC-6, Jere wrote: > On Sunday, May 6, 2018 at 9:15:42 AM UTC-4, Jere wrote: > > On Sunday, May 6, 2018 at 3:43:11 AM UTC-4, Jeffrey R. Carter wrote: > > > On 05/05/2018 11:32 PM, gorgelo wrote: > > > >> with Ada.Text_IO; use Ada.Text_IO; > > > >> > > > >> procedure jdoodle is > > > >> type Integer_Access is access all Integer; > > > >> > > > >> function Inner(Value : aliased in out Integer) return Integer_Access is > > > >> begin > > > >> return Value'Access; > > > >> end Inner; > > > >> > > > >> function Outer return Integer_Access is > > > >> Value : aliased Integer := 0; > > > >> begin > > > >> return Inner(Value); > > > >> end Outer; > > > >> > > > >> Ptr : Integer_Access := Outer; -- !!! Dangling reference > > > >> begin > > > >> Put_Line("Hello World"); > > > >> end jdoodle; > > > > > > This seems to violate ARM 3.10.2(29): the accessibility level of Value (the > > > object passed by reference to Inner) is deeper than that of the access type > > > Integer_Access. I cannot find an exception to this for aliased parameters. > > > > > > -- > > > Jeff Carter > > > "It is the German who is so uncourteous to his verbs." > > > A Scandal in Bohemia > > > 122 > > > > How would you interpret 3.10.2 (7/4)? It just says it doesn't have the same > > accessibility level as the master. I haven't found anything to suggest > > what the accessibility level should be at that point. I'll admit, I > > haven't grasped what the full meaning is. > > Trying to piece this together from the RM: > > 6.4.1 (6.4/3): > In a function call, the accessibility level of the actual object for each > explicitly aliased parameter shall not be statically deeper than the > accessibility level of the master of the call (see 3.10.2). > > The only reference to how the accessibility level of the master was > determined that I could fine was in > 6.10.2 (10.1/3): > 10.1/3 > The accessibility level of the result of a function call is that of the master > of the function call, which is determined by the point of call as follows: > 10.2/3 > If the result is used (in its entirety) to directly initialize part of an object, > the master is that of the object being initialized. In the case where the initialized > object is a coextension (see below) that becomes a coextension of another object, > the master is that of the eventual object to which the coextension will be transferred. > 10.3/3 > If the result is of an anonymous access type and is the operand of an explicit > conversion, the master is that of the target type of the conversion; > 10.4/3 > If the result is of an anonymous access type and defines an access discriminant, > the master is the same as that for an object created by an anonymous allocator > that defines an access discriminant (even if the access result is of an > access-to-subprogram type). > 10.5/3 > If the call itself defines the result of a function to which one of the above > rules applies, these rules are applied recursively; > 10.6/3 > In other cases, the master of the call is that of the innermost master that > evaluates the function call. > > I know this is meant to define the level for the result, but it also is the > only part that I could find that defines the level of the master of the call. > Here it would seem that 10.6/3 would apply? > > Reading the RM is rough! Any help out there? It's rough where you are looking. But I think you should be looking more at 3.10.2, as that is where the accessibility rules are defined, and its not going to get any less rough over there either. But before you do that, you might want to read this quote from the AARM. See 3.10.2 (3.b/3) Subclause 3.10.2, home of the accessibility rules, is informally known as the “Heart of Darkness” amongst the maintainers of Ada. Woe unto all who enter here (well, at least unto anyone that needs to understand any of these rules)." This is because, probably only a very small handful of people on this planet actually truly understand the rules. I am not one of those, though I try my best, when I need to. And those that do, it is only for a fleeting moment. It typically requires a deep dive into the Heart of Darkness. If you reach enlightenment, consider yourself lucky. Randy would be one of the lucky people, but even he will avoid diving into the Heart of Darkness if he doesn't need to :-) I think one of the main advantages of the aliased keyword on subprogram parameters, is that it means there is much less need to use access types. You can now, for the most part, keep access types hidden in the private part or body of a package, and not expose access types in the public part of the package specification. Users of a package do not have to deal with access types, when this design convention is in place. I think it is a good design principle to strive to not expose access types in the public part of a package. With earlier versions of Ada, it was much harder to avoid doing this. That is largely the case with the containers. The users of the container packages normally shouldn't need to mess with access types. Also, offhand, I think the problem originally posted above is a compiler bug, that should be fixed. Brad ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Recommendation of safe subset of Ada to use? 2018-05-06 21:28 ` Brad Moore @ 2018-05-08 0:19 ` Randy Brukardt 2018-05-08 8:07 ` Simon Wright 0 siblings, 1 reply; 13+ messages in thread From: Randy Brukardt @ 2018-05-08 0:19 UTC (permalink / raw) "Brad Moore" <bmoore.ada@gmail.com> wrote in message news:6e66aa5f-9ce0-4f28-ae1b-9bdfeb500a79@googlegroups.com... ... >See 3.10.2 (3.b/3) > >Subclause 3.10.2, home of the accessibility rules, is informally known as >the "Heart of Darkness" amongst the maintainers of Ada. Woe unto all >who enter here (well, at least unto anyone that needs to understand any >of these rules)." > >This is because, probably only a very small handful of people on this >planet >actually truly understand the rules. I am not one of those, though I try my >best, when I need to. And those that do, it is only for a fleeting moment. >It >typically requires a deep dive into the Heart of Darkness. If you reach >enlightenment, consider yourself lucky. ...and you ought to immediately join the ARG to help the rest of us out... ;-) >Randy would be one of the lucky people, but even he will avoid diving into >the Heart of Darkness if he doesn't need to :-) Thanks, I think. ;-) In this particular case, I know the intent because I ended up designing this feature. I was able to explain it to Tucker well enough that he agreed that the rules were right and sufficient. But whether the wording actually says what was meant is hardly known. The intent for explicitly aliased function parameters is that the accessibility check moves to the call. (Note that that doesn't happen for procedures, because there's no return object and no return accessibility.) So that object has to live longer than the function result; the call to Inner in this example doesn't do that and thus it is illegal. Note that examples of this case were included in ACATS test B641002, including one that looks nearly identical to the OP's example. That was issued in March 2014, so it's quite possible for older compilers to not make the check. If a new compiler doesn't make the check, definitely complain to your vendor and tell 'em I sent you. :-) Randy. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Recommendation of safe subset of Ada to use? 2018-05-08 0:19 ` Randy Brukardt @ 2018-05-08 8:07 ` Simon Wright 0 siblings, 0 replies; 13+ messages in thread From: Simon Wright @ 2018-05-08 8:07 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > Note that examples of this case were included in ACATS test B641002, > including one that looks nearly identical to the OP's example. That > was issued in March 2014, so it's quite possible for older compilers > to not make the check. If a new compiler doesn't make the check, > definitely complain to your vendor and tell 'em I sent you. :-) GNAT GPL >= 2015, FSF GCC >= 5 all refuse to compile that test: 23 errors each of which is marked in the source as expected. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Recommendation of safe subset of Ada to use? 2018-05-05 21:23 Recommendation of safe subset of Ada to use? joakimds 2018-05-05 21:32 ` gorgelo @ 2018-05-07 15:54 ` onox 2018-05-08 0:22 ` Randy Brukardt 2018-05-08 0:06 ` Randy Brukardt 2 siblings, 1 reply; 13+ messages in thread From: onox @ 2018-05-07 15:54 UTC (permalink / raw) On Saturday, May 5, 2018 at 11:23:04 PM UTC+2, joak...@kth.se wrote: > Jere gave the following example in the other thread about how to get Ada across the chasm: > > 1. Dangling references: Keeping a reference to an object past its lifetime > > Ada: > *********************************************** > with Ada.Text_IO; use Ada.Text_IO; > > procedure jdoodle is > type Integer_Access is access all Integer; > > function Inner(Value : aliased in out Integer) return Integer_Access is > begin > return Value'Access; > end Inner; > > function Outer return Integer_Access is > Value : aliased Integer := 0; > begin > return Inner(Value); > end Outer; > > Ptr : Integer_Access := Outer; -- !!! Dangling reference > begin > Put_Line("Hello World"); > end jdoodle; > *********************************************** > Hello World > > gcc -c jdoodle.adb > gnatbind -x jdoodle.ali > gnatlink jdoodle.ali -o jdoodle > > It's a 20 line application that demonstrates a dangling pointer in Ada. That's not supposed to be able to happen unless one goes outside of Ada's type system by using Unchecked_Deallocation, Unchecked_Conversion or System.Address_To_Access_Conversion. I've tried the example with the GNAT compiler and it does not detect the issue. I do not believe this is a GNAT bug. Aliased parameters were part of the solution to be able to safely reference elements in containers and thereby avoid unnecessary copying. By making this possible was a hole in Adas type system introduced? It means that one cannot safely use all the features of Ada and be sure of memory safety instead one should stick to a subset of Ada. One subset that comes to mind is SPARK. Another is for example sticking to Ada95 or Ada 2005. Or maybe one should just ban usage of aliased parameters but then what should one do with the standard containers that one probably uses throughout one's application. I am confused. Anybody that can shed light? > > /Joakim A similar problem happens with anonymous access procedures (GNAT 7.2): with Ada.Text_IO; procedure A is type Proc_Access is access procedure (P1 : Integer); function Inner (Value : access procedure (P2 : Integer)) return Proc_Access is begin return Value; end Inner; function Outer (X : Integer) return Proc_Access is use Ada.Text_IO; procedure Value (Y : Integer) is begin Put_Line ("X: " & X'Image); -- random Put_Line ("Y: " & Y'Image); -- 2 end Value; begin return Inner (Value'Access); end Outer; Ptr : Proc_Access := Outer (1); begin Ptr (2); end A; ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Recommendation of safe subset of Ada to use? 2018-05-07 15:54 ` onox @ 2018-05-08 0:22 ` Randy Brukardt 0 siblings, 0 replies; 13+ messages in thread From: Randy Brukardt @ 2018-05-08 0:22 UTC (permalink / raw) "onox" <denkpadje@gmail.com> wrote in message news:3d48e916-7ec1-4e01-9a9d-1d8c3c81061f@googlegroups.com... ... > function Inner (Value : access procedure (P2 : Integer)) return > Proc_Access is > begin > return Value; > end Inner; I believe this is outright illegal; the accessibility of an anonymous access-to-subprogram is "infinite", and the accessibility of Proc_Access is not, so it is not allowed. There's not supposed to be any legal conversion to "regular" access-to-subprogram types. Again, if allowed, report it as a bug. Randy. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Recommendation of safe subset of Ada to use? 2018-05-05 21:23 Recommendation of safe subset of Ada to use? joakimds 2018-05-05 21:32 ` gorgelo 2018-05-07 15:54 ` onox @ 2018-05-08 0:06 ` Randy Brukardt 2 siblings, 0 replies; 13+ messages in thread From: Randy Brukardt @ 2018-05-08 0:06 UTC (permalink / raw) <joakimds@kth.se> wrote in message news:9839db28-b6c6-44c9-9d36-336a39c12f25@googlegroups.com... > I do not believe this is a GNAT bug. This is definitely a GNAT bug, if it really does allow this program. This is definitely not allowed by the accessibility rules. See my other messages on it. Randy. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2018-05-08 8:07 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-05-05 21:23 Recommendation of safe subset of Ada to use? joakimds 2018-05-05 21:32 ` gorgelo 2018-05-06 7:43 ` Jeffrey R. Carter 2018-05-06 8:45 ` Niklas Holsti 2018-05-06 8:52 ` gorgelo 2018-05-06 13:15 ` Jere 2018-05-06 13:47 ` Jere 2018-05-06 21:28 ` Brad Moore 2018-05-08 0:19 ` Randy Brukardt 2018-05-08 8:07 ` Simon Wright 2018-05-07 15:54 ` onox 2018-05-08 0:22 ` Randy Brukardt 2018-05-08 0:06 ` Randy Brukardt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox