> void print_string_array (const char *array_name, > const char *string, ...) __attribute__ > ((__sentinel__)); > > print_string_array ("empty_array", NULL); /* gcc warns, but shouldn't */ > > The only way out for keeping the sentinel attribute and avoiding the > warning is using > > static void print_string_array (const char *array_name, ...) > __attribute__ ((__sentinel__));
I think you could maintain typesafety and silence the warning by keeping the more specific prototype and adding an extra NULL, e.g.: print_string_array ("empty_array", NULL, NULL); Doesn't seem elegant, but it does the job. > By the way, there is already an existing gcc bug, which is about the > same thing (NULL passed within named args), but wants to have it the > way it works now: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21911 Correct, the feature as I envisioned it expected the sentinel to appear in the variable arguments only. This PR reflects when I found out it didn't do that and got around to fixing it. Note the "buggy" behavior wasn't exactly what you wanted either because GCC got fooled by a sentinel in *any* of the named arguments, not just the last one. > so if it gets changed, then gcc might need to support both > - NULL termination within the last named parameter allowed > - NULL termination only allowed within varargs parameters (like it is > now) I'm not against this enhancement, but you need to specify a syntax that allows the old behavior but also allows doing it your way. Hmm, perhaps we could check for attribute "nonnull" on the last named argument, if it exists then that can't be the sentinel, if it's not there then it does what you want. This is not completely backwards compatible because anyone wanting the existing behavior has to add the attribute nonnull. But there's precedent for this when attribute printf split out whether the format specifier could be null... We could also create a new attribute name for the new behavior. This would preserve backwards compatibility. I like this idea better. Next you need to recruit someone to implement this enhancement, or submit a patch. :-) Although given that you can silence the warning by adding an extra NULL at the call site, I'm not sure it's worth it. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]