* Re: Gcc Digest, Vol 29, Issue 7
2022-07-05 7:19 ` Gcc Digest, Vol 29, Issue 7 Yair Lenga
@ 2022-07-05 12:16 ` Florian Weimer
2022-07-05 21:24 ` Yair Lenga
2022-07-05 21:52 ` Gcc Digest, Vol 29, Issue 7 Andrew Pinski
2022-07-06 7:17 ` David Brown
2 siblings, 1 reply; 7+ messages in thread
From: Florian Weimer @ 2022-07-05 12:16 UTC (permalink / raw)
To: Yair Lenga via Gcc; +Cc: Yair Lenga
* 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Gcc Digest, Vol 29, Issue 7
2022-07-05 12:16 ` Florian Weimer
@ 2022-07-05 21:24 ` Yair Lenga
2022-07-07 10:02 ` Safer vararg calls Florian Weimer
0 siblings, 1 reply; 7+ messages in thread
From: Yair Lenga @ 2022-07-05 21:24 UTC (permalink / raw)
To: Florian Weimer; +Cc: Yair Lenga via Gcc
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 <fweimer@redhat.com> 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
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Safer vararg calls
2022-07-05 21:24 ` Yair Lenga
@ 2022-07-07 10:02 ` Florian Weimer
0 siblings, 0 replies; 7+ messages in thread
From: Florian Weimer @ 2022-07-07 10:02 UTC (permalink / raw)
To: Yair Lenga; +Cc: Yair Lenga via Gcc
* 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Gcc Digest, Vol 29, Issue 7
2022-07-05 7:19 ` Gcc Digest, Vol 29, Issue 7 Yair Lenga
2022-07-05 12:16 ` Florian Weimer
@ 2022-07-05 21:52 ` Andrew Pinski
2022-07-06 7:17 ` David Brown
2 siblings, 0 replies; 7+ messages in thread
From: Andrew Pinski @ 2022-07-05 21:52 UTC (permalink / raw)
To: Yair Lenga; +Cc: GCC Mailing List
On Tue, Jul 5, 2022 at 12:21 AM Yair Lenga via Gcc <gcc@gcc.gnu.org> 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
This is all recorded as https://gcc.gnu.org/PR47781 . You could do a
plugin to handle the attribute maybe.
Thanks,
Andrew Pinski
>
> Yair
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Gcc Digest, Vol 29, Issue 7
2022-07-05 7:19 ` Gcc Digest, Vol 29, Issue 7 Yair Lenga
2022-07-05 12:16 ` Florian Weimer
2022-07-05 21:52 ` Gcc Digest, Vol 29, Issue 7 Andrew Pinski
@ 2022-07-06 7:17 ` David Brown
2022-07-06 7:59 ` Yair Lenga
2 siblings, 1 reply; 7+ messages in thread
From: David Brown @ 2022-07-06 7:17 UTC (permalink / raw)
To: Yair Lenga, gcc
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Gcc Digest, Vol 29, Issue 7
2022-07-06 7:17 ` David Brown
@ 2022-07-06 7:59 ` Yair Lenga
0 siblings, 0 replies; 7+ messages in thread
From: Yair Lenga @ 2022-07-06 7:59 UTC (permalink / raw)
To: David Brown; +Cc: gcc
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 <david@westcontrol.com> 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.
^ permalink raw reply [flat|nested] 7+ messages in thread