[cfe-dev] methods to access "base" and "index" in ArraySubscriptExpr

[Steve Naroff]

On Aug 17, 2007, at 9:58 AM, Ted Kremenek wrote:

> Recently I added a comment to the class definition for
> ArraySubscriptExpr (in Sema/Expr.h) noting that the true "base" of the
> array may actually be returned by "getIdx()" if the array happened to
> be written in the source (for example) as "4[A]" instead of "A[4]."  I
> think this is confusing, and may cause glitches down the line for
> semantic analysis tools built on the frontend.
>

I agree. I had similar thoughts, and was going to discuss this with you.

> I propose renaming the current getBase and getIdx methods to "getLHS"
> and "getRHS" respectively, as the current interpretation of these
> functions has more do with source code syntax (their position in the
> source code) rather than semantics.  I then propose adding new getBase
> and getIdx functions that look something like this:
>
> Expr *getBase() { return (Base->getType()->isPointerType()) ? Base :
> Idx; }
> Expr *getIdx() { return (!Idx->getType()->IsPointerType()) ? Idx :
> Base; }
>
> Naturally, along with these changes I suggest changing the member
> variables "Base" and "Idx" to "LHS" and "RHS" respectively.
>
> Comments?  One disadvantage that I see of this change is that using
> getBase() and getIdx() in tandem may require some extra unnecessary
> checking (as the same check is performed in both functions).  For such
> cases, we could consider adding an extra method that returns both the
> Base and the Idx expressions in a std::pair (would there be an
> efficiency issue here?).

I have no problem with the extra checking. I do have another suggestion:

Why not simply change the following...

   return new ArraySubscriptExpr(LHSExp, RHSExp, ResultType, RLoc);

to...

   return new ArraySubscriptExpr(BaseExpr, IndexExpr, ResultType, RLoc);

? And keep everything else the same...

The only disadvantage with this is the crazy case of idx[base] will  
always be output as base[idx] (if we are doing a pretty printer or  
source analysis tool). From my perspective, this loss is extremely  
minor (and can be fixed one day if necessary). In other words, I  
think it makes sense for the AST to normalize this case.

Let me know what you think,

snaroff


> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20070817/f737e731/attachment.html>