Re: Warning for unadorned 0 in varargs lists?

["Kaveh R. Ghazi" <ghazi at unknown>]

 > There's also the problem of
 > 
 > * avoiding the proliferation of many different attributes to cover the 
 > different conventions that may be used for this sort of thing; and
 > 
 > * covering the main cases used in real code (note e.g. execle isn't a 
 > NULL-terminated list, there's one argument after the NULL); and
 > 
 > * at the same time avoiding waiting forever in the hope of a general 
 > design that will do everything including many cases that are of no use.
 > 
 > (This makes a thorough survey of the conventions used for variadic 
 > function termination in real code important, to assess what is worth 
 > including in such an attribute and what possibilities are purely 
 > theoretical.)
 > 
 > http://gcc.gnu.org/ml/gcc-patches/2002-10/msg00789.html
 > http://gcc.gnu.org/ml/gcc-patches/2002-10/msg00802.html
 > http://gcc.gnu.org/ml/gcc-patches/2003-05/msg01571.html

I'd like to propose the following design:

__attribute__ ((sentinel [, sentinel_position_from_end [, sentinel_value]]))


Of the various choices proposed over time, I picked "sentinel" rather
than "null_terminated" or "terminated" because it avoids conveying a
particular terminator value or a position.  It also makes it a
superset of the existing openbsd syntax.

The square-brackets denote optional args whose default values are:
	sentinel_position_from_end=0
	sentinel_value=NULL

GCC's copy of stddef.h always defines NULL to (void*)0 in C and to
__null in g++.  In each C dialect, we would accept the respective
value.  We would warn about unadorned zero.

The warnings would be controlled by -Wformat (and therefore by -Wall).

so __attribute__ ((sentinel)) or __attribute__ ((sentinel, 0)) is the
"concat" style NULL termintion.

and __attribute__ ((sentinel, 1)) would be the "execle" style.

I've not yet seen any cases where a terminator other than NULL is
used, but this design allows one to specify it.

Another advantage of the design given the default argument values is
that one could implement this in stages as necessary.  E.g. we could
avoid implementing the sentinel_value argument and just allow the
first two or even just one until someone comes along and shows a need
for the other(s).  Internally I would expect that we would implement
at least the first two arguments so we could hardwire execle.

This design allows for all possibilities mentioned in the above
threads cited by Joseph except for multiple sentinels in one variadic
function call.  Given Joseph's third bullet about not waiting forever,
I think my proposal gives us everything we actually need with the most
flexibility and the simplest syntax.

Comments?

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu