[aspectc-user] volatile kills args (...) matching

arnd-hendrik.mathias at nefkom.net arnd-hendrik.mathias at nefkom.net
Sat Apr 5 05:47:25 CEST 2008


Hi,
I don't think it is really a bug but depends rather on the way, the  
pointcut handling and the before(), after()...etc. functions work. My  
test application shows following behavior:

- volatile does not influence the matching of pointcuts to the  
functions itself, which means that even
   + a pointcut with a volatile parameter matches a function with  
non-volatile parameter and
   + a pointcut with a non-volatile parameter matches a function with  
volatile parameters.

- using volatile in the parameter list of before ( ... ) etc. causes  
the advice to be silently ignored in any case (no warning, no error  
but no working, too).

- omitting volatile in the parameter list of the before ( ... ) etc.  
still fits the parameter even of a volatile parameter pointcut.

I try to attach the example code to this mail. If it turns out to be  
filtered out I'll cite it in another one.
Best regards

Arnd-Hendrik


Zitat von Panu Bloigu <panu.bloigu at gmail.com>:

> Hello.
>
> arnd-hendrik.mathias at nefkom.net wrote:
>> Hi,
>> I just recognized one strange effect with parameter types in   
>> pointcuts: If I declare one parameter of a function as volatile   
>> type (in the source code as well as in the aspect) ac++ does no   
>> longer match this execution (nor call) pointcut ( execution ( "%   
>> blah ( ... )" ) && args ( bli, blubb )).
>> Has anyone experienced this before?
>> Regards
> If you think that you have found a bug in ac++, then could you please
> post a compilable code example that demonstrates the problem. If at all
> possible, it would be good to try to minimize the code example so that
> it still is compilable and still demonstrates the problem. If your
> findings indeed turn out to be a bug in ac++, then I'm pretty sure the
> AspectC++ developers will appreciate that you reported it.
>>
>>
>> Arnd-Hendrik
>>
>> P.S.: I know that a volatile parameter in a function looks somewhat  
>>  uncommon, but I just stripped it down for debugging purposes. In   
>> real life it's a typedef'ed HW-Register value and this must be   
>> volatile.
>
> It's hard to say if this is relevant in your case, but I think that
> using type aliases (i.e. typedef'd type names) in pointcut descriptions
> is considered problematic. I once posted a question about this on the
> list, and here's Olaf's explanation on the issues involved:
> http://aspectc.org/pipermail/aspectc-user/2007-January/001098.html
>
> -- Panu


-------------- next part --------------
A non-text attachment was scrubbed...
Name: main.cc
Type: text/x-c++src
Size: 343 bytes
Desc: not available
URL: <http://www.aspectc.org/pipermail/aspectc-user/attachments/20080405/7b043124/attachment.cc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: main.ah
Type: application/octet-stream
Size: 1344 bytes
Desc: not available
URL: <http://www.aspectc.org/pipermail/aspectc-user/attachments/20080405/7b043124/attachment.obj>


More information about the aspectc-user mailing list