public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Yair Lenga <yair.lenga@gmail.com>
To: gcc@gcc.gnu.org
Subject: Re: Gcc Digest, Vol 29, Issue 7
Date: Tue, 5 Jul 2022 10:19:59 +0300	[thread overview]
Message-ID: <CAK3_KpNqaea8U+N+5Z=i+-wrEzoryhXCaEnkjsWCzOeWiYcQtQ@mail.gmail.com> (raw)
In-Reply-To: <mailman.0.1656936003.1843426.gcc@gcc.gnu.org>

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

       reply	other threads:[~2022-07-05  7:20 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.0.1656936003.1843426.gcc@gcc.gnu.org>
2022-07-05  7:19 ` Yair Lenga [this message]
2022-07-05 12:16   ` Florian Weimer
2022-07-05 21:24     ` Yair Lenga
2022-07-07 10:02       ` Safer vararg calls 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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAK3_KpNqaea8U+N+5Z=i+-wrEzoryhXCaEnkjsWCzOeWiYcQtQ@mail.gmail.com' \
    --to=yair.lenga@gmail.com \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).