Re: Gcc Digest, Vol 29, Issue 7
Thanks for suggestion, definitely doable, more verbose vs the scanf, but will do the trick. I will use it as my fallback, if no path with my current approach. Yair. Sent from my iPad > On Jul 6, 2022, at 10:17 AM, David Brown wrote: > > 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.
Re: Gcc Digest, Vol 29, Issue 7
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, _var, _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", _var, _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.
Re: Gcc Digest, Vol 29, Issue 7
On Tue, Jul 5, 2022 at 12:21 AM 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, _var, _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", _var, _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 This is all recorded as https://gcc.gnu.org/PR47781 . You could do a plugin to handle the attribute maybe. Thanks, Andrew Pinski > > Yair
Re: Gcc Digest, Vol 29, Issue 7
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. Yair. Sent from my iPad > On Jul 5, 2022, at 3:16 PM, Florian Weimer wrote: > > * Yair Lenga via Gcc: > >> 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. > > It's already possible to do this with C++. Can't you just use C++ > instead? > > Thanks, > Florian >
Re: Gcc Digest, Vol 29, Issue 7
* Yair Lenga via Gcc: > 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. It's already possible to do this with C++. Can't you just use C++ instead? Thanks, Florian
Re: Gcc Digest, Vol 29, Issue 7
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, _var, _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", _var, _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
