From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) by sourceware.org (Postfix) with ESMTPS id D38353858D39 for ; Wed, 6 Jul 2022 12:10:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D38353858D39 Received: by mail-vk1-xa2a.google.com with SMTP id d6so861675vko.11 for ; Wed, 06 Jul 2022 05:10:50 -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:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Bma9bDwvplfSSX+H2zUtTpvIf1J1zNwPxmHL0pG30zU=; b=I5Ky4XHY49FJJxvG4q4Cdvt6iOa8hZrtW2aqeiblhF8vUvR6MVa6fvYMHSq6HQNO1J E9eaknVY8eqUBAMGjF6+EmTR6NYB6s9pKKw7Dw7/9Sqh++yT4Dg3GwtSlV3SmAhS7FmV CIDHR57yz5oV0cvF+taTwJWXRjLX9Gw8MDL589bl9SBohXOeVzF9GOO7zjshw28SkA5J LeadgGJzKdDyfEt1RqxgPh2RYkukWM6WpnYscVX5FtdAsnuUfjUuaoD+kjedTjvvmSH7 glxRwa3sk6GOqIbVW+BFwj8+HzSak50cNG+HkJVfIMIqsSoCPnqAxbfFXtNyFgBPUUgs 7M5w== X-Gm-Message-State: AJIora9PJUzGN7EaqWgOZtKkNj7HaJMcdi+5euoeJnToOHlF2y26J7TO On5IWMcOsdfUXiSwt4NYaDYMqUchtOABK2X4 X-Google-Smtp-Source: AGRyM1vA8UsbR/unpR+/GZZa1zG7jT5k6qGos3rWNIm/CBchvK4a0OpziBjqYlbdFWiYfEFywLkVuw== X-Received: by 2002:a1f:24d4:0:b0:374:1e43:2032 with SMTP id k203-20020a1f24d4000000b003741e432032mr3661673vkk.12.1657109450044; Wed, 06 Jul 2022 05:10:50 -0700 (PDT) Received: from smtpclient.apple ([2804:431:c7cb:fef6:c4a4:5cf:6a9a:8440]) by smtp.gmail.com with ESMTPSA id r23-20020ab03317000000b00370fe98f896sm8757753uao.7.2022.07.06.05.10.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jul 2022 05:10:49 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: Re: Buffer size checking for scanf* functions From: Adhemerval Zanella In-Reply-To: Date: Wed, 6 Jul 2022 09:10:47 -0300 Cc: libc-help@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Yair Lenga X-Mailer: Apple Mail (2.3696.100.31) X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2022 12:10:53 -0000 > On 5 Jul 2022, at 18:50, Yair Lenga wrote: >=20 >=20 >>=20 >> Adhemerval, >=20 > Thanks for taking time to review my posting. >=20 > I agree 100% with the critic on annex K. I believe there is (almost) = universal agreement that it was half baked solution, rushed into the = standard without proper review - which is why it got very little = traction. >=20 > However, the fact the the annex K has many flaws does not mean that = there are no good ideas in it. In particular, the ability to create = =E2=80=9Csafer=E2=80=9D vararg lists for atomic types, and use them in = scanf* and similar, is significant improvement (IHMO). I believe it = improve safety, while keeping code clean, readable, and can be used for = many use cases (e.g., my scanf from a result set, parsing csv-like data, = =E2=80=A6). >=20 > Also worth mentioning that one mentioned alternative (OBS - object = size checking) can fit into the proposed scanf change, given it ability = to identify object sizes for static/dynamic char *. >=20 > Hoping to get feedback on my proposal for this limited use case. >=20 > Also, regarding the proposal for using stringifying macros, etc. Those = are interesting ideas, but will break code clarity/readability . They = Will not fit nicely into large scale projects, given their limitation = (e.g. with dynamic size strings, etc.) >=20 > Thanks again for your time/ideas/feedback, The main issue of extending standard interfaces with non standard=20 functionality is the burden of keeping compatibility over releases. =20 The scanf family itself requires glibc to provide multiple symbols to handle C99, originally on glibc =E2=80=98a=E2=80=99 was synonymous of = =E2=80=98m=E2=80=99 and=20 the C standard defines =E2=80=98a=E2=80=99 to being synonymous of = =E2=80=98f=E2=80=99. It means that for -std=3Dc99 glibc does a symbol redirection to a different one to handle this difference. If we add another non standard extension it might require extra additional handling in the future if C or POSIX reassign the conversion modifier to something else. We can follow the scanf_s idea and handle c, s, and [ conversion as a pair or argument. This will need also another symbol redirection (since this interface is not compatible with standard scanf family) and to export multiple new symbols. I don=E2=80=99t have a a strong opinion, but if the idea is to add such=20= extensions I think it would require some more discussion to avoid=20 the scanf_s mistakes and maybe add some useful extension like to handle non standard types supported by GCC (like int128 and float128). It also has the drawback to be an ad-hoc solution that will be eventually phase out if standard ended up provide simila functionality I really think using current standard %m is really a much better=20 approach than trying to extending scanf to use fixed sizes buffers. It does dynamic allocation, but since your idea is to use dynamic size strings anyway it might fit.=