Re: Gcc Digest, Vol 29, Issue 7

[David Brown <david@westcontrol.com>]

On 05/07/2022 09:19, Yair Lenga via Gcc wrote:
> Hi,
> 
> Wanted to get some feedback on an idea that I have - trying to address the
> age long issue with type check on VA list function - like 'scanf' and
> friends. In my specific case, I'm trying to build code that will parse a
> list of values from SELECT statement into list of C variables. The type of
> the values is known (by inspecting the result set meta-data). My ideal
> solution will be to implement something like:
> 
> int result_set_read(struct result_set *p_result_set, ...);
> 
> Which can be called with
> 
> int int_var ; float float_var ; char c[20] ;
> result_set_read(rs1, &int_var, &float_var, c) ;
> 
> The tricky part is to verify argument type - make sure . One possible path
> I thought was - why not leverage the ability to describe scanf like
> functions (
> result_set_read(rs1, const char *format, ...) __attribute((format (scanf,
> 2, 3)) ;
> 
> And then the above call will be
> result_set-read(rs1, "%d %f %s", &int_var, &float_var, c) ;
> 
> With the added benefit that GCC will flag as error, if there is mismatch
> between the variable and the type. My function parses the scanf format to
> decide on conversions (just the basic formatting '%f', '%d', '%*s', ...).
> So far big improvement, and the only missing item is the ability to enforce
> check on string sizes - to support better checks against buffer overflow
> (side note: wish there was ability to force inclusion of the max string
> size, similar to the sscanf_s).
> 
> My question: does anyone know how much effort it will be to add a new GCC
> built-in (or extension), that will automatically generate a descriptive
> format string, consistent with scanf formatting, avoiding the need to
> manually enter the formatting string. This can be thought of as "poor man
> introspection". Simple macro can then be used to generate it
> 
> #define RESULT_SET_READ(rs, ...) result_set_read(rs,
> __builtin_format(__VA_ARGS__),  __VA_ARGS__)
> 
> Practically, making the function "safe" (with respect to buffer overflow,
> type conversions) for most use cases.
> 
> Any feedback, pointers, ... to how to implement will be appreciated
> 
> Yair
> 

I haven't worked through all the details, but I wonder if this could be 
turned around a bit.  Rather than your function taking a variable number 
of arguments of different types, which as you know can be a risky 
business, have it take an array of (type, void*) pairs (where "type" is 
an enumeration).  Use some variadic macro magic to turn the 
"RESULT_SET_READ" into the creation of a local array that is then passed 
on to the function.