From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) by sourceware.org (Postfix) with ESMTPS id 751CA385841A for ; Tue, 5 Jul 2022 21:50:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 751CA385841A Received: by mail-ej1-x633.google.com with SMTP id sb34so23848747ejc.11 for ; Tue, 05 Jul 2022 14:50:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:message-id:date:cc:to; bh=Vh0Tifz2rLIvVqN0iOVLV9ZTE7qcy5e7w2zvHZKiLQY=; b=K1YfzdgHH+ifPerMSDYjVf8IJKdJisDpn7+DDvuQORdgqVo/Sz+WqAoQ8wEgVdP5t3 Ocf/mJCIotINjtgbPwK5u5l66ytMJZ/ustXgxDxkH4zFcWnXES/bQ7wDo0ajW6hAQpYA 2inqxgRGbuIvTteXPiugwvJY+8CF9QokVSD/Zh9LAZRYNslVs3qxi8RVDYL2m7kL/zrt svm3EwVBeIKTSWipKyyOWJY2OpBsSzz3vkRBAVTwCJ+wkoO4Unp94EBGiiu/Rj5kuCkl do3UEtTdYKWE+cNEZHDCzF45qCHyxhbm+Ls2TpbrOVN2+JYrtb14zHBjUHgbFQwv/zcE R7Tw== X-Gm-Message-State: AJIora8ZyCOvDfHlASb44hStyHOPb2SQkFqV5c4kHreCLACePrmaNiqq LOQb+jFHH3uEcgi4uAWfKZMx4D2hK1D8xw== X-Google-Smtp-Source: AGRyM1swiyGFeQl7RM8F0t186VLEle+TuD1By4kq2IPwlXos2n0ooV7o1/ig3Cj4uYg5KTyR81laEw== X-Received: by 2002:a17:907:8a25:b0:726:c9f2:2f5e with SMTP id sc37-20020a1709078a2500b00726c9f22f5emr35316202ejc.286.1657057836287; Tue, 05 Jul 2022 14:50:36 -0700 (PDT) Received: from smtpclient.apple (85.65.72.155.dynamic.barak-online.net. [85.65.72.155]) by smtp.gmail.com with ESMTPSA id m9-20020a509989000000b004355d27799fsm24743486edb.96.2022.07.05.14.50.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Jul 2022 14:50:35 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Yair Lenga Mime-Version: 1.0 (1.0) Subject: Re: Buffer size checking for scanf* functions Message-Id: Date: Wed, 6 Jul 2022 00:50:34 +0300 Cc: libc-help@sourceware.org To: Adhemerval Zanella X-Mailer: iPad Mail (19F77) X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, 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: Tue, 05 Jul 2022 21:50:39 -0000 =EF=BB=BF >=20 > Adhemerval, Thanks for taking time to review my posting. I agree 100% with the critic on annex K. I believe there is (almost) univers= al agreement that it was half baked solution, rushed into the standard witho= ut proper review - which is why it got very little traction. However, the fact the the annex K has many flaws does not mean that there ar= e 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 c= ode 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). Also worth mentioning that one mentioned alternative (OBS - object size chec= king) can fit into the proposed scanf change, given it ability to identify o= bject sizes for static/dynamic char *. Hoping to get feedback on my proposal for this limited use case. Also, regarding the proposal for using stringifying macros, etc. Those are i= nteresting ideas, but will break code clarity/readability . They Will not fi= t nicely into large scale projects, given their limitation (e.g. with dynami= c size strings, etc.) Thanks again for your time/ideas/feedback, Yair Sent from my iPad > On Jul 5, 2022, at 3:39 PM, Adhemerval Zanella wrote: > The glibc does not support hooks for scanf and I don=E2=80=99t think we wi= ll even > will, the printf hooks itself has some drawbacks (MT-safeness, etc.). Als= o > scan_s and similar =E2=80=98enhanced=E2=80=99 functions from TR-24731 have= not been widely=20 > implemented mainly because they do not actually improve much. Carlos and > Martim, both GNU developers, wrote a paper discussing the problems with > these interfaces [1].