* Simple Warnings Needs @ 2011-02-23 18:52 Rego 2011-02-23 19:56 ` mockturtle ` (2 more replies) 0 siblings, 3 replies; 7+ messages in thread From: Rego @ 2011-02-23 18:52 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Simple Warnings Needs 2011-02-23 18:52 Simple Warnings Needs Rego @ 2011-02-23 19:56 ` mockturtle 2011-02-23 23:07 ` jpwoodruff 2011-02-23 20:06 ` Ludovic Brenta 2011-02-23 21:55 ` Martin 2 siblings, 1 reply; 7+ messages in thread From: mockturtle @ 2011-02-23 19:56 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Simple Warnings Needs 2011-02-23 19:56 ` mockturtle @ 2011-02-23 23:07 ` jpwoodruff 0 siblings, 0 replies; 7+ messages in thread From: jpwoodruff @ 2011-02-23 23:07 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Simple Warnings Needs 2011-02-23 18:52 Simple Warnings Needs Rego 2011-02-23 19:56 ` mockturtle @ 2011-02-23 20:06 ` Ludovic Brenta 2011-02-23 21:55 ` Martin 2 siblings, 0 replies; 7+ messages in thread From: Ludovic Brenta @ 2011-02-23 20:06 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Simple Warnings Needs 2011-02-23 18:52 Simple Warnings Needs Rego 2011-02-23 19:56 ` mockturtle 2011-02-23 20:06 ` Ludovic Brenta @ 2011-02-23 21:55 ` Martin 2011-02-24 8:26 ` Markus Schöpflin 2 siblings, 1 reply; 7+ messages in thread From: Martin @ 2011-02-23 21:55 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Simple Warnings Needs 2011-02-23 21:55 ` Martin @ 2011-02-24 8:26 ` Markus Schöpflin 2011-02-26 3:51 ` Rego 0 siblings, 1 reply; 7+ messages in thread From: Markus Schöpflin @ 2011-02-24 8:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Simple Warnings Needs 2011-02-24 8:26 ` Markus Schöpflin @ 2011-02-26 3:51 ` Rego 0 siblings, 0 replies; 7+ messages in thread From: Rego @ 2011-02-26 3:51 UTC (permalink / raw) Thank you people, your comments have made me understand better this. Cheers. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2011-02-26 3:51 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-02-23 18:52 Simple Warnings Needs Rego 2011-02-23 19:56 ` mockturtle 2011-02-23 23:07 ` jpwoodruff 2011-02-23 20:06 ` Ludovic Brenta 2011-02-23 21:55 ` Martin 2011-02-24 8:26 ` Markus Schöpflin 2011-02-26 3:51 ` Rego
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox