From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) by sourceware.org (Postfix) with ESMTPS id B92513852760 for ; Tue, 5 Jul 2022 21:52:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B92513852760 Received: by mail-lf1-x12d.google.com with SMTP id z13so22754001lfj.13 for ; Tue, 05 Jul 2022 14:52:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1lVAlHDYrqyAqYrJ5BYd7FrYKNwaqhz8TTmKkTulZOI=; b=LfOcE6GIDvJcj1V8o3KlUZnVuLeap/5gfVBGSg9FAbwTCS4wG49hBPX6kYtfy0ajIp NAUy1N27r7of4Dc9Hnk5tn/6qZKfr/w6llsuBMQfheedr8LFx/cxQ4KkSr3K6T9eDYbg qC2ZQsGY2y1QzPLKlCdT9KKuzxkoUnNjUtId6qm6771y4M9henfD+fgFR2zA4iWzFMgr wkGHqFFQKFk4ZIsA5WF6boI4zNaTfiv/swKX8YfFpoqM6mJfBWRw0NWT/WJLOZFZxc5q PL7tZUNNu+sb1oYDwhTmWcWW5ObMadGpH1dYSDT1gFBWswikvvKGunHJMvZZTljOblkV RgVw== X-Gm-Message-State: AJIora9+JcwvzUSgS4+e6Ju5DRxacJZupXwgb2mAdhZHqALKV0Gc0XhY glAzcwFzFu6zXNaS0D8OENzU2TIQl+LyHMCgRvg= X-Google-Smtp-Source: AGRyM1uHjre0dUzioBOm6LAI1Z+L21AypnA2xQ2WnI+nxrfjajP/4tx7CQZPUx7ZbDKG2LjbsheeY1P4tXQRx+6LS4w= X-Received: by 2002:a05:6512:2255:b0:47f:6591:354b with SMTP id i21-20020a056512225500b0047f6591354bmr25573920lfu.191.1657057941040; Tue, 05 Jul 2022 14:52:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andrew Pinski Date: Tue, 5 Jul 2022 14:52:09 -0700 Message-ID: Subject: Re: Gcc Digest, Vol 29, Issue 7 To: Yair Lenga Cc: GCC Mailing List Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_NUMSUBJECT, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2022 21:52:24 -0000 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, &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