Selective suppression of warnings --- gnat on GNU/Linux

Selective suppression of warnings --- gnat on GNU/Linux

[Michael Mounteney]

Hello, I am trying to build an application of which some of the source
is automatically translated from Pascal, on the fly.  The problem is
that the automatically-translated source is causing a lot of spurious
warnings about declarations not being used.  This is because the
Pascal code has many instances of:

     type
          somerange = 1..10;
          somestruct = record ... end;

which is translated into Ada as

     type somerange is new integer range 1 .. 10;

     type somestruct is record ... end record;

but the problem is that any operators such as + and = are not visible
in other units.  The solution to that is to rename the operators in
the client units, thus:

     with stage3;    -- contains definitions of somerange, somestruct
etc.

     package body myusage is

          function "=" (L, R : in stage3.somestruct) return Boolean
renames stage3."=";
          function "+" (L, R : in stage3.somerange) return
stage3.somerange renames stage3."+";
          ..........
     end myusage;

without those renamings, any usage of = and + within the body of
myusage are flagged as errors owing to lack of visibility/
qualification.

The translator is a rather crude line-by-line affair written in
Haskell that only performs partial analysis of the source, and
certainly isn't up to identifying the arguments to operators within
expressions.  Thus, it produces the renaming clauses if it encounters
the type name is the source;  e.g., if it sees somerange, it outputs
all the renamings for somerange.  However, the renamings usually are
not required, so gnat warns about them.  Normally, this would not be a
problem;  one would simply remove the unneeded declaration from the
source.  I did try putting the declarations into another package and
then "with" and "use" that, but then the warning changes to "no
declarations used from the package".

I really really really don't like "use" anyway and prefer always to
qualify imported names.

What I'd like is a pragma that switches-off and switches-on the
warning over the specific range of lines containing the renamings, but
no such seems to be available.  I don't want to switch off the warning
from the command line as that will suppress valid warnings.

Is there another way ?  Is there some rearrangement of the source that
WOULD suppress the unwanted warnings.

So the question:

Re: Selective suppression of warnings --- gnat on GNU/Linux

[Ludovic Brenta]

On Dec 30, 4:13 am, Michael Mounteney <gat...@landcroft.co.uk> wrote:
> Hello, I am trying to build an application of which some of the source
> is automatically translated from Pascal, on the fly.  The problem is
> that the automatically-translated source is causing a lot of spurious
> warnings about declarations not being used.  This is because the
> Pascal code has many instances of:
>
>      type
>           somerange = 1..10;
>           somestruct = record ... end;
>
> which is translated into Ada as
>
>      type somerange is new integer range 1 .. 10;
>
>      type somestruct is record ... end record;
>
> but the problem is that any operators such as + and = are not visible
> in other units.  The solution to that is to rename the operators in
> the client units, thus:
>
>      with stage3;    -- contains definitions of somerange, somestruct
> etc.
>
>      package body myusage is
>
>           function "=" (L, R : in stage3.somestruct) return Boolean
> renames stage3."=";
>           function "+" (L, R : in stage3.somerange) return
> stage3.somerange renames stage3."+";
>           ..........
>      end myusage;
>
> without those renamings, any usage of = and + within the body of
> myusage are flagged as errors owing to lack of visibility/
> qualification.
>
> The translator is a rather crude line-by-line affair written in
> Haskell that only performs partial analysis of the source, and
> certainly isn't up to identifying the arguments to operators within
> expressions.  Thus, it produces the renaming clauses if it encounters
> the type name is the source;  e.g., if it sees somerange, it outputs
> all the renamings for somerange.  However, the renamings usually are
> not required, so gnat warns about them.  Normally, this would not be a
> problem;  one would simply remove the unneeded declaration from the
> source.  I did try putting the declarations into another package and
> then "with" and "use" that, but then the warning changes to "no
> declarations used from the package".
>
> I really really really don't like "use" anyway and prefer always to
> qualify imported names.
>
> What I'd like is a pragma that switches-off and switches-on the
> warning over the specific range of lines containing the renamings, but
> no such seems to be available.  I don't want to switch off the warning
> from the command line as that will suppress valid warnings.
>
> Is there another way ?  Is there some rearrangement of the source that
> WOULD suppress the unwanted warnings.
>
> So the question:

Have you tried replacing the renaming declarations with "use type
somerange;" ? One such clause applies to all operators. You will get
fewer warnings, as if a single operator is used then the "use type"
clause does not cause a warning.

--
Ludovic Brenta.

Re: Selective suppression of warnings --- gnat on GNU/Linux

[(see below)]

On 30/12/2008 03:13, in article
7a6baa71-80e8-4f3a-80b6-34935bda2fc0@r10g2000prf.googlegroups.com, "Michael
Mounteney" <gate02@landcroft.co.uk> wrote:

> Hello, I am trying to build an application of which some of the source
> is automatically translated from Pascal, on the fly.  The problem is
> that the automatically-translated source is causing a lot of spurious
> warnings about declarations not being used.  This is because the
> Pascal code has many instances of:
> 
>      type
>           somerange = 1..10;
>           somestruct = record ... end;
> 
> which is translated into Ada as
> 
>      type somerange is new integer range 1 .. 10;
> 
>      type somestruct is record ... end record;
> 
> but the problem is that any operators such as + and = are not visible
> in other units.  The solution to that is to rename the operators in
> the client units, thus:

No, the problem is that the Pascal subrange type declarations have been
wrongly translated. The Pascal declaration:

  type  somerange = 1..10;

Means, in Ada:

   SUBtype  somerange is Integer range 1..10;

Make this change and the Ada type compatibility problems will magically
vanish.
-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Selective suppression of warnings --- gnat on GNU/Linux

[Georg Bauhaus]

(see below) wrote:

> No, the problem is that the Pascal subrange type declarations have been
> wrongly translated. The Pascal declaration:
> 
>   type  somerange = 1..10;
> 
> Means, in Ada:
> 
>    SUBtype  somerange is Integer range 1..10;
> 
> Make this change and the Ada type compatibility problems will magically
> vanish.

I can see this is formally true, but wouldn't you loose
the valuable distinction that comes from different numeric
types?

Re: Selective suppression of warnings --- gnat on GNU/Linux

[(see below)]

On 30/12/2008 11:37, in article
495a0802$0$32677$9b4e6d93@newsspool2.arcor-online.net, "Georg Bauhaus"
<rm.tsoh.plus-bug.bauhaus@maps.futureapps.de> wrote:

> (see below) wrote:
> 
>> No, the problem is that the Pascal subrange type declarations have been
>> wrongly translated. The Pascal declaration:
>> 
>>   type  somerange = 1..10;
>> 
>> Means, in Ada:
>> 
>>    SUBtype  somerange is Integer range 1..10;
>> 
>> Make this change and the Ada type compatibility problems will magically
>> vanish.
> 
> I can see this is formally true, but wouldn't you loose
> the valuable distinction that comes from different numeric
> types?

The point is that in Pascal they are NOT different types, so if one wants to
mirror the semantics of the Pascal program - which is presumably the reason
for translating it - one must do as I say.

Even writing afresh in Ada, it is very unlikely indeed that one would want
EVERY subrange to be a separate type.

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Pascal ranges (was: Selective suppression of warnings --- gnat on GNU/Linux)

[Georg Bauhaus]

(see below) wrote:

>>>  The Pascal declaration:
>>>
>>>   type  somerange = 1..10;
>>>
>>> Means, in Ada:
>>>
>>>    SUBtype  somerange is Integer range 1..10;

> The point is that in Pascal they are NOT different types, so if one wants to
> mirror the semantics of the Pascal program - which is presumably the reason
> for translating it - one must do as I say.

Maybe, then, type mapping from Pascal ranges to Ada ranges,
selecting either types or subtypes,
will be an interesting switch to add to P2Ada?  I now get

-- Translated by (New) P2Ada v. 15-Nov-2006
-- ...
-- formatted by iccfmt_nt.exe

package stage3 is

   type somerange is range 1..10;

   type somestruct is
      record
         null;
      end record;

   function test(a : somerange) return integer;

end stage3;


for the Turbo Pascal input file

unit stage3;

interface

   type
      somerange = 1..10;
      somestruct = record  end;

   function test(a: somerange) : integer;

implementation
 ...
end.

Bits of history tell that programmers started protests when Modula/Wirth
introduced different, incompatible types such as INTEGER
and CARDINAL, together with type conversions and type cheats (pretty
much the same as instances of Unchecked_Conversion, I guess?)

Because, it seems, the protesters would have to type more characters
and state explicitly the conversions that they had previously just
thought about carefully and then delegated to the Depepartment of
The Obvious.


> Even writing afresh in Ada, it is very unlikely indeed that one would want
> EVERY subrange to be a separate type.

OK, but OTOH, is a program improved when by default
different Pascal ranges are mapped to Ada ranges of distinct
types?  I think, yes, in case one assumes Ada requires stating
assumptions explicitly by default:
If Pascal's integer ranges are not made for expressing
different types, then maybe Pascal programmers do their best
and carefully mix objects of logically distinct integer types
only when a conversion is logically valid. If a compiler can
help with this in case ranges are made different types by
default, why not?  (I.e., if a subtype constraint is enough
distinction, the type declarations would have to be turned
into subtype declarations by hand, after the automatic
translation has turned Pascal ranges into different Ada
types.)

Re: Pascal ranges (was: Selective suppression of warnings --- gnat on GNU/Linux)

[(see below)]

On 30/12/2008 14:11, in article
495a2c0a$0$30237$9b4e6d93@newsspool1.arcor-online.net, "Georg Bauhaus"
<rm.tsoh.plus-bug.bauhaus@maps.futureapps.de> wrote:

> Maybe, then, type mapping from Pascal ranges to Ada ranges,
> selecting either types or subtypes,
> will be an interesting switch to add to P2Ada?  I now get
> 
> -- Translated by (New) P2Ada v. 15-Nov-2006
> -- ...
> -- formatted by iccfmt_nt.exe
> 
> package stage3 is
> 
>    type somerange is range 1..10;
> ...

Yup. I complained about that to Gautier years ago. 8-)
It seems that the technology he was using did not permit a correct
translation to be made (doing it properly needs too much look-ahead).
 
>> Even writing afresh in Ada, it is very unlikely indeed that one would want
>> EVERY subrange to be a separate type.
> 
> OK, but OTOH, is a program improved when by default
> different Pascal ranges are mapped to Ada ranges of distinct
> types?  I think, yes, in case one assumes Ada requires stating
> assumptions explicitly by default:

Often, yes, it is, but there are cases where one wants to model in Pascal a
similar kind of relationship as exists between Integer, Natural and
Positive, but for a more restricted range. The need for these closely
related subranges is rather smaller in Ada, e.g. thanks to array attributes
such as 'First and 'Last. The Ada equivalents would be subranges of a common
base type, and so inter-convertible as painlessly as in Pascal. If these
subranges were all to be modelled by distinct types, much explicit type
conversion, to no useful effect, would be needed.

> If Pascal's integer ranges are not made for expressing
> different types,  ...

Well they are made for expressing constraints and distinctions. It's just
that Pascal's type system is not strong enough to express the finer
distinctions available in Ada, so Pascal programmers must make do with what
they have been given. That forces them to use related subtypes more than an
Ada programmer would need to (assuming of course, that they don't just use
Integer for everything, as a former colleague of mine insisted on doing).

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Selective suppression of warnings --- gnat on GNU/Linux

[Michael Mounteney]

Thanks very much, Ludovic, that answer was just what I needed !  The
warning count has decreased by about 80%.

Bill:  I take your point but I am trying to preserve semantic
information the conversion.  So I do want the types to be distinct.
The Pascal source has been modified where necessary thus:

     dest := (*ada:typeofdest*)(expr);

which the convertor sees as

     dest := typeofdest(expr);

in order to maintain the distinction of types.

Re: Selective suppression of warnings --- gnat on GNU/Linux

[Robert A Duff]

Michael Mounteney <gate02@landcroft.co.uk> writes:

> What I'd like is a pragma that switches-off and switches-on the
> warning over the specific range of lines containing the renamings, but
> no such seems to be available.  I don't want to switch off the warning
> from the command line as that will suppress valid warnings.

GNAT has a whole bunch of ways to suppress warnings.  Look at the docs.
You can suppress warnings in a range of code.  You can suppress
particular types of warnings.  You can suppress all warnings (in a range
of code, or globally).  Pragmas and command-line options.

As someone said, you might want "use type", which makes operators
directly visible, but nothing else.  Or you might want to use
subtypes of Integer.

Three alternative translations of Pascal's:

    type T = A..B;

have been discussed in this thread:

1.    subtype T is Integer range A..B;
2.    type T is new Integer range A..B;
3.    type T is range A..B;

Option 1 matches Pascal semantics most closely.

2 and 3 both might be better Ada style in some cases, but:

It's hard to tell from the Pascal code whether it's better or worse.
Sometimes 1 is better.  It depends on how many type conversions are
needed, and analyzing that would require a fairly sophisticated
translator, with global analysis of the Pascal program.

Option 3 is questionable, because of overflow semantics for intermediate
results in expressions.  In Pascal, if you say (X+Y)/2, it won't
overflow if X+Y is in Integer, but not in A..B.  Same is True in Ada for
option 2, but not necessarily for option 3.

- Bob

Re: Pascal ranges

[Robert A Duff]

"(see below)" <yaldnif.w@blueyonder.co.uk> writes:

> Often, yes, it is, but there are cases where one wants to model in Pascal a
> similar kind of relationship as exists between Integer, Natural and
> Positive, but for a more restricted range.

I agree.

>.. The need for these closely
> related subranges is rather smaller in Ada, e.g. thanks to array attributes
> such as 'First and 'Last.

I don't understand why you say "need...rather smaller" here.
I often have two subtypes of the same type, one for counting
how many there are (0..N), and one for indexing into an array
of them (1..N).  Like this:

    type Blah_Index is range 1..N;
    subtype Blah_Count is Blah_Index'Base range 0..Blah_Index'Last;

- Bob

Re: Selective suppression of warnings --- gnat on GNU/Linux

[Robert A Duff]

Michael Mounteney <gate02@landcroft.co.uk> writes:

> Thanks very much, Ludovic, that answer was just what I needed !  The
> warning count has decreased by about 80%.
>
> Bill:  I take your point but I am trying to preserve semantic
> information the conversion.  So I do want the types to be distinct.
> The Pascal source has been modified where necessary thus:
>
>      dest := (*ada:typeofdest*)(expr);
>
> which the convertor sees as
>
>      dest := typeofdest(expr);
>
> in order to maintain the distinction of types.

Aha!  So you're not exactly translating Pascal to Ada,
you're translating Pascal with some interesting
annotations (in Pascal comments) to Ada.

I think you might be better off annotating the Pascal
type declarations (which ones should be separate types,
in the Ada sense, versus subtypes), rather than annotating
the individual Pascal expressions with conversion annotations.

- Bob

Re: Pascal ranges

[(see below)]

On 30/12/2008 23:19, in article wccmyed1cae.fsf@shell01.TheWorld.com,
"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote:

>> .. The need for these closely
>> related subranges is rather smaller in Ada, e.g. thanks to array attributes
>> such as 'First and 'Last.
> 
> I don't understand why you say "need...rather smaller" here.
> I often have two subtypes of the same type, one for counting
> how many there are (0..N), and one for indexing into an array
> of them (1..N).  Like this:
> 
>     type Blah_Index is range 1..N;
>     subtype Blah_Count is Blah_Index'Base range 0..Blah_Index'Last;

Because we could write:

 type Blah_Count is range 0..N;
...  array(Blah_Count range 1..Blah_Count'Last) of ...


-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Pascal ranges

[Robert A Duff]

"(see below)" <yaldnif.w@blueyonder.co.uk> writes:

> On 30/12/2008 23:19, in article wccmyed1cae.fsf@shell01.TheWorld.com,
> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote:
>
>>> .. The need for these closely
>>> related subranges is rather smaller in Ada, e.g. thanks to array attributes
>>> such as 'First and 'Last.
>> 
>> I don't understand why you say "need...rather smaller" here.
>> I often have two subtypes of the same type, one for counting
>> how many there are (0..N), and one for indexing into an array
>> of them (1..N).  Like this:
>> 
>>     type Blah_Index is range 1..N;
>>     subtype Blah_Count is Blah_Index'Base range 0..Blah_Index'Last;
>
> Because we could write:
>
>  type Blah_Count is range 0..N;
> ...  array(Blah_Count range 1..Blah_Count'Last) of ...

Yes, we could write that, but more commonly, we might want to write:

 ...  array(Blah_Count range 1..Blah_Count'Last range <>) of ...

which is illegal, so we write:

 ...  array(Blah_Index range <>) of ...

Seems to me, in Ada, one often needs a name for both (the "count" and
the "index").  And we need the index [sub]type anyway, so we can declare
objects of it.  Such as the record component that records the last-used
component of that array (which is inside the record).

- Bob

Re: Pascal ranges

[(see below)]

On 31/12/2008 00:07, in article wcceizp1a3e.fsf@shell01.TheWorld.com,
"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote:

> "(see below)" <yaldnif.w@blueyonder.co.uk> writes:
> 
>> On 30/12/2008 23:19, in article wccmyed1cae.fsf@shell01.TheWorld.com,
>> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote:
>> 
>>>> .. The need for these closely
>>>> related subranges is rather smaller in Ada, e.g. thanks to array attributes
>>>> such as 'First and 'Last.
>>> 
>>> I don't understand why you say "need...rather smaller" here.
>>> I often have two subtypes of the same type, one for counting
>>> how many there are (0..N), and one for indexing into an array
>>> of them (1..N).  Like this:
>>> 
>>>     type Blah_Index is range 1..N;
>>>     subtype Blah_Count is Blah_Index'Base range 0..Blah_Index'Last;
>> 
>> Because we could write:
>> 
>>  type Blah_Count is range 0..N;
>> ...  array(Blah_Count range 1..Blah_Count'Last) of ...
> 
> Yes, we could write that, but more commonly, we might want to write:
> 
>  ...  array(Blah_Count range 1..Blah_Count'Last range <>) of ...
> 
> which is illegal, so we write:
> 
>  ...  array(Blah_Index range <>) of ...
> 
> Seems to me, in Ada, one often needs a name for both (the "count" and
> the "index").  And we need the index [sub]type anyway, so we can declare
> objects of it.  Such as the record component that records the last-used
> component of that array (which is inside the record).

Sure. I said the need was smaller, not non-existent. 8-)

My important point was that converting all Pascal subranges to distinct
types creates a need for pointless type conversions. These might do damage
to the type-safety mindset that is at least comparable with making
everything a subrange of Integer, as Pascal does.

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Selective suppression of warnings --- gnat on GNU/Linux

[Jean-Pierre Rosen]

Robert A Duff a �crit :
> 1.    subtype T is Integer range A..B;
> 2.    type T is new Integer range A..B;
> 3.    type T is range A..B;
> [...] 
> Option 3 is questionable, because of overflow semantics for intermediate
> results in expressions.  In Pascal, if you say (X+Y)/2, it won't
> overflow if X+Y is in Integer, but not in A..B.  Same is True in Ada for
> option 2, but not necessarily for option 3.
Oh no! Option 2 has exactly the same problem, you just hope that by 
forcing your type to have the same number of bits as Integer (a type you 
know nothing about), there will be enough room for your computations...

If you are worried about overflows (and you use only additions), the 
proper declarations are:
type Big_Enough is range A .. 2*B;
subtype T is Big_Enough range A .. B;

Of course, if you compute more than single additions, a real analysis 
has to be done to determine the bounds of Big_Enough.

By all means, please, let's get rid of Integer!

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

Re: Selective suppression of warnings --- gnat on GNU/Linux

[Robert A Duff]

Jean-Pierre Rosen <rosen@adalog.fr> writes:

> Robert A Duff a �crit :
>> 1.    subtype T is Integer range A..B;
>> 2.    type T is new Integer range A..B;
>> 3.    type T is range A..B;
>> [...] Option 3 is questionable, because of overflow semantics for
>> intermediate
>> results in expressions.  In Pascal, if you say (X+Y)/2, it won't
>> overflow if X+Y is in Integer, but not in A..B.  Same is True in Ada for
>> option 2, but not necessarily for option 3.
> Oh no! Option 2 has exactly the same problem, you just hope that by
> forcing your type to have the same number of bits as Integer (a type you
> know nothing about), there will be enough room for your computations...
>
> If you are worried about overflows (and you use only additions), the
> proper declarations are:
> type Big_Enough is range A .. 2*B;
> subtype T is Big_Enough range A .. B;
>
> Of course, if you compute more than single additions, a real analysis
> has to be done to determine the bounds of Big_Enough.

That's all true, if we're just talking about Ada.

But we're talking about translating Pascal into Ada.
I was making the implicit assumption that Pascal's
Integer is the same as Ada's Integer, which is
likely true.

If that's true, then we must presume that the Pascal
programmer already made sure that calculations won't
overflow, so they won't overflow in Ada Integer, either.
Or else there's a bug in the Pascal code,
and we're going to translate that into the same
bug in the Ada code.

If you don't like the above assumption, then I'd say
the correct translation is:

    type Pascal_Integer is range ...;
    subtype T is Pascal_Integer range A..B;

where the rangs of Pascal_Integer is chosen to
match the Pascal compiler -- obviously you have
to know something about the Pascal compiler.

Either way (whether we use Integer or a special
Pascal_Integer), there's no need to analyze the
program for overflow, and do things like the 2*B
you suggest -- that's not the job of a Pascal-to-Ada
translator!

> By all means, please, let's get rid of Integer!

I'm all for it.  ;-)

- Bob

Re: Selective suppression of warnings --- gnat on GNU/Linux

[Jean-Pierre Rosen]

Robert A Duff a �crit :
> If that's true, then we must presume that the Pascal
> programmer already made sure that calculations won't
> overflow 
Sigh... I'm afraid you are over-optimistic here

> Or else there's a bug in the Pascal code,
> and we're going to translate that into the same
> bug in the Ada code.
I agree that the translator can't do any better.

>     type Pascal_Integer is range ...;
>     subtype T is Pascal_Integer range A..B;
> 
> where the rangs of Pascal_Integer is chosen to
> match the Pascal compiler -- obviously you have
> to know something about the Pascal compiler.
This is a good idea, and shows the Pascal legacy for the future maintainer.

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

Re: Selective suppression of warnings --- gnat on GNU/Linux

[(see below)]

On 31/12/2008 09:46, in article 42ffjg.s9b.ln@hunter.axlog.fr, "Jean-Pierre
Rosen" <rosen@adalog.fr> wrote:

> By all means, please, let's get rid of Integer!

And String? ?-)

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Selective suppression of warnings --- gnat on GNU/Linux

[Jerry]

On Dec 29, 8:13 pm, Michael Mounteney <gat...@landcroft.co.uk> wrote:
> Hello, I am trying to build an application of which some of the source
> is automatically translated from Pascal, on the fly.  The problem is
> that the automatically-translated source is causing a lot of spurious
> warnings about declarations not being used.  This is because the
> Pascal code has many instances of:
>
>      type
>           somerange = 1..10;
>           somestruct = record ... end;
>
> which is translated into Ada as
>
>      type somerange is new integer range 1 .. 10;
>
>      type somestruct is record ... end record;
>
> but the problem is that any operators such as + and = are not visible
> in other units.  The solution to that is to rename the operators in
> the client units, thus:
>
>      with stage3;    -- contains definitions of somerange, somestruct
> etc.
>
>      package body myusage is
>
>           function "=" (L, R : in stage3.somestruct) return Boolean
> renames stage3."=";
>           function "+" (L, R : in stage3.somerange) return
> stage3.somerange renames stage3."+";
>           ..........
>      end myusage;
>
> without those renamings, any usage of = and + within the body of
> myusage are flagged as errors owing to lack of visibility/
> qualification.
>
> The translator is a rather crude line-by-line affair written in
> Haskell that only performs partial analysis of the source, and
> certainly isn't up to identifying the arguments to operators within
> expressions.  Thus, it produces the renaming clauses if it encounters
> the type name is the source;  e.g., if it sees somerange, it outputs
> all the renamings for somerange.  However, the renamings usually are
> not required, so gnat warns about them.  Normally, this would not be a
> problem;  one would simply remove the unneeded declaration from the
> source.  I did try putting the declarations into another package and
> then "with" and "use" that, but then the warning changes to "no
> declarations used from the package".
>
> I really really really don't like "use" anyway and prefer always to
> qualify imported names.
>
> What I'd like is a pragma that switches-off and switches-on the
> warning over the specific range of lines containing the renamings, but
> no such seems to be available.  I don't want to switch off the warning
> from the command line as that will suppress valid warnings.
>
> Is there another way ?  Is there some rearrangement of the source that
> WOULD suppress the unwanted warnings.
>
> So the question:

A quick read of this thread seems to indicate that the OP has not had
his question answered, beyond "read the docs."

Google reveals this Ada Gem of the Week from AdaCore:
http://www.adacore.com/2007/11/19/ada-gem-18/

It shows how to turn off warnings for a particular range of code. From
TFA:


   package body Warnings_Example is

      procedure Mumble (X : Integer) is
      begin
         null;
      end Mumble;

   end Warnings_Example;

will cause GNAT to complain:

warnings_example.adb:5:22: warning: formal parameter "X" is not
referenced
But the following will compile cleanly:

   package body Warnings_Example is

      pragma Warnings (Off, "formal parameter ""X"" is not
referenced");
      procedure Mumble (X : Integer) is
      pragma Warnings (On, "formal parameter ""X"" is not
referenced");
      --  X is ignored here, because blah blah blah...
      begin
         null;
      end Mumble;

   end Warnings_Example;


Jerry

Re: Selective suppression of warnings --- gnat on GNU/Linux

[Robert A Duff]

"(see below)" <yaldnif.w@blueyonder.co.uk> writes:

> On 31/12/2008 09:46, in article 42ffjg.s9b.ln@hunter.axlog.fr, "Jean-Pierre
> Rosen" <rosen@adalog.fr> wrote:
>
>> By all means, please, let's get rid of Integer!
>
> And String? ?-)

Well, since we're talking about grossly incompatible changes, we might
as well have:

    type String_Index is range 1..<implementation-defined>;
    type String is array (String_Index range <>) of Character;

More generally, it would also be nice to have a way to say, "Give me a
number that would be appropriate as the upper bound of an array whose
component type is T."  The number would be guaranteed to be big enough
that you would get Storage_Error if you ever create an array that big.

- Bob

Re: Selective suppression of warnings --- gnat on GNU/Linux

[Robert A Duff]

Jean-Pierre Rosen <rosen@adalog.fr> writes:

> Robert A Duff a �crit :
>> If that's true, then we must presume that the Pascal
>> programmer already made sure that calculations won't
>> overflow
> Sigh... I'm afraid you are over-optimistic here

Not really.  I didn't say "programmer made sure...",
I said we must presume they did.
Not because it's true, but because we have no
choice.

;-) ;-)

>> Or else there's a bug in the Pascal code,
>> and we're going to translate that into the same
>> bug in the Ada code.
> I agree that the translator can't do any better.
>
>>     type Pascal_Integer is range ...;
>>     subtype T is Pascal_Integer range A..B;
>> where the rangs of Pascal_Integer is chosen to
>> match the Pascal compiler -- obviously you have
>> to know something about the Pascal compiler.
> This is a good idea, and shows the Pascal legacy for the future maintainer.

- Bob

Re: Selective suppression of warnings --- gnat on GNU/Linux

[Jeffrey R. Carter]

Robert A Duff wrote:
> 
> More generally, it would also be nice to have a way to say, "Give me a
> number that would be appropriate as the upper bound of an array whose
> component type is T."  The number would be guaranteed to be big enough
> that you would get Storage_Error if you ever create an array that big.

Isn't that approximated by System.Max_Int and System.Max_Binary_Modulus? On many 
modern processors and OSes, though, one could possibly have a packed array of 
Boolean with those bounds that would fit in the available memory. But since you 
can't create an integer type with more values, the desired effect would be 
impossible to achieve.

-- 
Jeff Carter
"Drown in a vat of whiskey. Death, where is thy sting?"
Never Give a Sucker an Even Break
106

Re: Selective suppression of warnings --- gnat on GNU/Linux

[Robert A Duff]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.acm.org> writes:

> Robert A Duff wrote:
>> More generally, it would also be nice to have a way to say, "Give me a
>> number that would be appropriate as the upper bound of an array whose
>> component type is T."  The number would be guaranteed to be big enough
>> that you would get Storage_Error if you ever create an array that big.
>
> Isn't that approximated by System.Max_Int and System.Max_Binary_Modulus?

Well, the RM doesn't say that, and it's not true on at least some
implementations.  For example, GNAT on a 32-bit machine has
System.Max_Int = 2**63-1.  But if I want a possibly large
array of Integers, I want something like:

    type Index is range 1..2**31-1;
    type A is array (Index range <>) of Integer;

Or I might want 2**32-1, but 2**63-1 is way too big for a 32-bit
machine, and would be unnecessarily inefficient.

> On many modern processors and OSes, though, one could possibly have a
> packed array of Boolean with those bounds that would fit in the
> available memory. But since you can't create an integer type with more
> values, the desired effect would be impossible to achieve.

Good point.

On a 64-bit machine, you have enough virtual memory to create a packed
array of 2**63-1 Booleans (2**60 bytes), but you don't have enough
physical memory, or even paging file, to store it.

- Bob

Re: Selective suppression of warnings --- gnat on GNU/Linux

[Robert A Duff]

Jerry <lanceboyle@qwest.net> writes:

>       pragma Warnings (Off, "formal parameter ""X"" is not
> referenced");

And there's a limited form of wildcards allowed.

- Bob

Re: Selective suppression of warnings --- gnat on GNU/Linux

[Michael Mounteney]

Thanks for that tip, Jerry.  My specific question was solved by
Ludovic's "use type X" tip, above, but your answer will be useful in
eliminating other warnings.

Re: Selective suppression of warnings --- gnat on GNU/Linux

[sjw]

On Dec 31 2008, 7:46 pm, Jerry <lancebo...@qwest.net> wrote:

>       pragma Warnings (Off, "formal parameter ""X"" is not
> referenced");
>       procedure Mumble (X : Integer) is
>       pragma Warnings (On, "formal parameter ""X"" is not
> referenced");
>       --  X is ignored here, because blah blah blah...
>       begin
>          null;
>       end Mumble;

In this particular case, pragma Unreferenced (X) would also work (on
the versions of GNAT I use; some of which are old enough not to
recognise this extended form of pragma Warnings).