[cfe-dev] ConvertArgumentsForCall may segfault when called function has default parameters

[Reid Kleckner]

Yes, use cast_or_null. Other AST getters do the same thing.

On Thu, Aug 14, 2014 at 3:34 PM, Keno Fischer <kfischer at college.harvard.edu>
wrote:

> So, I believe the seg fault is actually it trying to dyn_cast a NULL
> expr inside getArg(N). Should I adjust getArg to return NULL in that
> case?
>
> On Thu, Aug 14, 2014 at 6:32 PM, Keno Fischer
> <kfischer at college.harvard.edu> wrote:
> > Sounds good, I'll draft up a patch.
> >
> > On Thu, Aug 14, 2014 at 6:31 PM, Reid Kleckner <rnk at google.com> wrote:
> >> I vote for making getLocStart() / getLocEnd() check that getArg(N) is
> not
> >> null before pulling the location from it. If we have a setter that
> nulls out
> >> subexprs, then it seems like the class should tolerate null subexprs in
> >> other methods.
> >>
> >>
> >> On Thu, Aug 14, 2014 at 1:23 PM, Keno Fischer <
> kfischer at college.harvard.edu>
> >> wrote:
> >>>
> >>> Hello,
> >>>
> >>> when the CallExpr passed to Sema::ConvertArgumentsForCall has all
> >>> default parameters, and the number of actual arguments passed is zero,
> >>> this function will segfault in the call to Call->getLocStart() if the
> >>> Callee has an invalid getLocStart(), the reason being that since
> >>> ConvertArgumentsForCall has set the correct number of arguments, but
> >>> has not filled them in yet, getLocStart() will try to access the first
> >>> (not yet existent) argument and thus segfaults. One possible fix is to
> >>> move the call to Call->getLocStart() before the adjustment of the
> >>> number of function arguments. Does anybody see something better? It
> >>> seems to me that this shouldn't segfault even on an invalid location,
> >>> since getLocStart even explicitly checks for the 0 argument case.
> >>>
> >>> Thanks,
> >>> Keno
> >>> _______________________________________________
> >>> 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/20140814/c9353e12/attachment.html>