Prev: naming, was Re: Design problem: generic package vs tagged subtype
Next: ANN: GtkAda contributions v2.7
From: BrianG on 3 Jul 2010 22:22
Stephen Leake wrote:
> Markus Schoepflin <nospam(a)no.spam> writes:
>> Am 02.07.2010 11:30, schrieb Stephen Leake:
>>> Markus Schoepflin<nospam(a)no.spam> writes:
>>> gnat is a very good compiler; the warnings it produces should be taken
>>> seriously.
>> I would love to, but I'm dealing with a multi-million LOC legacy code
>> base of Ada 83 in maintenance mode, which produces quite a large
>> number of warnings.
>>
>> I neither have the time nor the resources available to fix all of
>> them, nor am I allowed to do so.
>
> I can understand not changing design in a maintenance situation, but
> adding 'pragma Warnings (off)' in places ought to be ok. Still, it can
> be a lot of work.
>
In many maintenance situations, _ANY_ source code change is an issue.
The more files you change (in some situations the more lines you
change), the greater the impact - on testing and on cost. Adding
pragmas throughout the code may be as large an impact as a
moderate-to-large redesign.

Another GNAT warning I'd put in the same category is 'object XYZ is read
but never written' (or something similar). I saw this recently for a
record type (defined in a different location), where all components have
default value ... except for one which was added recently.
From: Markus Schoepflin on 5 Jul 2010 04:16
Am 02.07.2010 22:33, schrieb Georg Bauhaus:
> On 7/2/10 11:44 AM, Markus Schoepflin wrote:
>
>> I neither have the time nor the resources available to fix all of them,
>> nor am I allowed to do so. But if the compiler already knows that there
>> will be a constraint error at runtime, I would have liked the
>> compilation to fail.
>
> (I can't think of a way to do this without annotating each
> occurrence in the source program: some programs might want
> the constraint_error to be produced for whatever reason ...)

I'm sure some programs may want to raise constraint errors in their normal
course of action, but I'm also sure it's always an error if one of the
programs I'm dealing with statically raises a constraint error.

By the way, I found the compiler I had in mind in the first place. It was
DEC's/Compaq's/HP's cxx compiler for Tru64. It had very elaborate features
for message control. Each type of message had a unique tag and number, and
you could redefine the severity of most messages by using the option
-msg_<severity> <tag>, where severity is one of inform, warn, error,
enable, disable.

So if constraint error would have had the tag CONSER for example, I could
have said -msg_error CONSER, et voil�, mission accomplished.

> Anyway, grep has helped me scan traces of output and trigger
> actions accordingly, that should be a workaround.
> I understand GPS is programmable, so maybe the log console
> has hooks this sort of special case?

Yes, I think a grep output filter will be the way to go in my case.

Markus
From: Robert A Duff on 6 Jul 2010 17:12
Markus Schoepflin <nospam(a)no.spam> writes:

> I would love to, but I'm dealing with a multi-million LOC legacy code
> base of Ada 83 in maintenance mode, which produces quite a large number
> of warnings.

In that case, I think you should read the docs about the various
warning switches, and turn off the ones you wish to ignore,
and turn on the ones you wish to fix. Then use -gnatwe to
make all warnings (the ones you turned on) into errors.
Then fix those: for each warning, if the code is wrong,
fix the bug, and if not, use pragma Warnings(Off).

Don't be shy about using Warnings(Off). The compiler is
sometimes wrong to warn, and the Warnings(Off) (with
a suitable comment) documents the fact that something
fishy is going on, but in this particular case it's OK.
Don't contort the code just to make the compiler happy.
It's usually a good idea to use the form of the pragma
that gives the warning text.

Note that you can turn off warnings globally in two ways:
with switches, or with pragmas in a configuration file.
The latter can be as fine-grained as you like.

For new code, -gnatwae is a good idea. But that's
not your case.

- Bob
From: Robert A Duff on 6 Jul 2010 17:18
"Randy Brukardt" <randy(a)rrsoftware.com> writes:

> Keep in mind that such a message may occur in cases where there is no actual
> problem.

Right.

>...That can often happen if you have code that is conditional on
> constants. To take an extreme example, if you have:
>
> Max_Items := constant := 0;
>
> and then the code is:
>
> if Max_Items /= 0 then
> Average := Float(Count)/Float(Max_Items); -- (1)
> else
> Average := 0.0;
> end if;
>
> The code at (1) would raise Constraint_Error if it was executed, but of
> course it can never be executed. If you change the warning to an error here,
> you won't be able to compile the code without removing or changing the
> expression at (1), and that would cause problems if/when Max_Items is set to
> a different value.

You don't actually need to change (1). This is what pragma
Warnings(Off) is for. I don't know if GNAT warns about the
above (I think it might notice that (1) is dead code), but if
it does, tell it to shut up (after carefully making sure the
warning is indeed bogus).

In a case like this, Max_Items is probably declared in some package that
has multiple variants, which are selected by build options (e.g. GNAT
project files). Of course you need to test all the variants.

You can put Warnings(off/on) around just the one line of code.

- Bob
From: Randy Brukardt on 7 Jul 2010 19:32
"Robert A Duff" <bobduff(a)shell01.TheWorld.com> wrote in message
news:wcctyocqph3.fsf(a)shell01.TheWorld.com...
> "Randy Brukardt" <randy(a)rrsoftware.com> writes:
>
>> Keep in mind that such a message may occur in cases where there is no
>> actual
>> problem.
>
> Right.
>
>>...That can often happen if you have code that is conditional on
>> constants. To take an extreme example, if you have:
>>
>> Max_Items := constant := 0;
>>
>> and then the code is:
>>
>> if Max_Items /= 0 then
>> Average := Float(Count)/Float(Max_Items); -- (1)
>> else
>> Average := 0.0;
>> end if;
>>
>> The code at (1) would raise Constraint_Error if it was executed, but of
>> course it can never be executed. If you change the warning to an error
>> here,
>> you won't be able to compile the code without removing or changing the
>> expression at (1), and that would cause problems if/when Max_Items is set
>> to
>> a different value.
>
> You don't actually need to change (1). This is what pragma
> Warnings(Off) is for. I don't know if GNAT warns about the
> above (I think it might notice that (1) is dead code), but if
> it does, tell it to shut up (after carefully making sure the
> warning is indeed bogus).

Right. I don't know the details about GNAT, it might be harder to create
such an example than it would be for Janus/Ada (which makes these warning
checks during static expression evaluation, which is early during
compilation, while dead code elimination is much later). In general,
compilers may do the various tasks in different orders, and thus get
different warnings. (That one of many reasons why it is good to try code
that is intended to be portable on multiple compilers).

Randy.


> In a case like this, Max_Items is probably declared in some package that
> has multiple variants, which are selected by build options (e.g. GNAT
> project files). Of course you need to test all the variants.
>
> You can put Warnings(off/on) around just the one line of code.
>
> - Bob


First  |  Prev  | 
Pages: 1 2 3
Prev: naming, was Re: Design problem: generic package vs tagged subtype
Next: ANN: GtkAda contributions v2.7