Bug in Ada (SuSe 10.2) ?

Bug in Ada (SuSe 10.2) ?

[Reinert Korsnes]

Hi there,

could anyone try the test program below 
(which should output only positive numbers or error message).

I get the following output (running SuSe 10.2,
updated per 19 feb 2008):

                   1
                   2
                   6
                  24
                 120
                 720
                5040
               40320
              362880
             3628800
            39916800
           479001600
          1932053504
          1278945280
          2004310016
          2004189184
          -288522240
          -898433024
           109641728
         -2102132736'

The program should give an "integer out of range" error message ?

I compiled the program with the following command:
gnatmake -gnat05 test2


----------------------------------------------------
with Text_IO;
use  Text_IO;
procedure test2 is

  package Int_Io is new Text_IO.Integer_Io (Integer);
  use Int_Io;

  k : Integer := 1;
  n : Integer := 20;

begin

    for i in 1..n loop
        k := k * i;
        Put(k,20);New_Line;
    end loop;

end test2;

Re: Bug in Ada (SuSe 10.2) ?

[Niklas Holsti]

Reinert Korsnes wrote:
> Hi there,
> 
> could anyone try the test program below 
> (which should output only positive numbers or error message).
> ...
> The program should give an "integer out of range" error message ?

GNAT does not generate run-time overflow checks by default.

> I compiled the program with the following command:
> gnatmake -gnat05 test2

Add the option -gnato to enable run-time overflow checks. You 
should then get:

                    1
                    2
                    6
                   24
                  120
                  720
                 5040
                40320
               362880
              3628800
             39916800
            479001600

raised CONSTRAINT_ERROR : test2.adb:14 overflow check failed


HTH

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Bug in Ada (SuSe 10.2) ?

[Reinert Korsnes]

Thanks, I see,

I looked for a general "safe mode" under gnat.
Did not find. Is there any ?

reinert


Niklas Holsti wrote:

> Reinert Korsnes wrote:
>> Hi there,
>> 
>> could anyone try the test program below
>> (which should output only positive numbers or error message).
>> ...
>> The program should give an "integer out of range" error message ?
> 
> GNAT does not generate run-time overflow checks by default.
> 
>> I compiled the program with the following command:
>> gnatmake -gnat05 test2
> 
> Add the option -gnato to enable run-time overflow checks. You
> should then get:
> 
>                     1
>                     2
>                     6
>                    24
>                   120
>                   720
>                  5040
>                 40320
>                362880
>               3628800
>              39916800
>             479001600
> 
> raised CONSTRAINT_ERROR : test2.adb:14 overflow check failed
> 
> 
> HTH
> 
> --
> Niklas Holsti
> Tidorum Ltd
> niklas holsti tidorum fi
>        .      @       .

Re: Bug in Ada (SuSe 10.2) ?

[Ludovic Brenta]

Reinert Korsnes wrote:
> I looked for a general "safe mode" under gnat. Did not find. Is there any ?

gnatmake -gnatafo -gnatVa -fstack-check

Also see http://gcc.gnu.org/PR34117 and http://gcc.gnu.org/PR34118.

--
Ludovic Brenta.

Re: Bug in Ada (SuSe 10.2) ?

[Reinert Korsnes]

Thanks alot,

By the way: "safe mode" should be default
according to the "spirit" of Ada ?

reinert

Ludovic Brenta wrote:

> Reinert Korsnes wrote:
>> I looked for a general "safe mode" under gnat. Did not find. Is there any
>> ?
> 
> gnatmake -gnatafo -gnatVa -fstack-check
> 
> Also see http://gcc.gnu.org/PR34117 and http://gcc.gnu.org/PR34118.
> 
> --
> Ludovic Brenta.

Re: Bug in Ada (SuSe 10.2) ?

[Adam Beneschan]

On Feb 20, 4:41 am, Reinert Korsnes <a...@b.no> wrote:
> Thanks alot,
>
> By the way: "safe mode" should be default
> according to the "spirit" of Ada ?

That would perhaps be taking things too far.  I'm sure the reason that
this "safe mode" is not the default is because the needed overflow
checks are relatively expensive, depending on the processor.  It's a
trade-off.  But Ada is intended to be a tool to be put to practical
use, not a statue for us to all gather around and admire its purity of
spirit.

                                  -- Adam

Re: Bug in Ada (SuSe 10.2) ?

[Jeffrey R. Carter]

Adam Beneschan wrote:
> 
> That would perhaps be taking things too far.  I'm sure the reason that
> this "safe mode" is not the default is because the needed overflow
> checks are relatively expensive, depending on the processor.  It's a
> trade-off.  But Ada is intended to be a tool to be put to practical
> use, not a statue for us to all gather around and admire its purity of
> spirit.

I think that was true originally, on certain processors, but I think it's not 
still true. I never accepted that it was a valid reason for the defaults not to 
be Ada. The simple explanation is that GNAT, by default, is not an Ada compiler. 
You need at a minimum -gnato and -fstack-check for it to be so.

-- 
Jeff Carter
"English bed-wetting types."
Monty Python & the Holy Grail
15

Re: Bug in Ada (SuSe 10.2) ?

[Adam Beneschan]

On Feb 20, 10:31 am, "Jeffrey R. Carter"
<spam.jrcarter....@acm.nospam.org> wrote:
> Adam Beneschan wrote:
>
> > That would perhaps be taking things too far.  I'm sure the reason that
> > this "safe mode" is not the default is because the needed overflow
> > checks are relatively expensive, depending on the processor.  It's a
> > trade-off.  But Ada is intended to be a tool to be put to practical
> > use, not a statue for us to all gather around and admire its purity of
> > spirit.
>
> I think that was true originally, on certain processors, but I think it's not
> still true. I never accepted that it was a valid reason for the defaults not to
> be Ada. The simple explanation is that GNAT, by default, is not an Ada compiler.
> You need at a minimum -gnato and -fstack-check for it to be so.
>
> --
> Jeff Carter
> "English bed-wetting types."
> Monty Python & the Holy Grail
> 15

Re: Bug in Ada (SuSe 10.2) ?

[Adam Beneschan]

On Feb 20, 10:31 am, "Jeffrey R. Carter"
<spam.jrcarter....@acm.nospam.org> wrote:

(Sorry for the null reply last time...)


> Adam Beneschan wrote:
>
> > That would perhaps be taking things too far.  I'm sure the reason that
> > this "safe mode" is not the default is because the needed overflow
> > checks are relatively expensive, depending on the processor.  It's a
> > trade-off.  But Ada is intended to be a tool to be put to practical
> > use, not a statue for us to all gather around and admire its purity of
> > spirit.
>
> I think that was true originally, on certain processors, but I think it's not
> still true.

I'm not quite sure what this means, and what would have changed...
There are definitely processors on which Ada is available for which
integer overflow checks would add a significant execution penalty.
(One processor I'm working with not only doesn't have the ability to
fault on integer overflow, it doesn't even have a condition code
status bit of any sort to indicate overflow.)  I guess I'm not sure
what you mean by this.


> I never accepted that it was a valid reason for the defaults not to
> be Ada. The simple explanation is that GNAT, by default, is not an Ada
> compiler.
> You need at a minimum -gnato and -fstack-check for it to be so.

Well, if you're going to be pedantic, then even with those flags GNAT
is not an Ada compiler, because I can give it Ada programs that it
doesn't compile (not to mention non-Ada programs that it doesn't
reject, and Ada programs that run incorrectly after GNAT compiles
them).  And the same is doubtless true of any other compiler.  GNAT
will not be an Ada compiler until they finally get the Last Bug out,
which isn't going to happen because by the time they finally get Ada
2005 to be working 100% correctly, the Ada language will be up to Ada
2067 or so.

So maybe it's ridiculously pedantic to claim it's not Ada for that
reason---but probably no moreso than for your reason.

                                     -- Adam

Re: Bug in Ada (SuSe 10.2) ?

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message
news:48277611-402f-4622-be05-6edddf6dd56a@o10g2000hsf.googlegroups.com...
> On Feb 20, 10:31 am, "Jeffrey R. Carter"
> <spam.jrcarter....@acm.nospam.org> wrote:
> > I never accepted that it was a valid reason for the defaults not to
> > be Ada. The simple explanation is that GNAT, by default, is not an Ada
> > compiler.
> > You need at a minimum -gnato and -fstack-check for it to be so.
>
> Well, if you're going to be pedantic, then even with those flags GNAT
> is not an Ada compiler, because I can give it Ada programs that it
> doesn't compile (not to mention non-Ada programs that it doesn't
> reject, and Ada programs that run incorrectly after GNAT compiles
> them).  And the same is doubtless true of any other compiler.  GNAT
> will not be an Ada compiler until they finally get the Last Bug out,
> which isn't going to happen because by the time they finally get Ada
> 2005 to be working 100% correctly, the Ada language will be up to Ada
> 2067 or so.
>
> So maybe it's ridiculously pedantic to claim it's not Ada for that
> reason---but probably no moreso than for your reason.

Well, maybe you are write pedantically, but I would counterclaim that there
is a big difference between a compiler that fails to compile Ada by an
oversight (that is a bug) and one that does so intentionally.

In any case, I agree with Jeff that this is a bad thing. Overflow checking
is a feature of Ada that sets it apart from other languages, and it is bad
for it not to be supported by default. It would be like a compiler skipping
range checking or variant discriminant checking by default "because they're
too expensive". The Ada language even provides a way to turn those things
off if they are too expensive -- that surely suggests that the default
should be that these checks are present.

The other obvious evidence that this is a bad thing is that OP's question:
which we see here several times a year. It would obviously be better if we
didn't have to deal with that (and remember that many people will not
actually write such a question, so there probably are many more that are
confused).

Of course, this is just griping about a particular implementation. It is
always important to remember that Ada /= GNAT.

                                             Randy.

Re: Bug in Ada (SuSe 10.2) ?

[Jeffrey R. Carter]

Adam Beneschan wrote:
> 
> I'm not quite sure what this means, and what would have changed...
> There are definitely processors on which Ada is available for which
> integer overflow checks would add a significant execution penalty.
> (One processor I'm working with not only doesn't have the ability to
> fault on integer overflow, it doesn't even have a condition code
> status bit of any sort to indicate overflow.)  I guess I'm not sure
> what you mean by this.

I guess I could have been clearer. I meant on commonly used, current processors, 
and it may not be that the check is no longer expensive, but simply that it's 
not as expensive as it used to be. And I'm not an expert in these things.

> Well, if you're going to be pedantic, then even with those flags GNAT
> is not an Ada compiler, because I can give it Ada programs that it
> doesn't compile (not to mention non-Ada programs that it doesn't
> reject, and Ada programs that run incorrectly after GNAT compiles
> them).  And the same is doubtless true of any other compiler.  GNAT
> will not be an Ada compiler until they finally get the Last Bug out,
> which isn't going to happen because by the time they finally get Ada
> 2005 to be working 100% correctly, the Ada language will be up to Ada
> 2067 or so.
> 
> So maybe it's ridiculously pedantic to claim it's not Ada for that
> reason---but probably no moreso than for your reason.

I think there's quite a bit of difference between having (almost) all programs 
deliberately fail to implement the Ada semantics, and having an unintentional 
error in a compiler. The latter is trying to implement Ada; the former isn't. 
With its default options, GNAT is much more like the former than the latter.

-- 
Jeff Carter
"English bed-wetting types."
Monty Python & the Holy Grail
15

Re: Bug in Ada (SuSe 10.2) ?

[Jeffrey R. Carter]

Jeffrey R. Carter wrote:
> 
> I think there's quite a bit of difference between having (almost) all 
> programs deliberately fail to implement the Ada semantics, and having an 
> unintentional error in a compiler. The latter is trying to implement 
> Ada; the former isn't. With its default options, GNAT is much more like 
> the former than the latter.

More to the point, perhaps, is that it's interesting to see a posting here about 
the latter, but the 1_000th posting asking why GNAT doesn't catch integer 
overflow isn't.

-- 
Jeff Carter
"English bed-wetting types."
Monty Python & the Holy Grail
15

Re: Bug in Ada (SuSe 10.2) ?

[tmoran]

> > The simple explanation is that GNAT, by default, is not an Ada compiler.
> will not be an Ada compiler until they finally get the Last Bug out,
   Technically it's an Ada compiler if and only if it passes the
validation tests, and the default Gnat therefore isn't an Ada compiler,
and shouldn't be advertised as one.  If it its bugs were sufficiently
obscure they are not detected by the validation tests, then it would be an
Ada compiler.
   More importantly, how many times have we seen postings here from people
new to Ada saying "I heard about Ada, this supposedly highly safe
language, but it doesn't even catch an overflow, though the manual claims
it does."?  vs How many times have people new to Ada posted messages
asking about some obscure compiler bug they've stumbled across.

Re: Bug in Ada (SuSe 10.2) ?

[billjones6789]

On Feb 20, 4:55 pm, tmo...@acm.org wrote:
>    Technically it's an Ada compiler if and only if it passes the
> validation tests, and the default Gnat therefore isn't an Ada compiler,
> and shouldn't be advertised as one.  If it its bugs were sufficiently
> obscure they are not detected by the validation tests, then it would be an
> Ada compiler.

This was true prior to 30 November 1987, when the US DoD held a
registered trademark on the name Ada, and allowed use of the
trademark
only with validated compilers.  But the Ada trademark was allowed to
lapse, so there has not been any such restriction for over 20 years.

There is no mention in the Ada RM of "passing the validation tests".
Instead, it says (RM 95 1.1.5 paragraph 11) "An implementation may
provide nonstandard modes of operation. ... In any case, an
implementation
shall support a standard mode that conforms to the requirements of
this
International Standard; in particular, in the standard mode, all legal
compilation_units shall be accepted."

There is no mention in the Ada RM of "default compiler switches",
just "standard mode" and optionally "nonstandard modes".  So as long
as -gnato is considered part of "standard mode", there not any
technical problem calling it an Ada compiler (assuming of course that
"all legal compilation_units are accepted").

Re: Bug in Ada (SuSe 10.2) ?

[Jean-Pierre Rosen]

Randy Brukardt a �crit :
> The other obvious evidence that this is a bad thing is that OP's question:
> which we see here several times a year. It would obviously be better if we
> didn't have to deal with that (and remember that many people will not
> actually write such a question, so there probably are many more that are
> confused).
> 
Hmm... maybe we coud suggest to AdaCore (anybody listening?) that the 
GPL version should have the checks on by default, and let the default be 
what paying customers demand for the Pro version. After all, GnatGPL is 
2005 by default, and Pro is 95 by default, so it should be doable.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Bug in Ada (SuSe 10.2) ?

[Alex R. Mosteo]

Jean-Pierre Rosen wrote:
> Randy Brukardt a écrit :
>> The other obvious evidence that this is a bad thing is that OP's
>> question:
>> which we see here several times a year. It would obviously be better
>> if we
>> didn't have to deal with that (and remember that many people will not
>> actually write such a question, so there probably are many more that are
>> confused).
>>
> Hmm... maybe we coud suggest to AdaCore (anybody listening?) that the
> GPL version should have the checks on by default, and let the default be
> what paying customers demand for the Pro version. After all, GnatGPL is
> 2005 by default, and Pro is 95 by default, so it should be doable.

Seems sensible to me. I guess very few of us aware of this issue compile
during development without -gnato

Re: Bug in Ada (SuSe 10.2) ?

[Alex R. Mosteo]

tmoran@acm.org wrote:
>>> The simple explanation is that GNAT, by default, is not an Ada compiler.
>> will not be an Ada compiler until they finally get the Last Bug out,
>    Technically it's an Ada compiler if and only if it passes the
> validation tests, and the default Gnat therefore isn't an Ada compiler,
> and shouldn't be advertised as one.  If it its bugs were sufficiently
> obscure they are not detected by the validation tests, then it would be an
> Ada compiler.
>    More importantly, how many times have we seen postings here from people
> new to Ada saying "I heard about Ada, this supposedly highly safe
> language, but it doesn't even catch an overflow, though the manual claims
> it does."?  vs How many times have people new to Ada posted messages
> asking about some obscure compiler bug they've stumbled across.

vs How many times "my number-crunching program is horribly slow, in
fortran it was lightning fast"?

I /believe/ this has happened maybe once or twice in the last lustrum,
for sure not enough to justify not having -gnato by default.

Re: Bug in Ada (SuSe 10.2) ?

[Ludovic Brenta]

Alex R. Mosteo wrote:
> Jean-Pierre Rosen wrote:
> > Randy Brukardt a écrit :
> >> The other obvious evidence that this is a bad thing is that OP's
> >> question:
> >> which we see here several times a year. It would obviously be better
> >> if we
> >> didn't have to deal with that (and remember that many people will not
> >> actually write such a question, so there probably are many more that are
> >> confused).
> >>
> > Hmm... maybe we coud suggest to AdaCore (anybody listening?) that the
> > GPL version should have the checks on by default, and let the default be
> > what paying customers demand for the Pro version. After all, GnatGPL is
> > 2005 by default, and Pro is 95 by default, so it should be doable.
>
> Seems sensible to me. I guess very few of us aware of this issue compile
> during development without -gnato

The suggestion has already been made in GCC's Bugzilla database which
I mentioned earlier in this thread[1]. A few people have already added
comments supporting the suggestion but AdaCore has not yet implemented
it, or indicated any intention to do so. If anyone is interested they
too can comment on the PR, but better yet would be to submit a patch.

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34117

--
Ludovic Brenta.

Re: Bug in Ada (SuSe 10.2) ?

[billjones6789]

Jean-Pierre Rosen wrote:
> Hmm... maybe we coud suggest to AdaCore (anybody listening?) that the
> GPL version should have the checks on by default, ...

> - Show quoted text -

Including checks for dangling pointers??
What should this print?


with Ada.Text_IO;
procedure Dangling_Pointer is
   type Int_Access is access all integer;

   Save : Int_Access;

   type AirSpeed is record
      Altitude : aliased integer := 9;
   end record;

   type AoA (Rudder: access AirSpeed) is limited null record;

   function WoW (Slats: access AirSpeed) return Int_Access is
   begin
      return Slats.Altitude'Access;
   end;

   procedure Calculate is
      Fuel: aliased AirSpeed;
      Heading: AoA (Fuel'Access);
   begin
      Save := WoW (Heading.Rudder);
      Ada.Text_IO.Put_Line (integer'image(Save.all));
   end Calculate;

   procedure Mess_with_stack is
      Dummy: array(1..10) of integer := (others => 17);
   begin
      null;
   end Mess_with_stack;

begin
   Calculate;
   Mess_with_stack;
   Ada.Text_IO.Put_Line (integer'image(Save.all));
end Dangling_Pointer;

Access type (mis)use (Was: Bug in Ada (SuSe 10.2) ?)

[Jacob Sparre Andersen]

billjones6789@yahoo.com writes:

> What should this print?
>
> with Ada.Text_IO;
> procedure Dangling_Pointer is
>    type Int_Access is access all integer;
>
>    Save : Int_Access;
>
>    type AirSpeed is record
>       Altitude : aliased integer := 9;
>    end record;
>
>    type AoA (Rudder: access AirSpeed) is limited null record;
>
>    function WoW (Slats: access AirSpeed) return Int_Access is
>    begin
>       return Slats.Altitude'Access;
>    end;
>
>    procedure Calculate is
>       Fuel: aliased AirSpeed;
>       Heading: AoA (Fuel'Access);
>    begin
>       Save := WoW (Heading.Rudder);

I would expect the above line to give a compile time error.  If it
doesn't: Why?

Greetings,

Jacob
-- 
"Preserve wildlife, pickle a duck."

Re: Access type (mis)use (Was: Bug in Ada (SuSe 10.2) ?)

[Bob Klungle]

"Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message 
news:ygefxvmv6ir.fsf_-_@hugsarin.dmusyd.edu...
> billjones6789@yahoo.com writes:
>
>> What should this print?
>>
>> with Ada.Text_IO;
>> procedure Dangling_Pointer is
>>    type Int_Access is access all integer;
>>
>>    Save : Int_Access;
>>
>>    type AirSpeed is record
>>       Altitude : aliased integer := 9;
>>    end record;
>>
>>    type AoA (Rudder: access AirSpeed) is limited null record;
>>
>>    function WoW (Slats: access AirSpeed) return Int_Access is
>>    begin
>>       return Slats.Altitude'Access;
>>    end;
>>
>>    procedure Calculate is
>>       Fuel: aliased AirSpeed;
>>       Heading: AoA (Fuel'Access);
>>    begin
>>       Save := WoW (Heading.Rudder);
>
> I would expect the above line to give a compile time error.  If it
> doesn't: Why?
>
> Greetings,
>
> Jacob
> -- 
> "Preserve wildlife, pickle a duck."

For what it is worth, cygwin gnatmake 3.4.4 yields
9
11

cheers...bob

Re: Access type (mis)use (Was: Bug in Ada (SuSe 10.2) ?)

[Jeffrey R. Carter]

Bob Klungle wrote:
> 
> For what it is worth, cygwin gnatmake 3.4.4 yields
> 9
> 11

That might depend on the compiler and optimization level. A good optimizer might 
indicate that the 2nd procedure does nothing with its variable, and eliminate 
it. It might even be able to see that the 2nd procedure does nothing, and 
eliminate the call to it.

-- 
Jeff Carter
"Beyond 100,000 lines of code you
should probably be coding in Ada."
P. J. Plauger
26

Re: Access type (mis)use (Was: Bug in Ada (SuSe 10.2) ?)

[Vadim Godunko]

On 21 фев, 22:40, "Bob Klungle" <bklung...@verizon.net> wrote:
> "Jacob Sparre Andersen" <spa...@nbi.dk> wrote in messagenews:ygefxvmv6ir.fsf_-_@hugsarin.dmusyd.edu...
>
>
>
> > billjones6...@yahoo.com writes:
>
> >> What should this print?
>
> >> with Ada.Text_IO;
> >> procedure Dangling_Pointer is
> >>    type Int_Access is access all integer;
>
> >>    Save : Int_Access;
>
> >>    type AirSpeed is record
> >>       Altitude : aliased integer := 9;
> >>    end record;
>
> >>    type AoA (Rudder: access AirSpeed) is limited null record;
>
> >>    function WoW (Slats: access AirSpeed) return Int_Access is
> >>    begin
> >>       return Slats.Altitude'Access;
> >>    end;
>
> >>    procedure Calculate is
> >>       Fuel: aliased AirSpeed;
> >>       Heading: AoA (Fuel'Access);
> >>    begin
> >>       Save := WoW (Heading.Rudder);
>
> > I would expect the above line to give a compile time error.  If it
> > doesn't: Why?
>
> For what it is worth, cygwin gnatmake 3.4.4 yields
> 9
> 11
>

Where are no problem at this place. Program_Error must be raised
inside the Wow subprogram. Actual accessibility level of the object
passed in Slats is deeper when Int_Access type.

So, this is not a leak in the standard this is just a bug in the
concrete compiler.

Re: Bug in Ada (SuSe 10.2) ?

[Randy Brukardt]

<billjones6789@yahoo.com> wrote in message
news:c8a646bf-47b0-43e6-ae46-d5f820126b07@n77g2000hse.googlegroups.com...
>
> Jean-Pierre Rosen wrote:
> > Hmm... maybe we coud suggest to AdaCore (anybody listening?) that the
> > GPL version should have the checks on by default, ...
> Including checks for dangling pointers??

We're talking about language-defined checks. There are no language-defined
checks for dangling pointers!

> There is no mention in the Ada RM of "default compiler switches",
> just "standard mode" and optionally "nonstandard modes".  So as long
> as -gnato is considered part of "standard mode", there not any
> technical problem calling it an Ada compiler (assuming of course that
> "all legal compilation_units are accepted").

That's the legalistic answer, of course, but it doesn't answer the practical
point: it should be easiest for new users of a compiler to compile in
"standard mode". And, sadly, that is not true for Gnat. The result is a
steady stream of questions to this forum (and most likely elsewhere) from
people who are confused by getting a not-quite-Ada compiler out of the box.

More generally, simply meeting the standard in some fashion does not
necessarily make an implementation practically useful as an Ada
implementation. Neither the Standard nor the ACATS have anything to say
about usability.

                                     Randy.

Re: Bug in Ada (SuSe 10.2) ?

[Randy Brukardt]

"Alex R. Mosteo" <amosteo@unizar.es> wrote in message
news:624tidF21i3nvU2@mid.individual.net...
> tmoran@acm.org wrote:
...
> >    More importantly, how many times have we seen postings here from
people
> > new to Ada saying "I heard about Ada, this supposedly highly safe
> > language, but it doesn't even catch an overflow, though the manual
claims
> > it does."?  vs How many times have people new to Ada posted messages
> > asking about some obscure compiler bug they've stumbled across.
>
> vs How many times "my number-crunching program is horribly slow, in
> fortran it was lightning fast"?
>
> I /believe/ this has happened maybe once or twice in the last lustrum,
> for sure not enough to justify not having -gnato by default.

I don't think (at least on the Intel hardware) that -gnato has much to do
with the speed of floating point operations. They're much more dependent on
the cost of range checks, the rules that prevent rearrangements if
exceptions can be raised, and the Ada accuracy rules. All of which can be
worked around, but that requires more effort than simply changing some flag
on the command line.

Moreover, the code that is speed-critical is always a small part of any
program. It is bad practice to turn off checks everywhere simply so that a
small piece of code will run faster. It's simply premature optimization.

Now, I realize that some people run benchmarks without any tuning, and use
that to claim that some implementation of some language is "slow". (Or
worse, make the claim that the entire language is "slow", forgetting that
implementations can vary widely.) We could combat that by turning off all
checks by default and by letting optimizers rearrange code in any way that
they like and so on. But the result would have none of the values of Ada. Is
that really the only way to sell Ada?

The important thing is that tuned Ada code can be as fast as tuned C code
(or tuned Fortran code), not whatever happens by default. People usually are
comparing raw Ada code to tuned C and Fortran code anyway -- what do you
*think* is going to happen?

If the only way to sell Ada is to make it more like C, then we've already
lost. Customers sold Ada that way won't gain any of the benefits of using
Ada, and are likely to end up thinking they were sold something that is more
hype that results. That's not going to help Ada in the long run (or even the
medium run), although it might help someone's bottom line for a while.

Thus, I conclude if omitting language-defined checks is that important to
selling an Ada compiler, there is no hope for Ada. We all should find
something more useful to do.

                                       Randy.

Re: Bug in Ada (SuSe 10.2) ?

[Gautier]

> Reinert Korsnes wrote:
>> I looked for a general "safe mode" under gnat. Did not find. Is there any ?

Ludovic Brenta wrote:
> gnatmake -gnatafo -gnatVa -fstack-check

I'd suggest adding also that option:

-gnatecdebug.pra

File debug.pra contains:
pragma Initialize_Scalars;

It initializes variables, when possible, with out-of-range or otherwise invalid 
values -> makes the error detection even better.

______________________________________________________________
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Bug in Ada (SuSe 10.2) ?

[Stephen Leake]

Adam Beneschan <adam@irvine.com> writes:

> Well, if you're going to be pedantic, then even with those flags GNAT
> is not an Ada compiler, because I can give it Ada programs that it
> doesn't compile (not to mention non-Ada programs that it doesn't
> reject, and Ada programs that run incorrectly after GNAT compiles
> them).  And the same is doubtless true of any other compiler.  GNAT
> will not be an Ada compiler until they finally get the Last Bug out,
> which isn't going to happen because by the time they finally get Ada
> 2005 to be working 100% correctly, the Ada language will be up to Ada
> 2067 or so.
>
> So maybe it's ridiculously pedantic to claim it's not Ada for that
> reason---but probably no moreso than for your reason.

I agree with your basic point; all compilers have bugs.

But compare the number of times a post on this newsgroup is answered
by "you need -gnato" as opposed to "gnat has a bug"; that makes it
clear that this default was a mistake in the long term, even if there
were good short-term reasons for it at the time.

But it's not going to change now.

-- 
-- Stephe

Re: Bug in Ada (SuSe 10.2) ?

[billjones6789]

On Feb 21, 2:32 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> We're talking about language-defined checks. There are no language-defined
> checks for dangling pointers!

Huh?
In Ada83 there was no provision for pointers into the stack, because
of the well-known danger of leaving a dangling pointer when the
subprogram exited.  Ada95 considered it necessary to allow pointers
into the stack, in part because users were doing it anyway (using
unsafe techniques like 'address and Unchecked_Conversion) to avoid
the well-known dangers of using heap allocation.

To eliminate the danger of dangling pointers into the stack, Ada95
introduced the concept of Accessibility_Check, which, like
Overflow_Check, can be controlled using pragma Suppress/Unsuppress,
and possibly compiler switches.

Of course, the danger is only eliminated when this language-defined
check is fully implemented in standard mode.

Re: Bug in Ada (SuSe 10.2) ?

[Adam Beneschan]

On Feb 20, 4:55 pm, tmo...@acm.org wrote:
> > > The simple explanation is that GNAT, by default, is not an Ada compiler.
> > will not be an Ada compiler until they finally get the Last Bug out,
>
>    Technically it's an Ada compiler if and only if it passes the
> validation tests, and the default Gnat therefore isn't an Ada compiler,
> and shouldn't be advertised as one.  If it its bugs were sufficiently
> obscure they are not detected by the validation tests, then it would be an
> Ada compiler.

Unfortunately, I don't think "not detected by validation tests"
implies "obscure".  I have seen *many* cases where someone allegedly
writes a library or tool in Ada and makes the source publicly
available, but it turns out the program really isn't written in Ada at
all, because it contains constructs that the Ada standard prohibits,
but were not caught because of GNAT bugs that let them slip through.
So then code that the authors claim is Ada, but really isn't, gets
posted on the Internet, and then someone else tries to compile it with
a different vendor's compiler and that compiler properly rejects it.
I don't know what happens after that, or how many users may have tried
downloading quasi-Ada code, tried to compile it with some compiler,
run into problems, and given up.  But a bug that affects real code
like this, particularly real code that is intended for many users to
use, probably shouldn't be considered "obscure".

>    More importantly, how many times have we seen postings here from people
> new to Ada saying "I heard about Ada, this supposedly highly safe
> language, but it doesn't even catch an overflow, though the manual claims
> it does."?  vs How many times have people new to Ada posted messages
> asking about some obscure compiler bug they've stumbled across.

OK, this claim has been made (or implied) several times now---an
implication that the -gnato issue causes a lot more complaints than
supposedly obscure compiler bugs.  After thinking about this, I'm not
convinced that this is true.  Not that I have the time to do a study.
But it seems to me that there have been several threads in recent
months where someone couldn't figure out why their program didn't work
and it the answer seemed to be that it should have worked but the
compiler muffed it.  (The compiler isn't always GNAT, and sometimes
it's not identified.)  If I had to guess, I'd say this has come up
once every couple months at least, in recent months.  I don't recall
questions about integer overflow coming up significantly more than
that.  But I could have just missed them.  This just my vague
impression and isn't based on a methodical study.

After this discussion, I'm convinced that GNAT got the -gnato default
wrong (although maybe it's right for certain target processors) and I
can see the practical problems it causes.  (I'm less convinced about
stack checking.)   But it still seems a bit pointless, and/or overly
pedantic, to claim that this makes GNAT "not an Ada compiler" when
those flags aren't used.  Of course, it was probably pointless for me
to even argue about that in the first place.  But what would Usenet be
without pointless arguments?

                                    -- Adam

Re: Bug in Ada (SuSe 10.2) ?

[Georg Bauhaus]

On Fri, 2008-02-22 at 08:10 -0800, billjones6789@yahoo.com wrote:

> Of course, the danger is only eliminated when this language-defined
> check is fully implemented in standard mode.

Here is another dangling pointer. The program is
giving me results varying with compiler/OS. I didn't see
how accessiblity checks could help in this case, but
then maybe this is a different issue?

with Ada.Unchecked_Deallocation;
with Ada.Text_IO;

procedure News3 is
   use Ada;

   type Int_Ptr is access Integer;
   Pointer: Int_Ptr;
   Dangling_Pointer: Int_Ptr;

   procedure Copy(Source: in out Int_Ptr; Target: out Int_Ptr) is
      procedure Oops is new Unchecked_Deallocation
        (Integer, Int_Ptr);
   begin
      Target := Source;
      Oops(Source);
   end Copy;

begin
   Pointer := new Integer'(42);
   Copy(Pointer, Dangling_Pointer);

   Text_IO.Put_Line(Integer'image(Dangling_Pointer.all));
end News3;

Re: Bug in Ada (SuSe 10.2) ?

[Randy Brukardt]

<billjones6789@yahoo.com> wrote in message
news:69019a65-736e-48ee-bd9f-4c29cd7fc88f@72g2000hsu.googlegroups.com...
>On Feb 21, 2:32 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>> We're talking about language-defined checks. There are no
language-defined
>> checks for dangling pointers!
>
>Huh?
>In Ada83 there was no provision for pointers into the stack, because
>of the well-known danger of leaving a dangling pointer when the
>subprogram exited.  Ada95 considered it necessary to allow pointers
>into the stack, in part because users were doing it anyway (using
>unsafe techniques like 'address and Unchecked_Conversion) to avoid
>the well-known dangers of using heap allocation.
>
>To eliminate the danger of dangling pointers into the stack, Ada95
>introduced the concept of Accessibility_Check, which, like
>Overflow_Check, can be controlled using pragma Suppress/Unsuppress,
>and possibly compiler switches.

These aren't "dangling pointer" checks (which would occur on the
dereference). If you wanted to talk about them informally, I'd call them
"lifetime" checks, but it is best to call them by their real name (which you
finally did above). I thought you were talking about something completely
different.

Anyway, accessibility checks contain both a static and dynamic part, and it
is fairly difficult to write an interesting program that passes the static
check and fails the dynamic check. The most likely way to do so in practice
is to use an anonymous access parameter -- and this is the best reason for
avoiding such parameters, as you have the possibility of failure just
because you are making a call from a nested location.

And, yes, I suppose you could suppress the check. You could also play
Russian Roulette. Or, most likely, you'll have used 'Unchecked_Access to
avoid that silly check in the first place (it prevents lots of things that
are safe to do). But you still would have been better off avoiding the
unchecked access in the first place, because eliminating the check would not
eliminate most of the overhead (that overhead can only be eliminated if the
subprogram body and all calls are compiled such that it is certain that the
check is suppressed and cannot be turned back on -- which means that any
separate compilation eliminates that possibility).

In any case, there is nothing wrong with having the ability to suppress
language-defined checks via a compiler switch or whatever. But there is
something wrong with having the default operation of a compiler having those
checks suppressed. Yes, pendantically this is OK, but it means that new
users don't actually use the Ada standard mode.

                                           Randy.



Of course, the danger is only eliminated when this language-defined
check is fully implemented in standard mode.

Re: Bug in Ada (SuSe 10.2) ?

[Vadim Godunko]

On 22 фев, 22:21, Georg Bauhaus <rm.plus-bug.t...@maps.futureapps.de>
wrote:
> On Fri, 2008-02-22 at 08:10 -0800, billjones6...@yahoo.com wrote:
> > Of course, the danger is only eliminated when this language-defined
> > check is fully implemented in standard mode.
>
> Here is another dangling pointer. The program is
> giving me results varying with compiler/OS. I didn't see
> how accessiblity checks could help in this case, but
> then maybe this is a different issue?
>
> with Ada.Unchecked_Deallocation;
> with Ada.Text_IO;
>
> procedure News3 is
>    use Ada;
>
>    type Int_Ptr is access Integer;
>    Pointer: Int_Ptr;
>    Dangling_Pointer: Int_Ptr;
>
>    procedure Copy(Source: in out Int_Ptr; Target: out Int_Ptr) is
>       procedure Oops is new Unchecked_Deallocation
>         (Integer, Int_Ptr);
>    begin
>       Target := Source;
>       Oops(Source);
>    end Copy;
>
> begin
>    Pointer := new Integer'(42);
>    Copy(Pointer, Dangling_Pointer);
>
>    Text_IO.Put_Line(Integer'image(Dangling_Pointer.all));
> end News3;

Unchecked_Deallocation never makes program less erroneous. In the
example it is safe to remove instantiation of Unchecked_Deallocation.
Allocated memory will be automatically reclaimed after control flow
leave News3 subprogram, independent does or doesn't it is a main
subprogram.

Re: Bug in Ada (SuSe 10.2) ?

[Robert A Duff]

Vadim Godunko <vgodunko@gmail.com> writes:

> On 22 яПНяПНяПН, 22:21, Georg Bauhaus <rm.plus-bug.t...@maps.futureapps.de>
> wrote:
>> On Fri, 2008-02-22 at 08:10 -0800, billjones6...@yahoo.com wrote:
>> > Of course, the danger is only eliminated when this language-defined
>> > check is fully implemented in standard mode.
>>
>> Here is another dangling pointer. The program is
>> giving me results varying with compiler/OS. I didn't see
>> how accessiblity checks could help in this case, but
>> then maybe this is a different issue?
>>
>> with Ada.Unchecked_Deallocation;
>> with Ada.Text_IO;
>>
>> procedure News3 is
>>    use Ada;
>>
>>    type Int_Ptr is access Integer;
>>    Pointer: Int_Ptr;
>>    Dangling_Pointer: Int_Ptr;
>>
>>    procedure Copy(Source: in out Int_Ptr; Target: out Int_Ptr) is
>>       procedure Oops is new Unchecked_Deallocation
>>         (Integer, Int_Ptr);
>>    begin
>>       Target := Source;
>>       Oops(Source);
>>    end Copy;
>>
>> begin
>>    Pointer := new Integer'(42);
>>    Copy(Pointer, Dangling_Pointer);
>>
>>    Text_IO.Put_Line(Integer'image(Dangling_Pointer.all));
>> end News3;
>
> Unchecked_Deallocation never makes program less erroneous. In the
> example it is safe to remove instantiation of Unchecked_Deallocation.
> Allocated memory will be automatically reclaimed after control flow
> leave News3 subprogram, independent does or doesn't it is a main
> subprogram.

An implementation is allowed to do such reclamation, but most do not,
unless you add a Storage_Size or Storage_Pool clause.

- Bob

Re: Bug in Ada (SuSe 10.2) ?

[billjones6789]

On Feb 22, 11:21 am, Georg Bauhaus <rm.plus-
bug.t...@maps.futureapps.de> wrote:
> On Fri, 2008-02-22 at 08:10 -0800, billjones6...@yahoo.com wrote:
> > Of course, the danger is only eliminated when this language-defined
> > check is fully implemented in standard mode.
>
> Here is another dangling pointer. The program is
> giving me results varying with compiler/OS. I didn't see
> how accessiblity checks could help in this case, but
> then maybe this is a different issue?
>
> with Ada.Unchecked_Deallocation;
> with Ada.Text_IO;
>
> procedure News3 is
>    use Ada;
>
>    type Int_Ptr is access Integer;
>    Pointer: Int_Ptr;
>    Dangling_Pointer: Int_Ptr;
>
>    procedure Copy(Source: in out Int_Ptr; Target: out Int_Ptr) is
>       procedure Oops is new Unchecked_Deallocation
>         (Integer, Int_Ptr);
>    begin
>       Target := Source;
>       Oops(Source);
>    end Copy;
>
> begin
>    Pointer := new Integer'(42);
>    Copy(Pointer, Dangling_Pointer);
>
>    Text_IO.Put_Line(Integer'image(Dangling_Pointer.all));
> end News3;

Yes, this is a different issue, and accessibility checks
unfortunately don't help in this case.  The checks work for
pointers into the stack (objects declared inside subprograms
where 'access is used), not objects allocated on the heap
(where allocators (new) are used).

There are various methods available to detect such errors,
such as using the valgrind tool or special debug storage pools.

Re: Bug in Ada (SuSe 10.2) ?

[billjones6789]

On Feb 22, 11:52 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> These aren't "dangling pointer" checks (which would occur on the
> dereference). If you wanted to talk about them informally, I'd call them
> "lifetime" checks, but it is best to call them by their real name (which you
> finally did above). I thought you were talking about something completely
> different.

Sorry to confuse you.  Maybe my English is not so good.
I was referring to this language-defined check by its high-level
purpose
rather than its low-level implementation model, the same way it is
introduced in RM 3.10.2 paragraph 1, "The accessibility rules prevent
dangling references ...".

> Anyway, accessibility checks contain both a static and dynamic part, and it
> is fairly difficult to write an interesting program that passes the static
> check and fails the dynamic check.

I provided what I thought to be a rather simple example program that
demonstrated the dynamic case.  Do you mean to say that this example
is
fairly difficult to use in an interesting program?  It did include
an
access discriminant, which may be confusing, but that can be easily
removed, as follows:

with Ada.Text_IO;
procedure Dangling_Pointer2 is
   type Int_Access is access all integer;

   Save : Int_Access;

   type AirSpeed is record
      Altitude : aliased integer := 9;
   end record;

   function WoW (Slats: access AirSpeed) return Int_Access is
   begin
      return Slats.Altitude'Access;
   end WoW;

   procedure Calculate is
      Heading : aliased AirSpeed;
   begin
      Save := WoW (Heading'access);
      Ada.Text_IO.Put_Line (integer'image(Save.all));
   end Calculate;

   procedure Mess_with_stack is
      Dummy: array(1..10) of integer := (others => 17);
   begin
      null;
   end Mess_with_stack;

begin
   Calculate;
   Mess_with_stack;
   Ada.Text_IO.Put_Line (integer'image(Save.all));
end Dangling_Pointer2;

Re: Bug in Ada (SuSe 10.2) ?

[Randy Brukardt]

<billjones6789@yahoo.com> wrote in message
news:d8a465d3-9eae-480b-954f-93236e3a6203@s19g2000prg.googlegroups.com...
On Feb 22, 11:52 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>> These aren't "dangling pointer" checks (which would occur on the
>> dereference). If you wanted to talk about them informally, I'd call them
>> "lifetime" checks, but it is best to call them by their real name (which
you
>> finally did above). I thought you were talking about something completely
>> different.

>Sorry to confuse you.  Maybe my English is not so good.
>I was referring to this language-defined check by its high-level purpose
>rather than its low-level implementation model, the same way it is
>introduced in RM 3.10.2 paragraph 1, "The accessibility rules prevent
>dangling references ...".

I spend so much time in the language-lawyer cave (which requires only formal
terminology) that I can get confused by informal terminology -- especially
that which is not used in the standard. (Yes, I realize you found a mention
of it in a non-normative introduction paragraph, but of course I hardly ever
read those...)

>> Anyway, accessibility checks contain both a static and dynamic part, and
it
>> is fairly difficult to write an interesting program that passes the
static
>> check and fails the dynamic check.

>I provided what I thought to be a rather simple example program that
>demonstrated the dynamic case.  Do you mean to say that this example is
>fairly difficult to use in an interesting program?

I've completely forgotten your original point (or mine, for that matter), so
I'm probably babbling at this point.

You are using anonymous access parameters to achieve the effect. You are
quite correct that this is easy to do. That is in fact the problem: it is
easy to get a Program_Error from passing the "wrong" thing to a subprogram
that has an anonymous access parameter. Moreover, there is no way to
indicate in the specification what is required. Contrast this to parameters
that will be used as array indexes -- the specification ought to include the
appropriate range, in which case any check will take place at the call site
(and the error will be immediately obvious).

On top of that, the use of access parameters (rather than "in" or "in out")
clutters up the call site: both with a 'access and with "aliased"
declarations. Plus, there is a substantial runtime overhead for them
compared to named access types (where the checks are mainly static).

Thus, I believe that they should be avoided if at all possible. (I admit
that there are a few cases where they can't be avoided.) Indeed, a good ADT
should not contain the keyword "access" anywhere in the visible part - the
memory management of the top-level objects should be left to the client.

Net-net I tend to forget about the accessibility checks on anonymous access
parameters, because if you encounter them you probably are doing something
bad (using anonymous access parameters). Of course, all of this is personal
stylistic preferences; it is legal within the language.

Anyway, I'm pretty sure this is getting wildly off-topic.

                                    Randy.

Re: Bug in Ada (SuSe 10.2) ?

[billjones6789]

On Feb 25, 4:32 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> I spend so much time in the language-lawyer cave (which requires only formal
> terminology) that I can get confused by informal terminology -- especially
> that which is not used in the standard. (Yes, I realize you found a mention
> of it in a non-normative introduction paragraph, but of course I hardly ever
> read those...)
> ...
> Net-net I tend to forget about the accessibility checks on anonymous access
> parameters, because if you encounter them you probably are doing something
> bad (using anonymous access parameters).

If you are suggesting that the prevention of dangling pointers (into
the stack)
is simply non-normative flowery language intended to be ignored or
forgotten,
then I disagree.  I think it is a fundamental language invariant that
users
should be able to rely on to prevent the worst kind of programming
errors
(scribbling on arbitrary memory).

Paragraph 3 of 3.10.2, which _is_ normative, repeats the invariant:
"The accessibility rules, which prevent dangling references ...".
And the Ada 95 Rationale repeats it as well in Section 3.7, paragraph
3,
which says: "An additional accessibility check is performed to ensure
that the lifefime of the designated subprogram or object will not end
before that of the access type, eliminating the possibility of
dangling
references."

> You are using anonymous access parameters to achieve the effect. You are
> quite correct that this is easy to do. That is in fact the problem: it is
> easy to get a Program_Error from passing the "wrong" thing to a subprogram
> that has an anonymous access parameter.

You are completely missing the point.  The simple examples provided
show
that it is _not_ so easy to get a Program_Error where one is expected.

> Anyway, I'm pretty sure this is getting wildly off-topic.

To bring it back on topic, an unsuspecting Ada programmer will be
quite
surprised to see overflow checks and stack checks not performed by
default
in some cases, and will be equally surprised to see accessibility
checks
not performed by default in some cases.  For overflow and stack
checks,
there is a rather simple solution involving specifying default flags
in
the project file.  But for accessibility checks, I do not know of any
similar solution.

Re: Bug in Ada (SuSe 10.2) ?

[Randy Brukardt]

<billjones6789@yahoo.com> wrote in message
news:48a0a0c4-7b79-42dc-b541-7a68693bdd4c@e41g2000hsc.googlegroups.com...
> On Feb 25, 4:32 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> > I spend so much time in the language-lawyer cave (which requires only
formal
> > terminology) that I can get confused by informal terminology -- 
especially
> > that which is not used in the standard. (Yes, I realize you found a
mention
> > of it in a non-normative introduction paragraph, but of course I hardly
ever
> > read those...)
> > ...
> > Net-net I tend to forget about the accessibility checks on anonymous
access
> > parameters, because if you encounter them you probably are doing
something
> > bad (using anonymous access parameters).
>
> If you are suggesting that the prevention of dangling pointers (into the
stack)
> is simply non-normative flowery language intended to be ignored or
forgotten,
> then I disagree.  I think it is a fundamental language invariant that
users
> should be able to rely on to prevent the worst kind of programming errors
> (scribbling on arbitrary memory).

Not at all. I'm saying that for the dynamic (only) checks, the "cure" is as
bad as the "disease". The static checks that you get with named access types
don't have the problem with the "cure" being a problem. OTOH, in practice, I
find that I have to turn-off all of those checking 99% of the time I use
'Access. (OT3H, I don't use 'Access or access types themselves that much,
and most of the access types I do use are heap-allocated or "safe pointers"
by virtue of being managed by controlled types.)

...
> Paragraph 3 of 3.10.2, which _is_ normative, repeats the invariant:
> "The accessibility rules, which prevent dangling references ...".
> And the Ada 95 Rationale repeats it as well in Section 3.7, paragraph 3,
> which says: "An additional accessibility check is performed to ensure
> that the lifefime of the designated subprogram or object will not end
> before that of the access type, eliminating the possibility of
> dangling references."

The Rationale is never normative, so that's irrelevant. 3.10.2(3) is marked
in the AARM as a redundant introductory paragraph, meaning that the authors
of the RM considered it non-normative. (Yes, it is "technically" normative,
but since it is using terms that are undefined in the RM, it doesn't have
any meaning.)

> > You are using anonymous access parameters to achieve the effect. You are
> > quite correct that this is easy to do. That is in fact the problem: it
is
> > easy to get a Program_Error from passing the "wrong" thing to a
subprogram
> > that has an anonymous access parameter.
>
> You are completely missing the point.  The simple examples provided show
> that it is _not_ so easy to get a Program_Error where one is expected.

Surely the program should either be rejected or raise Program_Error. But I'd
have to spend an hour reading the accessibility rules to figure out which of
those is correct answer.

For the record, Janus/Ada rejects your program at compile-time with an
accessibility error (pointing at Slats.Altitude'Access). I think that's
because the component dereference (remember that this is actually
Slats.all.Altitude'Access) drops the "special" accessibility of an anonymous
access parameter, and the normal accessibility will fail (as the parameter
is more nested than Int_Access). I think that is correct, but in order to be
sure, I'd have to spend an hour reading through the accessibility rules (and
you'd have to pay me to do that).

> > Anyway, I'm pretty sure this is getting wildly off-topic.
>
> To bring it back on topic, an unsuspecting Ada programmer will be quite
> surprised to see overflow checks and stack checks not performed by default
> in some cases, and will be equally surprised to see accessibility checks
> not performed by default in some cases.  For overflow and stack checks,
> there is a rather simple solution involving specifying default flags in
> the project file.  But for accessibility checks, I do not know of any
> similar solution.

Not performing accessibility checks is simply a bug. The only thing you need
to worry about there is sending a bug report to your compiler vendor - it's
not a matter of turning them on or off.

                                     Randy.

Re: Bug in Ada (SuSe 10.2) ?

[Robert A Duff]

billjones6789@yahoo.com writes:

> To bring it back on topic, an unsuspecting Ada programmer will be
> quite surprised to see overflow checks and stack checks not performed
> by default in some cases,...

Probably true.  At the time this decision was made, I argued in favor of
having all checks on by default.  But I understand the
counterargument...

Anyway, changing this default at this point is a bad idea.
It would only create more confusion.

>...and will be equally surprised to see
> accessibility checks not performed by default in some cases.

But where did this idea come from?  All run-time accessibility checks
are enabled by default in every Ada compiler I know of, including GNAT.

Maybe I missed it -- did you or somebody else post an example of a
missing accessibility check?  If so, it must be a compiler bug,
rather than intended default behavior.

>...For
> overflow and stack checks, there is a rather simple solution involving
> specifying default flags in the project file.  But for accessibility
> checks, I do not know of any similar solution.

As far as I know, there's no need to use flags to turn on accessibility
checks -- they're on by default.  You can turn them off with flags
and/or pragmas.

- Bob

Re: Bug in Ada (SuSe 10.2) ?

[billjones6789]

On Feb 26, 5:05 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> Maybe I missed it -- did you or somebody else post an example of a
> missing accessibility check?  

Yes, here's another copy.  Randy reports a compile-time
error message, and Bob Klungle reports that the program
runs without raising program_error.

with Ada.Text_IO;
procedure Dangling_Pointer2 is
   type Int_Access is access all integer;

   Save : Int_Access;

   type AirSpeed is record
      Altitude : aliased integer := 9;
   end record;

   function WoW (Slats: access AirSpeed) return Int_Access is
   begin
      return Slats.Altitude'Access;
   end WoW;

   procedure Calculate is
      Heading : aliased AirSpeed;
   begin
      Save := WoW (Heading'access);
      Ada.Text_IO.Put_Line (integer'image(Save.all));
   end Calculate;

   procedure Mess_with_stack is
      Dummy: array(1..10) of integer := (others => 17);
   begin
      null;
   end Mess_with_stack;

begin
   Calculate;
   Mess_with_stack;
   Ada.Text_IO.Put_Line (integer'image(Save.all));
end Dangling_Pointer2;

Re: Bug in Ada (SuSe 10.2) ?

[Robert A Duff]

billjones6789@yahoo.com writes:

> On Feb 26, 5:05�pm, Robert A Duff <bobd...@shell01.TheWorld.com>
> wrote:
>> Maybe I missed it -- did you or somebody else post an example of a
>> missing accessibility check? �
>
> Yes, here's another copy.  Randy reports a compile-time
> error message, and Bob Klungle reports that the program
> runs without raising program_error.

Ah, thanks for reposting that.

Unless I'm missing something, both compiler behaviors are bugs,
and should be reported.  I would expect a run-time error in WoW,
and there's no compiler switch that's supposed to turn this
check on -- it's supposed to be on by default.

> with Ada.Text_IO;
> procedure Dangling_Pointer2 is
>    type Int_Access is access all integer;
>
>    Save : Int_Access;
>
>    type AirSpeed is record
>       Altitude : aliased integer := 9;
>    end record;
>
>    function WoW (Slats: access AirSpeed) return Int_Access is
>    begin
>       return Slats.Altitude'Access;
>    end WoW;
>
>    procedure Calculate is
>       Heading : aliased AirSpeed;
>    begin
>       Save := WoW (Heading'access);
>       Ada.Text_IO.Put_Line (integer'image(Save.all));
>    end Calculate;
>
>    procedure Mess_with_stack is
>       Dummy: array(1..10) of integer := (others => 17);
>    begin
>       null;
>    end Mess_with_stack;
>
> begin
>    Calculate;
>    Mess_with_stack;
>    Ada.Text_IO.Put_Line (integer'image(Save.all));
> end Dangling_Pointer2;

- Bob

Re: Bug in Ada (SuSe 10.2) ?

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wcc7igq2ssj.fsf@shell01.TheWorld.com...
> billjones6789@yahoo.com writes:
...
> > Yes, here's another copy.  Randy reports a compile-time
> > error message, and Bob Klungle reports that the program
> > runs without raising program_error.
>
> Ah, thanks for reposting that.
>
> Unless I'm missing something, both compiler behaviors are bugs,
> and should be reported.  I would expect a run-time error in WoW,
> and there's no compiler switch that's supposed to turn this
> check on -- it's supposed to be on by default.

Why do you think a compile-time message is a bug? I've convinced myself that
it is correct. Look at the body of WoW closely:

    function WoW (Slats: access AirSpeed) return Int_Access is
    begin
         return Slats.Altitude'Access;
    end WoW;

Since Slats is an access value, this is really a dereference. That is, the
return statement really is:

         return Slats.all.Altitude'Access;

And you lose the special (dynamic) accessibility with the dereference. Thus,
you get a static check (which fails in this case).

                                       Randy.






> > with Ada.Text_IO;
> > procedure Dangling_Pointer2 is
> >    type Int_Access is access all integer;
> >
> >    Save : Int_Access;
> >
> >    type AirSpeed is record
> >       Altitude : aliased integer := 9;
> >    end record;
> >
> >    function WoW (Slats: access AirSpeed) return Int_Access is
> >    begin
> >       return Slats.Altitude'Access;
> >    end WoW;
> >
> >    procedure Calculate is
> >       Heading : aliased AirSpeed;
> >    begin
> >       Save := WoW (Heading'access);
> >       Ada.Text_IO.Put_Line (integer'image(Save.all));
> >    end Calculate;
> >
> >    procedure Mess_with_stack is
> >       Dummy: array(1..10) of integer := (others => 17);
> >    begin
> >       null;
> >    end Mess_with_stack;
> >
> > begin
> >    Calculate;
> >    Mess_with_stack;
> >    Ada.Text_IO.Put_Line (integer'image(Save.all));
> > end Dangling_Pointer2;
>
> - Bob

Re: Bug in Ada (SuSe 10.2) ?

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Why do you think a compile-time message is a bug? I've convinced myself that
> it is correct. Look at the body of WoW closely:
>
>     function WoW (Slats: access AirSpeed) return Int_Access is
>     begin
>          return Slats.Altitude'Access;
>     end WoW;
>
> Since Slats is an access value, this is really a dereference. That is, the
> return statement really is:
>
>          return Slats.all.Altitude'Access;
>
> And you lose the special (dynamic) accessibility with the dereference. Thus,
> you get a static check (which fails in this case).

Hmm.  You may be right.  I'd have to reread the accessibility rules
carefully to be sure, which I'm too lazy to do right now.  ;-)

Certainly the GNAT behavior (no error) is wrong.
It won't get fixed unless somebody reports it.

- Bob

Re: Bug in Ada (SuSe 10.2) ?

[Colin Paul Gloster]

On Thu, 21 Feb 2008, Jeffrey R. Carter wrote:

|--------------------------------------------------------------------------------|
|"Jeffrey R. Carter wrote:                                                       |
|>                                                                               |
|> I think there's quite a bit of difference between having (almost) all programs|
|> deliberately fail to implement the Ada semantics, and having an unintentional |
|> error in a compiler. The latter is trying to implement Ada; the former isn't. |
|> With its default options, GNAT is much more like the former than the latter.  |
|                                                                                |
|More to the point, perhaps, is that it's interesting to see a posting here about|
|the latter, but the 1_000th posting asking why GNAT doesn't catch integer       |
|overflow isn't."                                                                |
|--------------------------------------------------------------------------------|

So which Ada compiler(s) for Linux does Singo Solution use?

Colin Paul Gloster, unemployed job applicant

Re: Bug in Ada (SuSe 10.2) ?

[Adam Beneschan]

On Feb 27, 4:30 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:

> Why do you think a compile-time message is a bug? I've convinced myself that
> it is correct. Look at the body of WoW closely:
>
>     function WoW (Slats: access AirSpeed) return Int_Access is
>     begin
>          return Slats.Altitude'Access;
>     end WoW;
>
> Since Slats is an access value, this is really a dereference. That is, the
> return statement really is:
>
>          return Slats.all.Altitude'Access;
>
> And you lose the special (dynamic) accessibility with the dereference. Thus,
> you get a static check (which fails in this case).

I wasn't paying much attention to this thread; but I've had an
occasion to take a second look at this, and this doesn't seem right.
3.10.2(15) says that the accessibility level of a view of a
dereference is the same as the accessibility level of that of the
access type, which in this case is the anonymous access type of the
access parameter.  And 3.10.2(19) says that the "statically deeper"
relationship doesn't apply to the accessibility level of the anonymous
type of the access parameter; I would think 3.10.2(19) would apply
equally to the dereference (Slats.all) as it does to the parameter
(Slats), since 3.10.2(15) says their accessibility levels are the
same.  In other words, I don't see from the RM how a dereference
causes you to lose the dynamic accessibility check.

Now I know that I don't get 3.10.2 right all the time---I've
embarrassed myself more than once on Ada-Comment by misinterpreting
this section.  And sometimes I just miss rules.  But if I'm wrong, and
I haven't missed a rule, then this is disturbing, because it means
that the legality of a certain fairly simple construct can't be
determined by reading the RM---it requires some subtle interpretation
that is accessible (no pun intended) only to a select few.

In any case, I don't see any reason why the construct in the above
example shouldn't be legal (with a dynamic check); the functionality
seems useful and not at all dangerous.

                                   -- Adam