* How many Ada compiler bugs are here? @ 2012-01-12 23:20 Maciej Sobczak 2012-01-13 0:21 ` Randy Brukardt 0 siblings, 1 reply; 41+ messages in thread From: Maciej Sobczak @ 2012-01-12 23:20 UTC (permalink / raw) Consider: with Ada.Finalization; with Ada.Text_IO; procedure Test is package P is Some_Error : exception; type T (<>) is limited private; function Make_T return T; private type T is new Ada.Finalization.Limited_Controlled with record Initialized : Boolean := False; end record; overriding procedure Adjust (V : in out T); overriding procedure Finalize (V : in out T); end P; package body P is function Make_T return T is begin raise Some_Error; -- needed to please the compiler: return (Ada.Finalization.Limited_Controlled with others => <>); end Make_T; procedure Adjust (V : in out T) is begin Ada.Text_IO.Put_Line ("adjusting"); end Adjust; procedure Finalize (V : in out T) is begin Ada.Text_IO.Put_Line ("finalizing with Initialized =" & Boolean'Image (V.Initialized)); end Finalize; end P; begin declare Tmp : P.T := P.Make_T; begin null; end; exception when others => Ada.Text_IO.Put_Line ("exception handled"); end Test; This program prints (GNAT 2011): $ ./test finalizing with Initialized =TRUE exception handled $ Above: 1. Adjust should not be allowed to be declared (it is a *limited* type). But I have defined it to trace the remaining bugs: 2. The return statement in Make_T should not be required, because it is unreachable anyway. 3. Logically, Tmp is never created, because Make_T raises an exception. Somehow some object is finalized. Apparently it is Tmp, which should not exist. 4. Somehow Tmp.initialized = True, even though its default value is defined to be False. Guess how I found that out. It's past midnight here... Are there any known workarounds? -- Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-12 23:20 How many Ada compiler bugs are here? Maciej Sobczak @ 2012-01-13 0:21 ` Randy Brukardt 2012-01-13 1:26 ` Adam Beneschan ` (2 more replies) 0 siblings, 3 replies; 41+ messages in thread From: Randy Brukardt @ 2012-01-13 0:21 UTC (permalink / raw) "Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message news:01dd6341-9c3c-4dcb-90f8-6ac66c65eb66@z1g2000vbx.googlegroups.com... ... > 1. Adjust should not be allowed to be declared (it is a *limited* > type). But I have defined it to trace the remaining bugs: There's nothing wrong with defining "Adjust" (you can define any named subprogram you want, of course), but (A) "overriding" shouldn't be allowed on it, and (B) it shouldn't be called automatically if it is defined without "overriding", because it is not special for a limited type. > 2. The return statement in Make_T should not be required, because it > is unreachable anyway. Ada requires all functions to have a return statement. 6.5(5/2). This was an Ada 83 rule; we've discussed removing it, but the feeling was that it catches as many errors as it creates, and we just couldn't justify a change to the language that didn't seem to be an obvious improvement. (In my personal work, it has been about 50-50 as to whether it helps or hinders.) So the requirement for a return statement is not a bug, it's a language rule. > 3. Logically, Tmp is never created, because Make_T raises an > exception. Somehow some object is finalized. Apparently it is Tmp, > which should not exist. > 4. Somehow Tmp.initialized = True, even though its default value is > defined to be False. I'm not sure if these are actually bugs or not; the fact that Adjust is being called for a limited object means to me that nothing that happens afterwards makes any sense from a formal language perspective, so you can't really say if there is a bug. Garbage-in, garbage-out! Does the same thing happen without Adjust being defined? That would seem more like a bug. Randy. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-13 0:21 ` Randy Brukardt @ 2012-01-13 1:26 ` Adam Beneschan 2012-01-13 8:23 ` Dmitry A. Kazakov 2012-01-13 20:06 ` Blady 2012-01-14 10:20 ` Maciej Sobczak 2 siblings, 1 reply; 41+ messages in thread From: Adam Beneschan @ 2012-01-13 1:26 UTC (permalink / raw) On Jan 12, 4:21 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote: > > 2. The return statement in Make_T should not be required, because it > > is unreachable anyway. > > Ada requires all functions to have a return statement. 6.5(5/2). This was an > Ada 83 rule; we've discussed removing it, but the feeling was that it > catches as many errors as it creates, and we just couldn't justify a change > to the language that didn't seem to be an obvious improvement. (In my > personal work, it has been about 50-50 as to whether it helps or hinders.) > > So the requirement for a return statement is not a bug, it's a language > rule. Maybe it would be helpful to remove the requirement for functions whose last statement is a RAISE statement, so that stubs for functions that aren't supposed to be called or aren't yet implemented don't have to have the useless RETURN. That way, you'd still catch most of the errors that get caught by the rule, if not all of them. I've written code where stub functions call some sort of error procedure that performs a RAISE, and I would have to put a dummy RETURN after the RAISE, which always annoyed me. The change I described wouldn't entirely fix that, since the function body ends with a procedure call statement instead of a RAISE statement. But at least I could add a dummy "raise Program_Error;" at the end instead of trying to write a return statement to cook up some value. But then again, with extended returns, you don't need to cook up a value. The code: -- needed to please the compiler: return (Ada.Finalization.Limited_Controlled with others => <>); could be written more simply as return Dummy : T; -- Adam -- Adam > > > 3. Logically, Tmp is never created, because Make_T raises an > > exception. Somehow some object is finalized. Apparently it is Tmp, > > which should not exist. > > 4. Somehow Tmp.initialized = True, even though its default value is > > defined to be False. > > I'm not sure if these are actually bugs or not; the fact that Adjust is > being called for a limited object means to me that nothing that happens > afterwards makes any sense from a formal language perspective, so you can't > really say if there is a bug. Garbage-in, garbage-out! Does the same thing > happen without Adjust being defined? That would seem more like a bug. > > Randy. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-13 1:26 ` Adam Beneschan @ 2012-01-13 8:23 ` Dmitry A. Kazakov 2012-01-13 8:47 ` AdaMagica 2012-01-13 17:15 ` Adam Beneschan 0 siblings, 2 replies; 41+ messages in thread From: Dmitry A. Kazakov @ 2012-01-13 8:23 UTC (permalink / raw) On Thu, 12 Jan 2012 17:26:34 -0800 (PST), Adam Beneschan wrote: > But then again, with extended returns, you don't need to cook up a > value. The code: > > -- needed to please the compiler: > return (Ada.Finalization.Limited_Controlled > with others => <>); > > could be written more simply as > > return Dummy : T; Not when T requires initialization, i.e. publicly has boxed discriminants. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-13 8:23 ` Dmitry A. Kazakov @ 2012-01-13 8:47 ` AdaMagica 2012-01-13 9:07 ` Dmitry A. Kazakov 2012-01-13 17:15 ` Adam Beneschan 1 sibling, 1 reply; 41+ messages in thread From: AdaMagica @ 2012-01-13 8:47 UTC (permalink / raw) On 13 Jan., 09:23, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > On Thu, 12 Jan 2012 17:26:34 -0800 (PST), Adam Beneschan wrote: > > But then again, with extended returns, you don't need to cook up a > > value. The code: > > > -- needed to please the compiler: > > return (Ada.Finalization.Limited_Controlled > > with others => <>); > > > could be written more simply as > > > return Dummy : T; > > Not when T requires initialization, i.e. publicly has boxed discriminants. > > -- > Regards, > Dmitry A. Kazakovhttp://www.dmitry-kazakov.de Of course this is legal since it's in the scope of the full view (it's a definite type in the full view, an indefinite only in the partial view). ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-13 8:47 ` AdaMagica @ 2012-01-13 9:07 ` Dmitry A. Kazakov 2012-01-13 9:35 ` AdaMagica 0 siblings, 1 reply; 41+ messages in thread From: Dmitry A. Kazakov @ 2012-01-13 9:07 UTC (permalink / raw) On Fri, 13 Jan 2012 00:47:35 -0800 (PST), AdaMagica wrote: > On 13 Jan., 09:23, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: >> On Thu, 12 Jan 2012 17:26:34 -0800 (PST), Adam Beneschan wrote: >>> But then again, with extended returns, you don't need to cook up a >>> value. �The code: >> >>> � � � � �-- �needed to please the compiler: >>> � � � � �return (Ada.Finalization.Limited_Controlled >>> � � � � � � � � � �with others => <>); >> >>> could be written more simply as >> >>> � � � � �return Dummy : T; >> >> Not when T requires initialization, i.e. publicly has boxed discriminants. > Of course this is legal since it's in the scope of the full view (it's > a definite type in the full view, an indefinite only in the partial > view). Only if you have that full view in the function body. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-13 9:07 ` Dmitry A. Kazakov @ 2012-01-13 9:35 ` AdaMagica 2012-01-13 10:00 ` Dmitry A. Kazakov 0 siblings, 1 reply; 41+ messages in thread From: AdaMagica @ 2012-01-13 9:35 UTC (permalink / raw) On 13 Jan., 10:07, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > On Fri, 13 Jan 2012 00:47:35 -0800 (PST), AdaMagica wrote: > > On 13 Jan., 09:23, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > > wrote: > >> On Thu, 12 Jan 2012 17:26:34 -0800 (PST), Adam Beneschan wrote: > >>> But then again, with extended returns, you don't need to cook up a > >>> value. The code: > > >>> -- needed to please the compiler: > >>> return (Ada.Finalization.Limited_Controlled > >>> with others => <>); > > >>> could be written more simply as > > >>> return Dummy : T; > > >> Not when T requires initialization, i.e. publicly has boxed discriminants. > > Of course this is legal since it's in the scope of the full view (it's > > a definite type in the full view, an indefinite only in the partial > > view). > > Only if you have that full view in the function body. > > -- > Regards, > Dmitry A. Kazakovhttp://www.dmitry-kazakov.de What do you want to say? Isn't that exactly what I said? ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-13 9:35 ` AdaMagica @ 2012-01-13 10:00 ` Dmitry A. Kazakov 2012-01-13 10:38 ` georg bauhaus ` (2 more replies) 0 siblings, 3 replies; 41+ messages in thread From: Dmitry A. Kazakov @ 2012-01-13 10:00 UTC (permalink / raw) On Fri, 13 Jan 2012 01:35:58 -0800 (PST), AdaMagica wrote: > On 13 Jan., 10:07, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: >> On Fri, 13 Jan 2012 00:47:35 -0800 (PST), AdaMagica wrote: >>> On 13 Jan., 09:23, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> >>> wrote: >>>> On Thu, 12 Jan 2012 17:26:34 -0800 (PST), Adam Beneschan wrote: >>>>> But then again, with extended returns, you don't need to cook up a >>>>> value. �The code: >> >>>>> � � � � �-- �needed to please the compiler: >>>>> � � � � �return (Ada.Finalization.Limited_Controlled >>>>> � � � � � � � � � �with others => <>); >> >>>>> could be written more simply as >> >>>>> � � � � �return Dummy : T; >> >>>> Not when T requires initialization, i.e. publicly has boxed discriminants. >>> Of course this is legal since it's in the scope of the full view (it's >>> a definite type in the full view, an indefinite only in the partial >>> view). >> >> Only if you have that full view in the function body. >> > What do you want to say? Isn't that exactly what I said? package P is type T (<>) is private; private type T is new Integer; end P; with P; use P; package Q is function Foo return T; end Q; package body Q is function Foo return T is begin raise Constraint_Error; return Dummy : T; -- No, that won't work! end Foo; end Q; The requirement to have a meaningless return might turn to be a serious trouble. The example above might look constructed, but things like this happen relatively frequently in large projects. And when they do, it forces interfaces and package hierarchies reworked. Nasty thing. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-13 10:00 ` Dmitry A. Kazakov @ 2012-01-13 10:38 ` georg bauhaus 2012-01-13 11:39 ` Dmitry A. Kazakov 2012-01-13 10:52 ` AdaMagica 2012-01-13 17:23 ` Adam Beneschan 2 siblings, 1 reply; 41+ messages in thread From: georg bauhaus @ 2012-01-13 10:38 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote: > > package P is > type T (<>) is private; > private > type T is new Integer; > end P; > package P.Dummies is Meaningless_Dummy : constant T; Raising_Dummy : constant T; private ... End P.Dummies; At project milestones, $ grep Dummies *.ad? to see where finishing work is needed. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-13 10:38 ` georg bauhaus @ 2012-01-13 11:39 ` Dmitry A. Kazakov 2012-01-13 12:43 ` Georg Bauhaus 0 siblings, 1 reply; 41+ messages in thread From: Dmitry A. Kazakov @ 2012-01-13 11:39 UTC (permalink / raw) On 13 Jan 2012 10:38:04 GMT, georg bauhaus wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote: > >> >> package P is >> type T (<>) is private; >> private >> type T is new Integer; >> end P; >> > > package P.Dummies is > Meaningless_Dummy : constant T; > Raising_Dummy : constant T; > private > ... > End P.Dummies; Which of course defies the very idea of requiring T initialized. If there exist some Meaningless_Dummy constant, then that could serve as an initial value for T. The whole point why Foo returning T raises an exception is that there NO value to return! -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-13 11:39 ` Dmitry A. Kazakov @ 2012-01-13 12:43 ` Georg Bauhaus 2012-01-13 13:06 ` AdaMagica 0 siblings, 1 reply; 41+ messages in thread From: Georg Bauhaus @ 2012-01-13 12:43 UTC (permalink / raw) On 13.01.12 12:39, Dmitry A. Kazakov wrote: > On 13 Jan 2012 10:38:04 GMT, georg bauhaus wrote: > >> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote: >> >>> >>> package P is >>> type T (<>) is private; >>> private >>> type T is new Integer; >>> end P; >>> >> >> package P.Dummies is >> Meaningless_Dummy : constant T; >> Raising_Dummy : constant T; >> private >> ... >> End P.Dummies; > > Which of course defies the very idea of requiring T initialized. If there > exist some Meaningless_Dummy constant, then that could serve as an initial > value for T. I'd drop Meaningless_Dummy, then, and declare only the dummy that raises an exception: package P is type T (<>) is private; private type T is new Integer; function Raises_Assertion_Error return T; end P; package P.Dummies is Raising_Dummy : constant T; private Raising_Dummy : constant T := Raises_Assertion_Error; end P.Dummies; -- or make Raising_Dummy a constructing function that raises, -- so that raising happens where Raising_Dummy is written. with Ada.Assertions; package body P is function Raises_Assertion_Error return T is use Ada.Assertions; begin raise Assertion_Error with "FIXME"; return Raises_Assertion_Error; end Raises_Assertion_Error; end P; Is this about statically ascertaining that a meaningful initial value has been stored in an object of type T, where "meaningful" is a statically known consequence of using some construction feature of non-Ada, or not-yet-Ada? ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-13 12:43 ` Georg Bauhaus @ 2012-01-13 13:06 ` AdaMagica 2012-01-13 13:16 ` AdaMagica 2012-01-13 13:22 ` Georg Bauhaus 0 siblings, 2 replies; 41+ messages in thread From: AdaMagica @ 2012-01-13 13:06 UTC (permalink / raw) On 13 Jan., 13:43, Georg Bauhaus <rm.dash-bauh...@futureapps.de> wrote: > package P is > type T (<>) is private; > private > type T is new Integer; > function Raises_Assertion_Error return T; > end P; > > package P.Dummies is > Raising_Dummy : constant T; > private > Raising_Dummy : constant T := Raises_Assertion_Error; > end P.Dummies; > > -- or make Raising_Dummy a constructing function that raises, > -- so that raising happens where Raising_Dummy is written. > > with Ada.Assertions; > package body P is > function Raises_Assertion_Error return T is > use Ada.Assertions; > begin > raise Assertion_Error with "FIXME"; > return Raises_Assertion_Error; > end Raises_Assertion_Error; > end P; > > Is this about statically ascertaining that a meaningful initial value > has been stored in an object of type T, where "meaningful" is a statically > known consequence of using some construction feature of non-Ada, or > not-yet-Ada? I do not see what you are trying to accomplish. As written, P.Dummies will raise an exception upon elaboration. package P is type T (<>) is private; function F (...) return T; private ... end P; This *is* the Ada way to force meaningful initial values. You may have as many functions returning a T as you like with whatever parameter profile. There is no need for any further apparatus. (Or am I missing something?) ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-13 13:06 ` AdaMagica @ 2012-01-13 13:16 ` AdaMagica 2012-01-13 13:22 ` Georg Bauhaus 1 sibling, 0 replies; 41+ messages in thread From: AdaMagica @ 2012-01-13 13:16 UTC (permalink / raw) Back to the title "How many Ada compiler bugs are here?" I guess there's a countable infinity of mistakes. At any time, it's a finite number, but whenever one is corrected, it's most probable that a new one is introduced. And Ada is evolving, so implementations will produce new mistakes. I venture a wager that there is no compiler on earth that is error- free (if the language it implements is elaborate enough so that you would use it for some real project). ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-13 13:06 ` AdaMagica 2012-01-13 13:16 ` AdaMagica @ 2012-01-13 13:22 ` Georg Bauhaus 2012-01-13 13:29 ` Dmitry A. Kazakov 1 sibling, 1 reply; 41+ messages in thread From: Georg Bauhaus @ 2012-01-13 13:22 UTC (permalink / raw) On 13.01.12 14:06, AdaMagica wrote: >> package P.Dummies is >> Raising_Dummy : constant T; >> private >> Raising_Dummy : constant T := Raises_Assertion_Error; >> end P.Dummies; >> >> -- or make Raising_Dummy a constructing function that raises, >> -- so that raising happens where Raising_Dummy is written. > I do not see what you are trying to accomplish. As written, P.Dummies > will raise an exception upon elaboration. Yes, my head was spinning around objects that would be (default) Initialized while my fingers were typing something different. Hence the constant-turned-function comment. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-13 13:22 ` Georg Bauhaus @ 2012-01-13 13:29 ` Dmitry A. Kazakov 0 siblings, 0 replies; 41+ messages in thread From: Dmitry A. Kazakov @ 2012-01-13 13:29 UTC (permalink / raw) On Fri, 13 Jan 2012 14:22:08 +0100, Georg Bauhaus wrote: > Yes, my head was spinning around objects that would > be (default) Initialized while my fingers were typing > something different. Hence the constant-turned-function > comment. OT. In Ada values and functions are consistently interchangeable. What you wanted is a lazy constant/value. I wonder is newly introduced aspects for dereferencing could give you that effect. I am not sure. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-13 10:00 ` Dmitry A. Kazakov 2012-01-13 10:38 ` georg bauhaus @ 2012-01-13 10:52 ` AdaMagica 2012-01-13 11:35 ` Dmitry A. Kazakov 2012-01-13 17:23 ` Adam Beneschan 2 siblings, 1 reply; 41+ messages in thread From: AdaMagica @ 2012-01-13 10:52 UTC (permalink / raw) > >>> Of course this is legal since it's in the scope of the full view (it's > >>> a definite type in the full view, an indefinite only in the partial > >>> view). > > >> Only if you have that full view in the function body. > > > What do you want to say? Isn't that exactly what I said? > > package P is > type T (<>) is private; > private > type T is new Integer; > end P; That's a severe design mistake. You cannot declare objects of T - there are no constructors. > with P; use P; > package Q is > function Foo return T; > end Q; You have to declare constructors in P (I know you know that, so why do you write such nonsense?). PS: I know that Foo in your terminology is not a constructor. > package body Q is > function Foo return T is > begin > raise Constraint_Error; > return Dummy : T; -- No, that won't work! So what? Yeah, that's not in the scope of the full view. > end Foo; > end Q; > > The requirement to have a meaningless return might turn to be a serious > trouble. The example above might look constructed, but things like this > happen relatively frequently in large projects. And when they do, it forces > interfaces and package hierarchies reworked. Nasty thing. Well, yes, design errors happen. Everyone knows that... But this example is a silly mistake. You know that. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-13 10:52 ` AdaMagica @ 2012-01-13 11:35 ` Dmitry A. Kazakov 2012-01-13 12:58 ` AdaMagica 0 siblings, 1 reply; 41+ messages in thread From: Dmitry A. Kazakov @ 2012-01-13 11:35 UTC (permalink / raw) On Fri, 13 Jan 2012 02:52:29 -0800 (PST), AdaMagica wrote: >>>>> Of course this is legal since it's in the scope of the full view (it's >>>>> a definite type in the full view, an indefinite only in the partial >>>>> view). >> >>>> Only if you have that full view in the function body. >> >>> What do you want to say? Isn't that exactly what I said? >> >> package P is >> � �type T (<>) is private; >> private >> � �type T is new Integer; >> end P; > > That's a severe design mistake. You cannot declare objects of T - > there are no constructors. P could have a constructing function, but that would not make the return statement in Q legal. Note, my point was that the workaround Adam suggested does not always work in the real-life code. >> The requirement to have a meaningless return might turn to be a serious >> trouble. The example above might look constructed, but things like this >> happen relatively frequently in large projects. And when they do, it forces >> interfaces and package hierarchies reworked. Nasty thing. > > Well, yes, design errors happen. Everyone knows that... An unreachable return required by the language is certainly a design error. But I suggest that you are rather trying to excuse Ada's sloppiness in this issue. If they wanted to be adamant on requiring return, they should have allowed raising return, e.g. function Foo return T is begin return raise Constraint_Error; end Foo; > But this example is a silly mistake. You know that. Where do you see any mistake? I omitted constructing functions because, firstly, they are irrelevant to the point I am making, and, secondly, because factories could be provided by other packages, not necessarily by P itself. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-13 11:35 ` Dmitry A. Kazakov @ 2012-01-13 12:58 ` AdaMagica 2012-01-13 13:43 ` Dmitry A. Kazakov 0 siblings, 1 reply; 41+ messages in thread From: AdaMagica @ 2012-01-13 12:58 UTC (permalink / raw) On 13 Jan., 12:35, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > An unreachable return required by the language is certainly a design error. Well, yes, you may see this as such. But it's not a severe one, or else the ARG would certainly have changed that. > But I suggest that you are rather trying to excuse Ada's sloppiness in this > issue. Ada's not perfect, we all know that. But it's one of the best... > > But this example is a silly mistake. You know that. > > Where do you see any mistake? I omitted constructing functions because, > firstly, they are irrelevant they're not, see below > to the point I am making, and, secondly, > because factories could be provided by other packages, not necessarily by P > itself. But without a constructor in P (or in children thereof) for T there cannot be any factories anywhere. This is silly mistake in your example. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-13 12:58 ` AdaMagica @ 2012-01-13 13:43 ` Dmitry A. Kazakov 2012-01-13 15:06 ` Robert A Duff 0 siblings, 1 reply; 41+ messages in thread From: Dmitry A. Kazakov @ 2012-01-13 13:43 UTC (permalink / raw) On Fri, 13 Jan 2012 04:58:21 -0800 (PST), AdaMagica wrote: > On 13 Jan., 12:35, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: >> But I suggest that you are rather trying to excuse Ada's sloppiness in this >> issue. > > Ada's not perfect, we all know that. But it's one of the best... The best, IMO. >> to the point I am making, and, secondly, >> because factories could be provided by other packages, not necessarily by P >> itself. > > But without a constructor in P (or in children thereof) for T there > cannot be any factories anywhere. This is silly mistake in your > example. No. You can have them in children packages, which is not so uncommon to do. I ran into the issue of required return statement several times. If you have a hierarchy of managed objects, for which you would like to prevent stack instances or make them accessible only though proxy objects, etc. Especially when some fields are not null access. Then you may get this problem. It can occur pretty late and require a huge amount of redesign. Because to access the full view the package must be a child, and it is usually already a child of some other package and not without a reason, e.g. to access the internals of those. BTW, I always wondered why cannot we have multiple parents of a package in Ada? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-13 13:43 ` Dmitry A. Kazakov @ 2012-01-13 15:06 ` Robert A Duff 2012-01-13 15:46 ` Dmitry A. Kazakov 0 siblings, 1 reply; 41+ messages in thread From: Robert A Duff @ 2012-01-13 15:06 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > No. You can have them in children packages, which is not so uncommon to do. True. You could also create all the objects (maybe there is only one!) in the body of package P itself, and perhaps hand out access-to-T values. > I ran into the issue of required return statement several times. If you > have a hierarchy of managed objects, for which you would like to prevent > stack instances or make them accessible only though proxy objects, etc. > Especially when some fields are not null access. Then you may get this > problem. It can occur pretty late and require a huge amount of redesign. I don't think it can cause huge redesign. I agree with you that it's a language design flaw, but I also agree with AdaMagica that it's a small one. Here's a workaround: function Foo return T is begin raise Constraint_Error; return Foo; -- kludgy recursive call; can't get here! end Foo; If Foo takes parameters, pass them along in the recursive call. No need to gin up a value of type T. > BTW, I always wondered why cannot we have multiple parents of a package in > Ada? Sounds hugely complicated. - Bob ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-13 15:06 ` Robert A Duff @ 2012-01-13 15:46 ` Dmitry A. Kazakov 2012-01-13 17:42 ` georg bauhaus ` (2 more replies) 0 siblings, 3 replies; 41+ messages in thread From: Dmitry A. Kazakov @ 2012-01-13 15:46 UTC (permalink / raw) On Fri, 13 Jan 2012 10:06:02 -0500, Robert A Duff wrote: > Here's a workaround: > > function Foo return T is > begin > raise Constraint_Error; > return Foo; -- kludgy recursive call; can't get here! > end Foo; Cool! I never thought about that. Thanks! >> BTW, I always wondered why cannot we have multiple parents of a package in >> Ada? > > Sounds hugely complicated. Why? The only complicated thing would naming of the files. Instantiation of multiple parent's generic child must be fun, but no more than generic child already is. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-13 15:46 ` Dmitry A. Kazakov @ 2012-01-13 17:42 ` georg bauhaus 2012-01-13 18:52 ` Dmitry A. Kazakov 2012-01-14 0:26 ` Randy Brukardt 2012-01-14 2:41 ` Robert A Duff 2 siblings, 1 reply; 41+ messages in thread From: georg bauhaus @ 2012-01-13 17:42 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote: > On Fri, 13 Jan 2012 10:06:02 -0500, Robert A Duff wrote: > >> Here's a workaround: >> >> function Foo return T is >> begin >> raise Constraint_Error; >> return Foo; -- kludgy recursive call; can't get here! >> end Foo; > > Cool! I never thought about that. Thanks! Have you used gnatstub before? ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-13 17:42 ` georg bauhaus @ 2012-01-13 18:52 ` Dmitry A. Kazakov 0 siblings, 0 replies; 41+ messages in thread From: Dmitry A. Kazakov @ 2012-01-13 18:52 UTC (permalink / raw) On 13 Jan 2012 17:42:57 GMT, georg bauhaus wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote: >> On Fri, 13 Jan 2012 10:06:02 -0500, Robert A Duff wrote: >> >>> Here's a workaround: >>> >>> function Foo return T is >>> begin >>> raise Constraint_Error; >>> return Foo; -- kludgy recursive call; can't get here! >>> end Foo; >> >> Cool! I never thought about that. Thanks! > > Have you used gnatstub before? Never. I always add a specification and the body together, i.e. spec A body A spec B body B ... rather than spec A spec B ... body A body B ... Otherwise I would certainly forget to implement something, because I do not do coverage testing. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-13 15:46 ` Dmitry A. Kazakov 2012-01-13 17:42 ` georg bauhaus @ 2012-01-14 0:26 ` Randy Brukardt 2012-01-14 9:49 ` Dmitry A. Kazakov 2012-01-14 2:41 ` Robert A Duff 2 siblings, 1 reply; 41+ messages in thread From: Randy Brukardt @ 2012-01-14 0:26 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:11extopcf5hsy.qk7psu30kjrp.dlg@40tude.net... >>> BTW, I always wondered why cannot we have multiple parents of a package >>> in >>> Ada? >> >> Sounds hugely complicated. > > Why? The only complicated thing would naming of the files. Because the parent's declarations are directly visible in the child. If there are multiple parents, you'd have multiple scopes of declarations directly visible, and we would have to worry about what happens when there are conflicts. We don't have to do this in Ada today. There is a similar problem for package use clauses, but there is no satisfactory solution to that problem. All of the solutions are dangerous (Ada picks the least dangerous solution, but it still has lots of issues in practice). I don't think we want more of these cases. In fact, the only *safe* alternative is for there to be precisely one scope that is directly visible. This isn't very practical, I'm afraid, and I don't know of any way to support that for children. [Aside: I'm now convinced that the primary problem with use clauses is conflicts between non-overloadable entities. As such, "use type" and "use all type" are much safer (since they only make overloadable entities visible), and I will be using them more often in new code. I'm still going to avoid package use in the vast majority of cases.] I realize that allowing only one of something is always going to be a problem: one parent, one stream attribute of each kind, etc. But many of these defy easy solution. Randy. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-14 0:26 ` Randy Brukardt @ 2012-01-14 9:49 ` Dmitry A. Kazakov 2012-01-19 1:35 ` Randy Brukardt 0 siblings, 1 reply; 41+ messages in thread From: Dmitry A. Kazakov @ 2012-01-14 9:49 UTC (permalink / raw) On Fri, 13 Jan 2012 18:26:13 -0600, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:11extopcf5hsy.qk7psu30kjrp.dlg@40tude.net... >>>> BTW, I always wondered why cannot we have multiple parents of a package >>>> in Ada? >>> >>> Sounds hugely complicated. >> >> Why? The only complicated thing would naming of the files. > > Because the parent's declarations are directly visible in the child. If > there are multiple parents, you'd have multiple scopes of declarations > directly visible, and we would have to worry about what happens when there > are conflicts. We don't have to do this in Ada today. Yes, but I want this feature in other form anyway. I want to have an ability to fuse several declaration scopes into a package to reuse obtained direct visibility scope later. It is quite a problem now that packages need large sets of "with" and "use" clauses in front of them as well as multiple "use" clauses inside them (for generic instances). This stuff is repeated over and over again, which is a maintenance problem and a problem for the reader. > There is a similar problem for package use clauses, but there is no > satisfactory solution to that problem. All of the solutions are dangerous > (Ada picks the least dangerous solution, but it still has lots of issues in > practice). I don't think we want more of these cases. I am not sure which solutions you have in mind. I would simply forbid any conflicts. The compiler must insist on explicit renaming of all conflicting entities. It is rather a perceived problem so long declaration scopes cannot be named an reused. Once we would use them as named entities, construct and design them intentionally, the problem would disappear. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-14 9:49 ` Dmitry A. Kazakov @ 2012-01-19 1:35 ` Randy Brukardt 2012-01-19 10:33 ` Dmitry A. Kazakov 0 siblings, 1 reply; 41+ messages in thread From: Randy Brukardt @ 2012-01-19 1:35 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:e8vqwjo7ify3.htkn2p8qs8lw$.dlg@40tude.net... > On Fri, 13 Jan 2012 18:26:13 -0600, Randy Brukardt wrote: > >> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >> news:11extopcf5hsy.qk7psu30kjrp.dlg@40tude.net... >>>>> BTW, I always wondered why cannot we have multiple parents of a >>>>> package >>>>> in Ada? >>>> >>>> Sounds hugely complicated. >>> >>> Why? The only complicated thing would naming of the files. >> >> Because the parent's declarations are directly visible in the child. If >> there are multiple parents, you'd have multiple scopes of declarations >> directly visible, and we would have to worry about what happens when >> there >> are conflicts. We don't have to do this in Ada today. > > Yes, but I want this feature in other form anyway. I want to have an > ability to fuse several declaration scopes into a package to reuse > obtained > direct visibility scope later. It is quite a problem now that packages > need > large sets of "with" and "use" clauses in front of them as well as > multiple > "use" clauses inside them (for generic instances). This stuff is repeated > over and over again, which is a maintenance problem and a problem for the > reader. I agree with you, and in fact we tried to provide such a feature in Ada 2012. (See AI05-0135-2.) We eventually gave up, mainly because any scheme for managing the conflicts caused unacceptable problems in maintenance. >> There is a similar problem for package use clauses, but there is no >> satisfactory solution to that problem. All of the solutions are dangerous >> (Ada picks the least dangerous solution, but it still has lots of issues >> in >> practice). I don't think we want more of these cases. > > I am not sure which solutions you have in mind. I would simply forbid any > conflicts. The compiler must insist on explicit renaming of all > conflicting > entities. We tried rules on that line, but they caused the sorts of maintenance problems that aren't really acceptable. It should never be the case that adding a declaration to a package makes some other package illegal even though the other package does not use the new declaration. (Yes, I know there are cases where direct visibility and parent visibility violate this principle, but just because the language is already wrong doesn't mean it should be made wronger. :-) [Keep in mind I'm talking about an *addition* and not a modification of a declaration. The principle is that adding new features to a package shouldn't cause clients that don't use those features to need modification.] Another cause of problems was diamond inheritance, where an integrated package tries to add a declaration that is already directly visible by some other path. We definitely don't want those to conflict, but it is very hard to craft rules that have the right effect (in large part because visibility is based on "views", not "entities", and these clearly are different views). > It is rather a perceived problem so long declaration scopes cannot be > named > an reused. Once we would use them as named entities, construct and design > them intentionally, the problem would disappear. Maybe, but the evidence is that handling the conflicts is a major maintenance problem. One thing that clearly would help would be to make all entities overloadable. In that case, there would be far fewer conflicts (objects would overload on their types, and could overload with functions and procedures as well), so perhaps we could live with the conflicts. But that would be hugely expensive in existing Ada compilers (pretty much all of the visibility mechanisms would have to be redone from scratch), and it is unlikely that it could be done compatibly with existing code. I made a proposal to allow overloading of objects (only), which I believe could in fact be done compatibly, but it went nowhere. And there still would be problems with exceptions and packages and types (none of which can be overloaded currently or in any compatible way), so its probably not enough. Randy. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-19 1:35 ` Randy Brukardt @ 2012-01-19 10:33 ` Dmitry A. Kazakov 0 siblings, 0 replies; 41+ messages in thread From: Dmitry A. Kazakov @ 2012-01-19 10:33 UTC (permalink / raw) On Wed, 18 Jan 2012 19:35:39 -0600, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:e8vqwjo7ify3.htkn2p8qs8lw$.dlg@40tude.net... >> On Fri, 13 Jan 2012 18:26:13 -0600, Randy Brukardt wrote: >> >>> There is a similar problem for package use clauses, but there is no >>> satisfactory solution to that problem. All of the solutions are dangerous >>> (Ada picks the least dangerous solution, but it still has lots of issues in >>> practice). I don't think we want more of these cases. >> >> I am not sure which solutions you have in mind. I would simply forbid any >> conflicts. The compiler must insist on explicit renaming of all >> conflicting entities. > > We tried rules on that line, but they caused the sorts of maintenance > problems that aren't really acceptable. It should never be the case that > adding a declaration to a package makes some other package illegal even > though the other package does not use the new declaration. (Yes, I know > there are cases where direct visibility and parent visibility violate this > principle, but just because the language is already wrong doesn't mean it > should be made wronger. :-) > [Keep in mind I'm talking about an *addition* and not a modification of a > declaration. The principle is that adding new features to a package > shouldn't cause clients that don't use those features to need modification.] This goal is unreachable in principle. It is the same delusion as behind the LSP. There is not such thing as safe extension or addition, alas. That should not hinder use of addition (in either form of a subtype or an extended package). > Another cause of problems was diamond inheritance, where an integrated > package tries to add a declaration that is already directly visible by some > other path. We definitely don't want those to conflict, but it is very hard > to craft rules that have the right effect (in large part because visibility > is based on "views", not "entities", and these clearly are different views). Yep, that must be fixed. It must be clear where the semantics is referential and where it is not. Presently it is so as if there were no difference, but this concept is clearly not maintainable anymore. >> It is rather a perceived problem so long declaration scopes cannot be named >> an reused. Once we would use them as named entities, construct and design >> them intentionally, the problem would disappear. > > Maybe, but the evidence is that handling the conflicts is a major > maintenance problem. Right, that is why we have to address this. In particular to flag conflicts as errors rather than letting them slipping through the layers of packages to the point where there is no easy way to fix the problem. Early error detection is the Ada's strength. If we had means to design declaration scopes, then instead of patching conflicting packages, we could create an integration package which would resolve conflicts and use that package instead of both. > One thing that clearly would help would be to make all entities > overloadable. In that case, there would be far fewer conflicts (objects > would overload on their types, and could overload with functions and > procedures as well), so perhaps we could live with the conflicts. But that > would be hugely expensive in existing Ada compilers (pretty much all of the > visibility mechanisms would have to be redone from scratch), and it is > unlikely that it could be done compatibly with existing code. We, the programmers, do not care. That is your problem! (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-13 15:46 ` Dmitry A. Kazakov 2012-01-13 17:42 ` georg bauhaus 2012-01-14 0:26 ` Randy Brukardt @ 2012-01-14 2:41 ` Robert A Duff 2 siblings, 0 replies; 41+ messages in thread From: Robert A Duff @ 2012-01-14 2:41 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > Cool! I never thought about that. Thanks! You're welcome! >>> BTW, I always wondered why cannot we have multiple parents of a package in >>> Ada? >> >> Sounds hugely complicated. > > Why? The only complicated thing would naming of the files. Tree structures are easier to understand than more-complicated graphs. I think it would make the visibility rules more complicated for users (and harder to implement). I'm not sure how to deal with private vs. public children. Probably other stuff I haven't thought of. Isn't Ada 2012 complicated enough? ;-) > Instantiation of multiple parent's generic child must be fun, but no more > than generic child already is. Yeah, well, generics multiply the complexity of anything they interact with. - Bob ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-13 10:00 ` Dmitry A. Kazakov 2012-01-13 10:38 ` georg bauhaus 2012-01-13 10:52 ` AdaMagica @ 2012-01-13 17:23 ` Adam Beneschan 2012-01-14 2:41 ` Robert A Duff 2 siblings, 1 reply; 41+ messages in thread From: Adam Beneschan @ 2012-01-13 17:23 UTC (permalink / raw) On Jan 13, 2:00 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > On Fri, 13 Jan 2012 01:35:58 -0800 (PST), AdaMagica wrote: > > On 13 Jan., 10:07, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > > wrote: > >> On Fri, 13 Jan 2012 00:47:35 -0800 (PST), AdaMagica wrote: > >>> On 13 Jan., 09:23, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > >>> wrote: > >>>> On Thu, 12 Jan 2012 17:26:34 -0800 (PST), Adam Beneschan wrote: > >>>>> But then again, with extended returns, you don't need to cook up a > >>>>> value. The code: > > >>>>> -- needed to please the compiler: > >>>>> return (Ada.Finalization.Limited_Controlled > >>>>> with others => <>); > > >>>>> could be written more simply as > > >>>>> return Dummy : T; > > >>>> Not when T requires initialization, i.e. publicly has boxed discriminants. > >>> Of course this is legal since it's in the scope of the full view (it's > >>> a definite type in the full view, an indefinite only in the partial > >>> view). > > >> Only if you have that full view in the function body. > > > What do you want to say? Isn't that exactly what I said? > > package P is > type T (<>) is private; > private > type T is new Integer; > end P; > > with P; use P; > package Q is > function Foo return T; > end Q; > > package body Q is > function Foo return T is > begin > raise Constraint_Error; > return Dummy : T; -- No, that won't work! > end Foo; > end Q; > > The requirement to have a meaningless return might turn to be a serious > trouble. The example above might look constructed, but things like this > happen relatively frequently in large projects. And when they do, it forces > interfaces and package hierarchies reworked. Nasty thing. I think that most likely, if I had a package P that declared a type like this, it would also declare some function (or a deferred constant) to represent some sort of "empty" or "null" or "undefined" value. I guess one could come up with a case where it wouldn't be needed, but I haven't come across one; in my experience, it's *always* been useful to have a value like that that can be used by users of the package. Anyway, having something like that would make the problem moot, in your example. -- Adam ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-13 17:23 ` Adam Beneschan @ 2012-01-14 2:41 ` Robert A Duff 0 siblings, 0 replies; 41+ messages in thread From: Robert A Duff @ 2012-01-14 2:41 UTC (permalink / raw) Adam Beneschan <adam@irvine.com> writes: > I think that most likely, if I had a package P that declared a type > like this, it would also declare some function (or a deferred > constant) to represent some sort of "empty" or "null" or "undefined" > value. Have you read "The Billion Dollar Mistake", by C.A.R. Hoare? - Bob ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-13 8:23 ` Dmitry A. Kazakov 2012-01-13 8:47 ` AdaMagica @ 2012-01-13 17:15 ` Adam Beneschan 1 sibling, 0 replies; 41+ messages in thread From: Adam Beneschan @ 2012-01-13 17:15 UTC (permalink / raw) On Jan 13, 12:23 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > On Thu, 12 Jan 2012 17:26:34 -0800 (PST), Adam Beneschan wrote: > > But then again, with extended returns, you don't need to cook up a > > value. The code: > > > -- needed to please the compiler: > > return (Ada.Finalization.Limited_Controlled > > with others => <>); > > > could be written more simply as > > > return Dummy : T; > > Not when T requires initialization, i.e. publicly has boxed discriminants. Or if T is any other indefinite type, such as an unconstrained array (including String) or a classwide type. -- Adam ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-13 0:21 ` Randy Brukardt 2012-01-13 1:26 ` Adam Beneschan @ 2012-01-13 20:06 ` Blady 2012-01-13 23:30 ` Adam Beneschan 2012-01-14 10:20 ` Maciej Sobczak 2 siblings, 1 reply; 41+ messages in thread From: Blady @ 2012-01-13 20:06 UTC (permalink / raw) On 13 jan, 01:21, "Randy Brukardt" <ra...@rrsoftware.com> wrote: > "Maciej Sobczak" <see.my.homep...@gmail.com> wrote in message > > news:01dd6341-9c3c-4dcb-90f8-6ac66c65eb66@z1g2000vbx.googlegroups.com... > ... > > > 1. Adjust should not be allowed to be declared (it is a *limited* > > type). But I have defined it to trace the remaining bugs: > > There's nothing wrong with defining "Adjust" (you can define any named > subprogram you want, of course), but (A) "overriding" shouldn't be allowed > on it, and (B) it shouldn't be called automatically if it is defined without > "overriding", because it is not special for a limited type. > 8< ... >8 > > Randy. Hello, back to point 1), assuming GNAT is used, the private spec of Ada.Finalization is package SFR renames System.Finalization_Root; type Controlled is abstract new SFR.Root_Controlled with null record; -- In order to simplify the implementation, the mechanism in Process_Full_ -- View ensures that the full view is limited even though the parent type -- is not. type Limited_Controlled is abstract new SFR.Root_Controlled with null record; and type Root_Controlled is tagged null record; procedure Adjust (Object : in out Root_Controlled); procedure Finalize (Object : in out Root_Controlled); procedure Initialize (Object : in out Root_Controlled); So with GNAT Adjust is part of Limited_Controlled primitives, isn't it? Best, Pascal. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-13 20:06 ` Blady @ 2012-01-13 23:30 ` Adam Beneschan 2012-01-14 13:29 ` Brian Drummond 0 siblings, 1 reply; 41+ messages in thread From: Adam Beneschan @ 2012-01-13 23:30 UTC (permalink / raw) On Jan 13, 12:06 pm, Blady <p....@orange.fr> wrote: > > > > 1. Adjust should not be allowed to be declared (it is a *limited* > > > type). But I have defined it to trace the remaining bugs: > > > There's nothing wrong with defining "Adjust" (you can define any named > > subprogram you want, of course), but (A) "overriding" shouldn't be allowed > > on it, and (B) it shouldn't be called automatically if it is defined without > > "overriding", because it is not special for a limited type. > Hello, > back to point 1), assuming GNAT is used, the private spec of > Ada.Finalization is > package SFR renames System.Finalization_Root; > type Controlled is abstract new SFR.Root_Controlled with null > record; > -- In order to simplify the implementation, the mechanism in > Process_Full_ > -- View ensures that the full view is limited even though the > parent type > -- is not. > type Limited_Controlled is > abstract new SFR.Root_Controlled with null record; > and > type Root_Controlled is tagged null record; > procedure Adjust (Object : in out Root_Controlled); > procedure Finalize (Object : in out Root_Controlled); > procedure Initialize (Object : in out Root_Controlled); > So with GNAT Adjust is part of Limited_Controlled primitives, isn't > it? > > Best, Pascal. Since Limited_Controlled is derived from SFR.Root_Controlled in the *private* part of Ada.Finalization, any primitive operations that get inherited shouldn't be visible to any place that can't see the private part of Ada.Finalization; and therefore this should not affect the legality of anything. Maciej's package says overriding procedure Adjust (...) which is illegal because Adjust isn't supposed to be visible to his package. If GNAT is accepting this, this means that some stuff that should be invisible is visible, and that's a bug. -- Adam ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-13 23:30 ` Adam Beneschan @ 2012-01-14 13:29 ` Brian Drummond 2012-01-19 1:47 ` Randy Brukardt 0 siblings, 1 reply; 41+ messages in thread From: Brian Drummond @ 2012-01-14 13:29 UTC (permalink / raw) On Fri, 13 Jan 2012 15:30:37 -0800, Adam Beneschan wrote: > Maciej's package says > > overriding procedure Adjust (...) > > which is illegal because Adjust isn't supposed to be visible to his > package. If GNAT is accepting this, this means that some stuff that > should be invisible is visible, and that's a bug. > > -- Adam Recalling an earlier conversation : this (visibility of private parts) strikes me as a candidate for submission to the ACATS suite; though it would surprise me if ACATS doesn't cover this in some depth already. One question is : can the same error be reproduced with a less specific test case (type A is interface ... ), or has Gnat special-cased controlled types such that the error only appears with Ada.Finalization and procedures named Adjust etc? The latter I can understand to some extent; but if the former ... what went wrong? - Brian ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-14 13:29 ` Brian Drummond @ 2012-01-19 1:47 ` Randy Brukardt 2012-01-19 4:24 ` Adam Beneschan 0 siblings, 1 reply; 41+ messages in thread From: Randy Brukardt @ 2012-01-19 1:47 UTC (permalink / raw) "Brian Drummond" <brian@shapes.demon.co.uk> wrote in message news:jes008$q0f$1@dont-email.me... > On Fri, 13 Jan 2012 15:30:37 -0800, Adam Beneschan wrote: ... > Recalling an earlier conversation : this (visibility of private parts) > strikes me as a candidate for submission to the ACATS suite; though it > would surprise me if ACATS doesn't cover this in some depth already. Keep in mind that the ACATS doesn't try to guess the errors that a compiler implementer might make, as that is nearly an infinite set. Rather, it tries to have at least one test of Legality Rule in the standard; combinations of multiple rules (as in this case) are not a priority. The Ada 83 ACVC tried much hard to make such guesses. But the effect was a lot of rather pointless tests that tried to guess what syntax a compiler writer might want to allow beyond that in the Standard. All of those tests were removed from the Ada 95 ACVC (which became the ACATS), as their only value was to stress compiler syntax error correction/handling (which is not an intended purpose of the ACATS!). Indeed, there is rule against including syntax error tests in the ACATS (with an exception made for "syntax" that most likely will be enforced post-syntax; one example is the rules about others limbs in case statements). Which is a long way to say that I don't think there is any attempt to declare Adjust for a limited type, and if there is, it would be an Ada 95 C-Test in which case there would be no "overriding" involved. Randy. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-19 1:47 ` Randy Brukardt @ 2012-01-19 4:24 ` Adam Beneschan 2012-01-20 0:04 ` Randy Brukardt 0 siblings, 1 reply; 41+ messages in thread From: Adam Beneschan @ 2012-01-19 4:24 UTC (permalink / raw) On Jan 18, 5:47 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote: > "Brian Drummond" <br...@shapes.demon.co.uk> wrote in message > > news:jes008$q0f$1@dont-email.me... > > > On Fri, 13 Jan 2012 15:30:37 -0800, Adam Beneschan wrote: > ... > > Recalling an earlier conversation : this (visibility of private parts) > > strikes me as a candidate for submission to the ACATS suite; though it > > would surprise me if ACATS doesn't cover this in some depth already. > > Keep in mind that the ACATS doesn't try to guess the errors that a compiler > implementer might make, as that is nearly an infinite set. And some days it seems like I've made all of them. Of course, I could really quibble about what "nearly infinite" means. However big the set of possible errors is, I'm sure it's still billions, maybe even trillions, short of infinity. :) -- Adam ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-19 4:24 ` Adam Beneschan @ 2012-01-20 0:04 ` Randy Brukardt 0 siblings, 0 replies; 41+ messages in thread From: Randy Brukardt @ 2012-01-20 0:04 UTC (permalink / raw) "Adam Beneschan" <adam@irvine.com> wrote in message news:75df28b7-e784-41a1-9c40-9520fb6f1c0d@v14g2000yqh.googlegroups.com... >On Jan 18, 5:47 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote: >> "Brian Drummond" <br...@shapes.demon.co.uk> wrote in message >> ... >> > Recalling an earlier conversation : this (visibility of private parts) >> > strikes me as a candidate for submission to the ACATS suite; though it >> > would surprise me if ACATS doesn't cover this in some depth already. >> >> Keep in mind that the ACATS doesn't try to guess the errors that a >> compiler >> implementer might make, as that is nearly an infinite set. > >And some days it seems like I've made all of them. Been there, done that. >Of course, I could really quibble about what "nearly infinite" means. >However big the set of possible errors is, I'm sure it's still >billions, maybe even trillions, short of infinity. :) True enough. For the purposes of a test suite, it might as well be infinite, even if the actual number is "finite but very large". An ACATS with 10 billion tests would be hard to process... Aside: I note that security testers are putting a lot of work into "fuzzing" tools. One could imagine building such a tool for Ada syntax; it could create thousands of programs each containing a single error in many different ways. But I'd be somewhat dubious about the value of such a tool, as it would a take a lot of effort to create and probably wouldn't find a lot of errors. (Mainly because many compilers use a table-driven parser [Janus/Ada does], so the only way to get parsing errors is to have mistakes in the original grammar definition. Those happen, but they're relatively obvious and easy to fix when found. Even in compilers with hand-written parsers, [like GNAT], errors are fairly unlikely and obvious.) A fuzzing tool would be a lot more useful if it could generate Legality errors automatically, but I don't think that is possible beyond a very limited subset. Randy. -- Adam ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-13 0:21 ` Randy Brukardt 2012-01-13 1:26 ` Adam Beneschan 2012-01-13 20:06 ` Blady @ 2012-01-14 10:20 ` Maciej Sobczak 2012-01-14 14:03 ` Brian Drummond 2012-01-16 16:35 ` Adam Beneschan 2 siblings, 2 replies; 41+ messages in thread From: Maciej Sobczak @ 2012-01-14 10:20 UTC (permalink / raw) On Jan 13, 1:21 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote: > > 3. Logically, Tmp is never created, because Make_T raises an > > exception. Somehow some object is finalized. Apparently it is Tmp, > > which should not exist. > > 4. Somehow Tmp.initialized = True, even though its default value is > > defined to be False. > > I'm not sure if these are actually bugs or not; the fact that Adjust is > being called for a limited object means to me that nothing that happens > afterwards makes any sense Adjust is not called, but I have defined it to check if that's the case. Still, Adjust is not the biggest issue here, neither is the requirement for the return statement. The biggest issue is that the compiler fails to initialize some object (even ignoring the statically provided field initializers) and yet considers it to be worthy finalization - and the Finalize operation has absolutely no line of defense against this. This is a *very* serious problem. I have found it, because my program was crashing. And since this relates to the very fundamentals of the object model, this bug is not to be ignored. I can live with the rest, but this one is really serious. The workaround is this: type T is limited private; (note the lack of indefinite constraint - that is, we allow default objects) and then: procedure Init (Val : in out T; whateverelsehere); This works, but introduces the notion of uninitialized (default) object. The original version was stronger as it only allowed full proper objects. -- Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-14 10:20 ` Maciej Sobczak @ 2012-01-14 14:03 ` Brian Drummond 2012-01-16 16:35 ` Adam Beneschan 1 sibling, 0 replies; 41+ messages in thread From: Brian Drummond @ 2012-01-14 14:03 UTC (permalink / raw) On Sat, 14 Jan 2012 02:20:19 -0800, Maciej Sobczak wrote: > The biggest issue is that the compiler fails > to initialize some object (even ignoring the statically provided field > initializers) and yet considers it to be worthy finalization - and the > Finalize operation has absolutely no line of defense against this. This > is a *very* serious problem. I would agree with that! However the following may be of interest: brian@linnet:~/projects/ada/bugs> gnat --version GNAT 4.6.2 20111212 [gcc-4_6-branch revision 182222] Copyright 1996-2010, Free Software Foundation, Inc. ... brian@linnet:~/projects/ada/bugs> gnatmake test ... gnatlink: warning: executable name "test" may conflict with shell command brian@linnet:~/projects/ada/bugs> ./test exception handled brian@linnet:~/projects/ada/bugs> Not a whisper from finalization. However it still doesn't flag Adjust as illegal. - Brian ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-14 10:20 ` Maciej Sobczak 2012-01-14 14:03 ` Brian Drummond @ 2012-01-16 16:35 ` Adam Beneschan 2012-01-20 10:43 ` Brian Drummond 1 sibling, 1 reply; 41+ messages in thread From: Adam Beneschan @ 2012-01-16 16:35 UTC (permalink / raw) On Jan 14, 2:20 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote: > On Jan 13, 1:21 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote: > > > > 3. Logically, Tmp is never created, because Make_T raises an > > > exception. Somehow some object is finalized. Apparently it is Tmp, > > > which should not exist. > > > 4. Somehow Tmp.initialized = True, even though its default value is > > > defined to be False. > > > I'm not sure if these are actually bugs or not; the fact that Adjust is > > being called for a limited object means to me that nothing that happens > > afterwards makes any sense > > Adjust is not called, but I have defined it to check if that's the > case. > Still, Adjust is not the biggest issue here, neither is the > requirement for the return statement. > The biggest issue is that the compiler fails to initialize some object > (even ignoring the statically provided field initializers) and yet > considers it to be worthy finalization - and the Finalize operation > has absolutely no line of defense against this. This is a *very* > serious problem. > I have found it, because my program was crashing. > And since this relates to the very fundamentals of the object model, > this bug is not to be ignored. I can live with the rest, but this one > is really serious. I think what Randy was getting at--and I concur with this--is that if you can create a *legal* program that has the bug you're concerned about (i.e. one that does not try to override a non-existent Adjust), then it's a serious problem and you should definitely report it. But if you can't, I wouldn't worry about it. You're probably thinking that you've run across a serious problem in the object model that's **independent** of the Adjust visibility issue. But to me, there's a good chance that this problem is intertwined with the Adjust problem, not independent of it. That's because as a compiler developer myself, I'm aware of the kind of special things compilers need to do to handle Controlled and Limited_Controlled. If something goes wrong with that, I can easily imagine how this could lead to all sorts of other things going wrong. -- Adam ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: How many Ada compiler bugs are here? 2012-01-16 16:35 ` Adam Beneschan @ 2012-01-20 10:43 ` Brian Drummond 0 siblings, 0 replies; 41+ messages in thread From: Brian Drummond @ 2012-01-20 10:43 UTC (permalink / raw) On Mon, 16 Jan 2012 08:35:55 -0800, Adam Beneschan wrote: > On Jan 14, 2:20 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote: >> Adjust is not called, but I have defined it to check if that's the >> case. > I think what Randy was getting at--and I concur with this--is that if > you can create a *legal* program that has the bug you're concerned about > (i.e. one that does not try to override a non-existent Adjust), then > it's a serious problem and you should definitely report it. But if you > can't, I wouldn't worry about it. You're probably thinking that you've > run across a serious problem in the object model that's **independent** > of the Adjust visibility issue. But to me, there's a good chance that > this problem is intertwined with the Adjust problem, not independent of > it. That was my concern too. However my limited attempts to create a testcase for visibility errors independent of controlled types, failed to do so. I believe you are correct that it arises out of some special case handling, and nothing deeper. - Brian ^ permalink raw reply [flat|nested] 41+ messages in thread
end of thread, other threads:[~2012-01-20 10:43 UTC | newest] Thread overview: 41+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-01-12 23:20 How many Ada compiler bugs are here? Maciej Sobczak 2012-01-13 0:21 ` Randy Brukardt 2012-01-13 1:26 ` Adam Beneschan 2012-01-13 8:23 ` Dmitry A. Kazakov 2012-01-13 8:47 ` AdaMagica 2012-01-13 9:07 ` Dmitry A. Kazakov 2012-01-13 9:35 ` AdaMagica 2012-01-13 10:00 ` Dmitry A. Kazakov 2012-01-13 10:38 ` georg bauhaus 2012-01-13 11:39 ` Dmitry A. Kazakov 2012-01-13 12:43 ` Georg Bauhaus 2012-01-13 13:06 ` AdaMagica 2012-01-13 13:16 ` AdaMagica 2012-01-13 13:22 ` Georg Bauhaus 2012-01-13 13:29 ` Dmitry A. Kazakov 2012-01-13 10:52 ` AdaMagica 2012-01-13 11:35 ` Dmitry A. Kazakov 2012-01-13 12:58 ` AdaMagica 2012-01-13 13:43 ` Dmitry A. Kazakov 2012-01-13 15:06 ` Robert A Duff 2012-01-13 15:46 ` Dmitry A. Kazakov 2012-01-13 17:42 ` georg bauhaus 2012-01-13 18:52 ` Dmitry A. Kazakov 2012-01-14 0:26 ` Randy Brukardt 2012-01-14 9:49 ` Dmitry A. Kazakov 2012-01-19 1:35 ` Randy Brukardt 2012-01-19 10:33 ` Dmitry A. Kazakov 2012-01-14 2:41 ` Robert A Duff 2012-01-13 17:23 ` Adam Beneschan 2012-01-14 2:41 ` Robert A Duff 2012-01-13 17:15 ` Adam Beneschan 2012-01-13 20:06 ` Blady 2012-01-13 23:30 ` Adam Beneschan 2012-01-14 13:29 ` Brian Drummond 2012-01-19 1:47 ` Randy Brukardt 2012-01-19 4:24 ` Adam Beneschan 2012-01-20 0:04 ` Randy Brukardt 2012-01-14 10:20 ` Maciej Sobczak 2012-01-14 14:03 ` Brian Drummond 2012-01-16 16:35 ` Adam Beneschan 2012-01-20 10:43 ` Brian Drummond
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox