Kazu Hirata wrote: > Hi Ian, > >>> I keep finding places in GCC sources that check whether a member of >>> TYPE_ARG_TYPES is 0. For example, >>> >>> for (link = TYPE_ARG_TYPES (function_or_method_type); >>> link && TREE_VALUE (link); >>> link = TREE_CHAIN (link)) >>> gen_type_die (TREE_VALUE (link), context_die); >>> >>> Notice that TREE_VALUE (link) is part of the loop condition. >>> >>> Now, do we ever allow a NULL in TYPE_ARG_TYPES? If so, what does that >>> mean? My guess is that soneone was trying to be cautious about >>> encountering a NULL in TYPE_ARG_TYPES. (If that's the case, we should >>> be using gcc_assert instead.) >> >> >> Just guessing here, but what happens with an old-style function >> definition in C? >> >> void f(); > > AFAIK, that gets TYPE_ARG_TYPES (...) == NULL, so we don't even get to > evaluate TREE_VALUE (TYPE_ARG_TYPES (...)). > > On IRC, Daniel Berlin claims that there are some weird cases where > TREE_VALUE (TYPE_ARG_TYPES (...)) is NULL. I'll keep putting gcc_assert > to see what happens.
That may be the difference between "void f()" (where TYPE_ARG_TYPES might be NULL) and "void f(...)" (where TREE_VALUE (TYPE_ARG_TYPES) would be NULL). The latter, as Daniel says, is not valid C, but perhaps we used to accept it. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
