Re: [abc] [Bug 18] New: jimple type assigner can interact badly with cast pointcuts in extreme cases

On Fri, Sep 17, 2004 at 02:02:56AM +0100, Ganesh Sittampalam wrote:
> The AspectJ differences between bytecode and source are clearly a mess in
> search of a solution; but I don't think we should be adding to them with
> EAJ. I'm not suggesting we should be in a rush to fix this, but I think
> refusing to fix it ever is unreasonable; it's not particularly hard to fix
> (just tag the casts that either do or don't come from bytecode).

But that opens up yet another can of worms (where will it all end?): is
the point of the cast pointcut to capture all of the casts in the code
going into the compiler, or all the code coming out? I think different
users could make sensible arguments for either alternative. For example,
you may want to tag casts with an after throwing that does some recovery
if they fail; in that case, you wouldn't want output in which certain
casts lack this recovery code just because they weren't in the original
bytecode.

In this case, a very easy "fix" is to just define the cast extension as
implementing the second alternative, which is just as valid as the
first.

I guess we can leave it open, but it makes abc look bad to have bugs and
test failures which, IMHO, aren't really bugs.

Ondrej

>
> Ganesh
>
> On Thu, 16 Sep 2004, Ondrej Lhotak wrote:
>
> > I'm trying to decide whether to close this WONTFIX or INVALID, and I
> > don't believe there should be a test case in our test suite for it.
> > If I understand correctly, this bug cannot happen on code produced by
> > javac. Soot was designed from the ground up to handle any bytecode,
> > even that not produced by Java. Afaik, abc, and the AspectJ language
> > itself, weren't. If you give it code that is not typeable without a
> > cast, it's unlikely that we're ever going to process it without adding
> > a cast as long as we're using Soot (hence WONTFIX). I'm sure we make
> > plenty of other much more serious assumptions about the code coming
> > from javac than this. Consider all the synthetic attribute stuff, the
> > helper methods, initializers that we inline, inner class attributes,
> > weaving in the presence of exception handlers and synchronization, and
> > I'm sure there's lots more. If we do want to define the semantics in
> > terms of bytecode rather than Java source, then that's a huge change in
> > the design of the compiler and even the language. If it's a bug that
> > the language is defined in terms of Java and not bytecode, then let's
> > make such a bug, and put the countless other issues into it as well.
> > Ohterwise, we have plenty of real bugs to fix; let's not clutter things
> > with stuff like this.
> >
> > Ondrej
> >
> > ----- Forwarded message from abc-bugs@comlab.ox.ac.uk -----
> >
> > From: abc-bugs@comlab.ox.ac.uk
> > To: abc-bugs@comlab.ox.ac.uk
> > Subject: [Bug 18] New: jimple type assigner can interact badly with cast pointcuts in extreme cases
> > Date: Fri, 17 Sep 2004 00:55:41 +0100
> >
> > http://abc.comlab.ox.ac.uk/cgi-bin/bugzilla/show_bug.cgi?id=18
> >
> > Summary: jimple type assigner can interact badly with cast
> > pointcuts in extreme cases
> > Product: abc
> > Version: unspecified
> > Platform: PC
> > OS/Version: Linux
> > Status: NEW
> > Severity: minor
> > Priority: P2
> > Component: EAJ
> > AssignedTo: abc-bugs@comlab.ox.ac.uk
> > ReportedBy: ganesh@comlab.ox.ac.uk
> >
> >
> > This is a rather obscure bug even by my standards :-)
> >
> > If you consult the SAS 2000 paper which roughly describes the Jimple typing
> > algorithm (http://www.sable.mcgill.ca/publications/papers/#sas2000), you find
> > that in certain corner cases on bytecode not produced from Java source, casts
> > get inserted by the Jimplifier.
> >
> > This means that the cast pointcut might find itself applying at a point that
> > didn't have a cast in the original bytecode.
> >
> > Test case 992 exposes this bug.
> >
> >
> >
> > ------- You are receiving this mail because: -------
> > You are the assignee for the bug, or are watching the assignee.
> >
> >
> > ----- End forwarded message -----
> >
> >
> >
>
>
Received on Fri Sep 17 02:54:41 2004