Simple Warnings Needs

Simple Warnings Needs

[Rego]

I would like to know (in more details than gnat documentation) the criticality of these warnings options: 
 ** "-gnatwd" (Implicit dereferencing)
 ** "-gnatwf" (Unreferenced formals)
 ** "-gnatwh" (Hiding)
 ** "-gnatwm" (Modified but unreferenced variables)
 ** "-gnatwk" (Variables that could be constants)

I mean, for instance, a code with several variables that could be constants, even in local procedures is an ugly code, not clean, but generally it's ok if works. But I just want to understand what kind of other complications that code could get due to not fixing these type of constructs. Someone once told me that it could bring out code vulnerabilities, the binary app could become "hackeable", but he gave not a deep explanation (so I cannot convince others about this). And I did not find in ARM05 and gnat documentation. So, could someone give me a hint?

Regards.

Re: Simple Warnings Needs

[mockturtle]

On Wednesday, February 23, 2011 7:52:37 PM UTC+1, Rego wrote:
> I would like to know (in more details than gnat documentation) the criticality of these warnings options: 
>  ** "-gnatwd" (Implicit dereferencing)
>  ** "-gnatwf" (Unreferenced formals)
>  ** "-gnatwh" (Hiding)
>  ** "-gnatwm" (Modified but unreferenced variables)
>  ** "-gnatwk" (Variables that could be constants)
> 

Hmmm... I would say that at least some of these warnings do not induce security threats.  For example, Hiding warning should be raised in a context similar to this (disclaimer: I do not have an Ada compiler at hand [my dog eat it :-)], so I cannot test the code)

  with A;  -- it declares Foo : Integer;
  
  procedure Warn is
    use A;  -- make A.Foo visible
    Foo : integer; -- Warning: Hiding A.Foo
    Goo : integer;
  begin
     -- The local one or the one in A?
     Goo := Foo;  
  end Warn;

In this case, I would say, the compiler warns you since you could want to access the Foo in A and you did not notice that you hide it.  I would say that in a typical case this does not give rise to a security threat, but to a non-working program.

About "-gnatwf" (Unreferenced formals), "-gnatwm" (Modified but unreferenced variables)  I think that the idea is to warn about "strange" construct: why did you modify that variable if you are not reading it again?  This is strange and maybe it is the consequence of an error.  Again, the risk is having a program with a bug rather than a security threat. 

I do not know about the remaining two.  Maybe "-gnatwk" (Variables that could be constants) it is just about optimization and/or declaring explicitly that the variable will not change, but I am not sure.

Re: Simple Warnings Needs

[jpwoodruff]

On Feb 23, 11:56 am, mockturtle <framefri...@gmail.com> wrote:
> On Wednesday, February 23, 2011 7:52:37 PM UTC+1, Rego wrote:
> > I would like to know (in more details than gnat documentation) the criticality of these warnings options:
> >  ** "-gnatwd" (Implicit dereferencing)
> >  ** "-gnatwf" (Unreferenced formals)
> >  ** "-gnatwh" (Hiding)
> >  ** "-gnatwm" (Modified but unreferenced variables)
> >  ** "-gnatwk" (Variables that could be constants)
>

>
> About "-gnatwf" (Unreferenced formals), "-gnatwm" (Modified but unreferenced variables)  I think that the idea is to warn about "strange" construct: why did you modify that variable if you are not reading it again?  This is strange and maybe it is the consequence of an error.  Again, the risk is having a program with a bug rather than a security threat.
>

I think I'd like these if I were "adjusting" some old code.  Suppose I
added a requirement to some good quality code.  I'll look for the
warning when I'm done modifying, so I'll see if I left some artifact
that should have been considered when I modify.

John

Re: Simple Warnings Needs

[Ludovic Brenta]

Rego writes:
> I would like to know (in more details than gnat documentation) the
> criticality of these warnings options:
>
>  ** "-gnatwd" (Implicit dereferencing)
>  ** "-gnatwf" (Unreferenced formals)
>  ** "-gnatwh" (Hiding)
>  ** "-gnatwm" (Modified but unreferenced variables)
>  ** "-gnatwk" (Variables that could be constants)
>
> I mean, for instance, a code with several variables that could be
> constants, even in local procedures is an ugly code, not clean, but
> generally it's ok if works. But I just want to understand what kind of
> other complications that code could get due to not fixing these type
> of constructs. Someone once told me that it could bring out code
> vulnerabilities, the binary app could become "hackeable", but he gave
> not a deep explanation (so I cannot convince others about this). And I
> did not find in ARM05 and gnat documentation. So, could someone give
> me a hint?

I don't think that "variables that could be constants" would make the
program unsafe in the ways you describe.  Instead, it could prevent the
compiler from doing some optimizations.  Bust the most important aspect
of these warnings is that, if you exmine the sources at the place of the
warning, you can discover bugs (it has happened to me several times).
The other important aspect is long-term maintenance of your sources.  In
this context, if you decide not to fix the warnings, you basically
guarantee that someone else, years after you, will have to investigate
the warnings again.

In addition to these considerations, "implicit dereferencing" could be
important for safety-critical software, where the executable object
code, not the sources, must be certified.  It is important to be able to
trace every instruction in the object code to a statement in the
sources.  Here, the compiler is warning you that it is emitting machine
instructions that do not have an "obvious" source.

"Unreferenced formals" and "Modified but unreferenced variables" could
mean a design bug. If not, you can use pragma Unreferenced to document
the fact that you've looked at this warning and decided it was not a bug
(here again, think about long-term maintenance by many people).

"Hiding" is sometimes forbidden outright by coding standards, so you
want the compiler to warn you about that.

-- 
Ludovic Brenta.

Re: Simple Warnings Needs

[Martin]

On Feb 23, 6:52 pm, Rego <pablo.r...@embraer.com.br> wrote:
>  ** "-gnatwk" (Variables that could be constants)

A rationale behind this one is that by explicitly declaring items as
constants you can prevent _accidental_ modification. It's also a nice
visual queue to a reader that the value is deliberately set once and
once only, or they are left to wonder why a variable is defined and
set once but never again - is that a bug?

I seem to remember an article by Dewar explaining why constants can
rarely be optimized but I can't put my finger on it at the moment...

HTH
-- Martin

Re: Simple Warnings Needs

[Markus Schöpflin]

Am 23.02.2011 22:55, schrieb Martin:

[...]

> I seem to remember an article by Dewar explaining why constants can
> rarely be optimized but I can't put my finger on it at the moment...

There has been a GOTW article about this. It of course discusses C++, but 
most statements are also valid for other languages. See 
http://www.gotw.ca/gotw/081.htm.

To quote from it's summary at the end:

<quote>
It's a common belief that const-correctness helps compilers generate 
tighter code. Const is indeed a Good Thing, but the point of this issue of 
GotW is that const is mainly for humans, rather than for compilers and 
optimizers. When it comes to writing safe code, const is a great tool that 
lets programmers write safer code with compiler checking and enforcement. 
Even when it comes to optimization, const is still principally useful as a 
tool that lets human class designers better implement handcrafted 
optimizations, and less so as a tag for omniscient compilers to 
automatically generate better code.
</quote>

Markus

Re: Simple Warnings Needs

[Rego]

Thank you people, your comments have made me understand better this.
Cheers.