From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x112b.google.com (mail-yw1-x112b.google.com [IPv6:2607:f8b0:4864:20::112b]) by sourceware.org (Postfix) with ESMTPS id 67F0B385828E for ; Tue, 5 Jul 2022 07:20:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 67F0B385828E Received: by mail-yw1-x112b.google.com with SMTP id 00721157ae682-31c89111f23so49569257b3.0 for ; Tue, 05 Jul 2022 00:20:11 -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; bh=2tAZkOkLxRPz1XgFzBl5z+WnnSuh/8FxmCfA0RnKWCk=; b=pt4x+qdNq4RdwL2TqLodA4xQeqs/FwqGfOpHBteqh9TBJKF1FjxwAag4m1KqKY6GhB d6BazJRnvD2/9oqVYUDe7IpiY8iKM8GdaRgqQvlIxC37b1imqZRqGc3OdPuaUxRXC2qK mO4z5sDntcU3C/o/oIgERL6bwruPmrGraUrhvWZL3r0zTCTIGZ9W3J6wMj6xS6lVMGd2 MzGOpPzr9X89YocDY+Mro9WcdoHADUq5VGUPlm6U3wuxXRyyIQrgPOARTVbcdTzsMxD7 BGczpMWPEb07PwT3bxMxlUs1yID/swIPSzt2pZ1Rt5q9kE9Rs0roxm0EdBzu61joO8Bc hxwA== X-Gm-Message-State: AJIora/QQKAha50A5xw6+6QwRXsL8bc3xhKToDOTchcCTIvE2qIU666a OPbLBujCmiQ0xmzX6NXoMVGwp3ngv/uqVKXyDEympfLSmT4= X-Google-Smtp-Source: AGRyM1uQJrgnW1B/t5JRs9bKiDF7FnHz3/Kwpy4xa3EEw0FJOI5IS4C2b1+B6y1woWjZZq/PxOfaDeVZ62rafl1uLik= X-Received: by 2002:a0d:d586:0:b0:31c:97f5:e7ba with SMTP id x128-20020a0dd586000000b0031c97f5e7bamr10621298ywd.186.1657005610513; Tue, 05 Jul 2022 00:20:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yair Lenga Date: Tue, 5 Jul 2022 10:19:59 +0300 Message-ID: Subject: Re: Gcc Digest, Vol 29, Issue 7 To: gcc@gcc.gnu.org X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, KAM_NUMSUBJECT, 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 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 07:20:13 -0000 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