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

Keno Fischer kfischer at college.harvard.edu
Thu Aug 14 15:34:28 PDT 2014


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
>>
>>



More information about the cfe-dev mailing list