[aspectc-user] member access through an uninitialized pointer
Olaf Spinczyk
Olaf.Spinczyk at informatik.uni-erlangen.de
Thu Apr 12 11:58:08 CEST 2007
Hi Panu,
the implementation is not safe. The aspectof function should always return a
pointer to an *initialized* aspect instance. It's a "hen and egg" problem: the
aspectof function needs a valid aspect instance while the construction advice,
which creates the aspect instance, needs the aspectof function.
For me at appears to be more a problem of the aspect "Aspect" and less a code
generation problem. You could, for example, replace "Aspect *a" within the slice
by "Aspect a". Then one aspect instance would be automatically created for each
ClassA object. A construction advice wouldn't be necessary. The aspectof
function could return "&tjp->that()->a";
Best regards,
Olaf
Panu Bloigu wrote:
> Hello.
>
> I have a question about the code that ac++ generates. It seems that the
> generated C++ code accesses instances members through an uninitialized
> pointer and I'm concerned whether this really is a safe thing to do. To
> explain what I have in mind, I will first show some intentionally simple
> AspectC++ code and then show the parts of the produced C++ code that I'm
> concerned about.
>
>
> The source:
> =============================================================================
>
> class ClassA
> {
> public:
> ClassA(){}
> virtual ~ClassA(){}
> };
>
> aspect Aspect
> {
> private:
> advice "ClassA" : slice class
> {
> private:
> Aspect* a;
> };
>
> advice construction("ClassA") : after()
> {
> tjp->that()->a = new Aspect();
> }
> public:
> static Aspect* aspectof()
> {
> return tjp->that()->a;
> }
> };
> =============================================================================
>
>
>
>
>
> The parts of the compiled code that worry me. First there is this in the
> ClassA's ctor:
> =============================================================================
>
>
>
> ClassA()
> #line 106 "unitest.acc"
> {
> TJP__ZN6ClassAC1Ev_0 tjp;
> tjp._that = (TJP__ZN6ClassAC1Ev_0::That*)this;
> this->__exec_old_C1();
> AC::invoke_Aspect_Aspect_a0_after<TJP__ZN6ClassAC1Ev_0> (&tjp);
> }
> =============================================================================
>
>
> ... which leads to a call to this in the namespace AC:
> =============================================================================
>
> namespace AC {
> template <class JoinPoint>
> inline void invoke_Aspect_Aspect_a0_after (JoinPoint *tjp) {
> ::Aspect::aspectof(tjp)->__a0_after (tjp);
> }
> }
> =============================================================================
>
>
> ... which in turn first calls this in the aspect Aspect:
> =============================================================================
>
> template<class JoinPoint> static Aspect* aspectof(JoinPoint *tjp)
> {
> #line 209 "unitest.acc"
>
> typedef typename JoinPoint::That __JP_That;
> typedef typename JoinPoint::Target __JP_Target;
> typedef typename JoinPoint::Result __JP_Result;
>
> #line 26 "unitest.cpp"
>
> return tjp->that()->a; // This returns an uninitialized pointer!
> }
> =============================================================================
>
>
> As you can see, an uninitialized pointer is returned. However, the
> member __a0_after (tjp) is nevertheless accessed through that pointer.
>
> What I'm concerned about is that whether this really is a safe thing to
> do. In all C++ lessons I've participated in and in all the tutorials
> around the net a strong point has been made: always initialize your
> pointers, or the sky will fall on you!
>
> So I'm asking that on what grounds do you expect this to always work?
>
> Now, I have access to the ISO/2003 C++ standard, but I haven't been able
> to find anything there that would say that this is guaranteed to work. I
> have, however, tested member access through an uninitialized pointer
> with various compliers and on all of them it seems to work, as long as
> no data member is being assigned to in the called member function.
>
> I would appreciate if someone would show me the correct sections of the
> standard that support this as IMHO this behavior goes against the very
> semantics of an *instance* member access.
>
> Thanks,
>
> Panu.
>
>
>
> _______________________________________________
> aspectc-user mailing list
> aspectc-user at aspectc.org
> http://www.aspectc.org/mailman/listinfo/aspectc-user
More information about the aspectc-user
mailing list