Safer vararg calls

Safer vararg calls

[Yair Lenga]

Hi,

Looking for feedback on the adding new attribute to function calls that will help create safer vararg functions.

Consider the case where a vararg function takes list of arguments of the same type. In my case, there are terminated with a sentinel of null.

Char *result = delimitedstr(‘:’ “foo”, “bar”, “zoo”, NULL) ;

The standard prototype
is char * delimitedstr(char delim, char *p1…) ;

Which will currently allow many incorrect calls:
 delimitedstr(‘:’, “foo”, 5, 7.3, ‘a’) ;    // bad types + missing sentinel.

The __attribute__((sentinel)) can force the last arg to be null.

My proposal is to add new attribute ((va_vector)) that will add a check that all parameters in a vararg list match the typeof the last parameter. So that:

__attribute__ ((va_typed)) delimitedstr(char delim, char *p1…) ;

Will flag a call where any of the parameter after p1, is not a string.

This can result in cleaner, safer code, without making the calling sequence more difficult, or modifying the behavior of the call.

For Java developers, this is basically the same type checking provided by the as ‘datatype …’ (without the conversion into array).

I am Looking for feedback, Pointers on how to implement, as I do not have experience with extending gcc.

Yair

Re: Safer vararg calls

[Jonathan Wakely]

On Tue, 21 Jun 2022 at 11:17, Yair Lenga via Gcc <gcc@gcc.gnu.org> wrote:
>
> Hi,
>
> Looking for feedback on the adding new attribute to function calls that will help create safer vararg functions.
>
> Consider the case where a vararg function takes list of arguments of the same type. In my case, there are terminated with a sentinel of null.
>
> Char *result = delimitedstr(‘:’ “foo”, “bar”, “zoo”, NULL) ;
>
> The standard prototype
> is char * delimitedstr(char delim, char *p1…) ;
>
> Which will currently allow many incorrect calls:
>  delimitedstr(‘:’, “foo”, 5, 7.3, ‘a’) ;    // bad types + missing sentinel.
>
> The __attribute__((sentinel)) can force the last arg to be null.
>
> My proposal is to add new attribute ((va_vector)) that will add a check that all parameters in a vararg list match the typeof the last parameter. So that:

"va_vector" is a bad name IMHO. It tells me nothing about what it
means. Does it have something to do with SIMD vectors?

>
> __attribute__ ((va_typed)) delimitedstr(char delim, char *p1…) ;

"va_typed" at least suggests something to do with types, but it
doesn't tell me they have to be the same type.

>
> Will flag a call where any of the parameter after p1, is not a string.

In your example NULL does not have the same type as the earlier
arguments. You would have to write (char*)NULL to suppress a
diagnostic.

I also wonder how a mixture of char* and const char* arguments would
be handled in your example.


>
> This can result in cleaner, safer code, without making the calling sequence more difficult, or modifying the behavior of the call.
>
> For Java developers, this is basically the same type checking provided by the as ‘datatype …’ (without the conversion into array).
>
> I am Looking for feedback, Pointers on how to implement, as I do not have experience with extending gcc.
>
> Yair

Re: Safer vararg calls

[Yair Lenga]

Hi Jonathan, thanks for taking the time to review.

I agree with your comment about the attribute name (va_vector, va_type). My
best improvement is "va_sametype". Is it better ? ? May be "va_matchtype" ?
any other suggestions ?

For the case of the sentinel/va_sametype, I hope that the implementation
will recognize the combination of the two, and will allow NULL to be used
as-is, without having to cast it. Altough I believe that NULL pointers are
considered compatible with with any pointer. Not 100% sure about this.

I'm not sure I understand the question about mixing char * and const char
*. Probably I cause confusion with my rushed example, which should be:

      // join all parameters, return newly allocate string.
__attribute__ ((malloc(free), va_matchtype, sentinel)) char
*delimitedstr(char delim, const char *p1, ...);


On Tue, Jun 21, 2022 at 6:44 AM Jonathan Wakely <jwakely.gcc@gmail.com>
wrote:

> On Tue, 21 Jun 2022 at 11:17, Yair Lenga via Gcc <gcc@gcc.gnu.org> wrote:
> >
> > Hi,
> >
> > Looking for feedback on the adding new attribute to function calls that
> will help create safer vararg functions.
> >
> > Consider the case where a vararg function takes list of arguments of the
> same type. In my case, there are terminated with a sentinel of null.
> >
> > Char *result = delimitedstr(‘:’ “foo”, “bar”, “zoo”, NULL) ;
> >
> > The standard prototype
> > is char * delimitedstr(char delim, char *p1…) ;
> >
> > Which will currently allow many incorrect calls:
> >  delimitedstr(‘:’, “foo”, 5, 7.3, ‘a’) ;    // bad types + missing
> sentinel.
> >
> > The __attribute__((sentinel)) can force the last arg to be null.
> >
> > My proposal is to add new attribute ((va_vector)) that will add a check
> that all parameters in a vararg list match the typeof the last parameter.
> So that:
>
> "va_vector" is a bad name IMHO. It tells me nothing about what it
> means. Does it have something to do with SIMD vectors?
>
> >
> > __attribute__ ((va_typed)) delimitedstr(char delim, char *p1…) ;
>
> "va_typed" at least suggests something to do with types, but it
> doesn't tell me they have to be the same type.
>
> >
> > Will flag a call where any of the parameter after p1, is not a string.
>
> In your example NULL does not have the same type as the earlier
> arguments. You would have to write (char*)NULL to suppress a
> diagnostic.
>
> I also wonder how a mixture of char* and const char* arguments would
> be handled in your example.
>
>
> >
> > This can result in cleaner, safer code, without making the calling
> sequence more difficult, or modifying the behavior of the call.
> >
> > For Java developers, this is basically the same type checking provided
> by the as ‘datatype …’ (without the conversion into array).
> >
> > I am Looking for feedback, Pointers on how to implement, as I do not
> have experience with extending gcc.
> >
> > Yair
>

Re: Safer vararg calls

[Florian Weimer]

* Yair Lenga:

> I prefer not to go into “flame wars” on the merits of C vs C++. My
> projects are (mostly) in “C” and I am happy with this setup. In
> addition, given technical / organizational / business issues,
> switching to C++ not an option.

Sure, but you could at least use C++ to prototype the implementation and
even the ABI.

Thanks,
Florian