This is the mail archive of the
mailing list for the GCC project.
Re: Problem with type safety and the "sentinel" attribute
- From: "Kaveh R. Ghazi" <ghazi at caipclassic dot rutgers dot edu>
- To: stefan at space dot twc dot de
- Cc: gcc at gcc dot gnu dot org, timj at gtk dot org
- Date: Fri, 9 Jun 2006 12:30:36 -0400 (EDT)
- Subject: Re: Problem with type safety and the "sentinel" attribute
- References: <20060609152646.GE20719@space.twc.de>
> void print_string_array (const char *array_name,
> const char *string, ...) __attribute__
> 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:
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
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 R. Ghazi email@example.com