Unfortunately you're not going to be able to use global variables to
turn analysis on and off at the file scope because dehydra doesn't
have a callback to see these (you'd need to use treehydra instead).
You also won't be able to rely on on any particular order when
visiting declarations so if you did go this route you'd have to save
up all of your errors and then examine line numbers to determine if
checking is enabled (the horror). Actually this situation does call
for some kind of pragma support but that won't be implemented in the
immediate future. If it's really necessary feel free to file a bug in
mozilla's rewriting and analysis section.

My suggestion would be to use function attributes to turn checking
on/off at the whole function level. You could also enable/disable
checking for all methods of a class using type attributes. For
function scope enabling/disabling of checking I would go with a simple
inline function call but the variable declarations would work too.
Check out http://mxr.mozilla.org/mozilla-central/source/xpcom/base/nscore.h#490
for how this is managed in the mozilla build system. We hide the
attributes behind macros and ifdef them as no ops when static checking
is not enabled.

As to long term maintenance, I believe dehydra builds out of the box
with gcc trunk so support in a future gcc 4.6 release should be a
given. Beyond that, I'm not really the one to ask but I don't see why
it would be unsupported.

On Sun, Jul 11, 2010 at 6:57 PM, Bartlett, Roscoe A <[email protected]> wrote:
> Ehren,
>
> This looks pretty good.  I think I can see how I can play games like the 
> static function trick.  Also, I think that the checking would be off by 
> default and it would require code to turn it on explicitly.
>
> For turning checking on and off for an entire set of functions you could use 
> static objects like:
>
>
>  // Header: ControlPointersOkay.hpp:
>
>  namespace Thyra {
>
>  class PushPointersNotOkay {};
>  class ReleasePointersNotOkay {};
>
>  class PushPointersOkay {};
>  class ReleasePointerOkay {};
>
>  } // namespace Thyra
>
>
>  // Header: MyHeader.hpp:
>
>  // Do not allow pointers for a whole block of functions
>  Teuchos::PushPointersNotOkay  MY_HEADER_POINTER_OKAY;
>
>  void myFunc1(...) {...};
>
>  void myFunc2(...)
>  {
>    ...
>    // Allow pointers for just a little bit of code
>    Teuchos::PushPointersOkay pointersOkay;
>    int *i = new int();
>    ...
>    Teuchos::ReleasePointersOkay pointersNotOkay;
>    // Now pointers are not okay anymore because of the active
>    // PushPointersNotOkay static object that is in effect
>    ...
>
>  };
>
>  void myFunc3(...) {...};
>
>  ...
>
>  // Turn off my use of checking for no pointers
>  Teuchos::ReleasePointersNotOkay  MY_HEADER_POINTERS_NOT_OKAY;
>
>
> My Dehydra script would keep track of the different static objects to turn on 
> and off checking for raw pointers.  I am guessing that in the Dehyra script 
> that you can just look at the name of type the static and local objects being 
> created and you don't really need to use user-defined attributes.  Do you see 
> anything wrong with this strategy?
>
> I will see if I can't get the Dehydra plug-in working with GCC 4.5 and see 
> how this goes.
>
> This looks very encouraging!  I will let you know how it goes and if I run 
> into any problems.  I will also let you know if it is ultimately successful 
> or not.  By the way, the final static analysis tool that I will write will do 
> more than just check for pointers.  It will also check for things like trying 
> to use raw references as data members (which is almost always asking for a 
> dangling reference, just as with a raw pointer).  The possibilities are 
> endless when you have this type of control.
>
> Thanks,
>
> - Ross
>
> P.S. What is the probability that the Dehyra plug-in will be maintained with 
> future versions of GCC?  This is a worry?  If there is high confidence that 
> the Dehyra plug-in will be maintained then this is could be a huge service 
> that the Dehydra team has done for the C++ community.  I am very excited to 
> try this.
>
>
>
>> -----Original Message-----
>> From: Ehren Metcalfe [mailto:[email protected]]
>> Sent: Sunday, July 11, 2010 12:45 AM
>> To: Bartlett, Roscoe A; [email protected]
>> Subject: Re: Dehydra support for pragmas or other ways to turn on and
>> off checking?
>>
>> Hello,
>>
>> Your best bet is to define a function with a user attribute in some
>> header:
>>
>> static inline void __attribute__((user("pointer_ok"))) pointer_ok() {}
>> static inline void __attribute__((user("pointer_not_ok")))
>> pointer_not_ok() {}
>> #define POINTER_OK pointer_ok();
>> #define POINTER_NOT_OK pointer_not_ok();
>>
>> Incidentally, custom pragmas can be used with a gcc plugin (see
>> http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/g%2B%2B.dg/plugin/pragma
>> _plugin.c?view=markup)
>> but they don't end up as ast nodes (you'll only get whole function
>> granularity).
>>
>> As for a pointer exposed by a function call, you can already check
>> this with dehydra.
>>
>> Try using a script like this to print the node info:
>>
>> function process_function(decl, stmts) {
>>  for each (let v in iterate_vars(stmts)) {
>>    do_dehydra_dump(v, 2, 5); // see libs/utils.js
>>    print("---");
>>  }
>> }
>>
>> A statement like
>>
>>  foo(/* pointer type */ bar());
>>
>> results in:
>>
>> shortName: 'foo'
>> name: 'foo(int*)'
>> isFunction: true
>> parameters: object
>>  0: object
>>    shortName: 'x'
>>    name: 'x'
>>    type: object
>>      isPointer: true
>>      precision: 64
>>      type: object
>>        min: object
>>        max: object
>>        isSigned: true
>>        precision: 32
>>        name: 'int'
>>    loc: object
>>      _source_location: 1246
>>      file: 'pragma.c'
>>      line: 10
>>      column: 6
>>      toString: object
>> type: object
>>  type: object
>>    name: 'void'
>>  parameters: object
>>    0: object
>>      isPointer: true
>>      precision: 64
>>      type: object
>>        min: object
>>        max: object
>>        isSigned: true
>>        precision: 32
>>        name: 'int'
>> loc: object
>>  _source_location: 1246
>>  file: 'pragma.c'
>>  line: 10
>>  column: 6
>>  toString: object
>> isFcall: true
>> arguments: object
>>  0: object
>>    shortName: 'bar'
>>    name: 'bar()'
>>    isFunction: true
>>    parameters: object
>>    type: object
>>      type: object
>>        isPointer: true
>>        precision: 64
>>        type: object
>>      parameters: object
>>    loc: object
>>      _source_location: 734
>>      file: 'pragma.c'
>>      line: 6
>>      column: 6
>>      toString: object
>>    isFcall: true
>>    arguments: object
>>
>> So, somewhat obscurely, for each element of the arguments array you'll
>> need to check type.type.isPointer when dealing with embedded function
>> calls.
>>
>> Also, although you should get identical results regardless, I would
>> highly recommend using GCC 4.5.
>>
>> Cheers,
>>
>> Ehren
>>
>> On Sat, Jul 10, 2010 at 11:42 PM, Ehren Metcalfe <[email protected]>
>> wrote:
>> > Hello,
>> >
>> > Your best bet is to define a function with a user attribute in some
>> header:
>> >
>> > static inline void __attribute__((user("pointer_ok"))) pointer_ok()
>> {}
>> > static inline void __attribute__((user("pointer_not_ok")))
>> pointer_not_ok() {}
>> > #define POINTER_OK pointer_ok();
>> > #define POINTER_NOT_OK pointer_not_ok();
>> >
>> > Incidentally, custom pragmas can be used with a gcc plugin (see
>> >
>> http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/g%2B%2B.dg/plugin/pragma
>> _plugin.c?view=markup)
>> > but they don't end up as ast nodes (you'll only get whole function
>> > granularity).
>> >
>> > As for a pointer exposed by a function call, you can already check
>> > this with dehydra.
>> >
>> > Try using a script like this to print the node info:
>> >
>> > function process_function(decl, stmts) {
>> >  for each (let v in iterate_vars(stmts)) {
>> >    do_dehydra_dump(v, 2, 5); // see libs/utils.js
>> >    print("---");
>> >  }
>> > }
>> >
>> > A statement like
>> >
>> >  foo(/* pointer type */ bar());
>> >
>> > results in:
>> >
>> > shortName: 'foo'
>> > name: 'foo(int*)'
>> > isFunction: true
>> > parameters: object
>> >  0: object
>> >    shortName: 'x'
>> >    name: 'x'
>> >    type: object
>> >      isPointer: true
>> >      precision: 64
>> >      type: object
>> >        min: object
>> >        max: object
>> >        isSigned: true
>> >        precision: 32
>> >        name: 'int'
>> >    loc: object
>> >      _source_location: 1246
>> >      file: 'pragma.c'
>> >      line: 10
>> >      column: 6
>> >      toString: object
>> > type: object
>> >  type: object
>> >    name: 'void'
>> >  parameters: object
>> >    0: object
>> >      isPointer: true
>> >      precision: 64
>> >      type: object
>> >        min: object
>> >        max: object
>> >        isSigned: true
>> >        precision: 32
>> >        name: 'int'
>> > loc: object
>> >  _source_location: 1246
>> >  file: 'pragma.c'
>> >  line: 10
>> >  column: 6
>> >  toString: object
>> > isFcall: true
>> > arguments: object
>> >  0: object
>> >    shortName: 'bar'
>> >    name: 'bar()'
>> >    isFunction: true
>> >    parameters: object
>> >    type: object
>> >      type: object
>> >        isPointer: true
>> >        precision: 64
>> >        type: object
>> >      parameters: object
>> >    loc: object
>> >      _source_location: 734
>> >      file: 'pragma.c'
>> >      line: 6
>> >      column: 6
>> >      toString: object
>> >    isFcall: true
>> >    arguments: object
>> >
>> > So, somewhat obscurely, for each element of the arguments array
>> you'll
>> > need to check type.type.isPointer when dealing with embedded function
>> > calls.
>> >
>> > Also, although you should get identical results regardless, I would
>> > highly recommend using GCC 4.5.
>> >
>> > Cheers,
>> >
>> > Ehren
>> >
>> > On Sat, Jul 10, 2010 at 9:31 AM, Bartlett, Roscoe A
>> <[email protected]> wrote:
>> >> Hello,
>> >>
>> >> I am very interested in trying to use the Dehydra static-analysis
>> plugin for GCC 4.5 to implement some enforcement of the safe memory
>> management classes described here:
>> >>
>> >>    http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf
>> >>
>> >> Basically, I want to be able to turn on a mode on in the code where
>> the custom static analysis tool (that I will write with Dehyra) where
>> all raw pointers will not be allowed, or it will be an error.  However,
>> there will likely be places where a raw pointer will need to be exposed
>> for a short period of time.  In this cases I would like to be able to
>> temporarily turn off the the checking and then turn it back on again.
>> >>
>> >> The problem is that I don't see a way to do this with Dehydra given
>> what is documented at:
>> >>
>> >>    https://developer.mozilla.org/en/Dehydra
>> >>
>> >> I would like to use something like a pragma or something but it does
>> not look like that info is given in the parse tree.  Otherwise, I don't
>> know how I can do this.
>> >>
>> >> Also, I would need ways to detect when a raw pointer was exposed in
>> a direct function call such as with:
>> >>
>> >>    someFuncTakingRawPtr(  someFuncReturningRawPtr(...) );
>> >>
>> >> It does not look like Dehydra exposes temporary variables that are
>> managed by the compiler.
>> >>
>> >> I guess that I need to get the Dehydra plug-inn working with GCC 4.5
>> and see what kinds of info it does actually spit out.  Perhaps it
>> already returns temporary objects from function calls?
>> >>
>> >> Thanks,
>> >>
>> >> - Ross
>> >>
>> >>
>> >> --------------------------------------------------------------------
>> ---
>> >> Dr. Roscoe A. Bartlett
>> >> Sandia National Laboratories
>> >> Department of Optimization and Uncertainty Estimation
>> >> Trilinos Software Engineering Technologies and Integration Lead
>> >> (505) 844-5097
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> dev-static-analysis mailing list
>> >> [email protected]
>> >> https://lists.mozilla.org/listinfo/dev-static-analysis
>> >>
>> >
>
>
>
_______________________________________________
dev-static-analysis mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-static-analysis

Reply via email to