From owner-svn-src-all@freebsd.org Mon Sep 2 00:38:00 2019 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D6641CBB42; Mon, 2 Sep 2019 00:38:00 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-io1-f53.google.com (mail-io1-f53.google.com [209.85.166.53]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46MB535PvXz43Q7; Mon, 2 Sep 2019 00:37:59 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-io1-f53.google.com with SMTP id d25so23370691iob.6; Sun, 01 Sep 2019 17:37:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=ei3QaA6s06OJ92IO/j5C+VMM0RTCVlQV1PvI1PcMBgE=; b=KD0ri9DCznik0StD28nrkiYcq1jHDPi2Rm2MAYUyLCPvHq1xQlehOP7X1g/zIM1SAh lEN7fVB/kpLZU0a3EQoM9h8JekOCBzW97fqWdN7+MyPWrqwsfcHwWXz17C2t8j1DMH7e PxBjJLVA0djGMoRgM6YK3Y3if7Nt5rEcG6sZaug3T3xyNWA736zi+J6ip51nxDxNhPZr LbNWcSKoZXljhw8r9/2EGgPAP4zrxKq7KHa9bZ3GLeJSDmeMkNS7+9TtxdG6HGhYiKQD QBFhpb0fk+D940q3Vln6msqpL9CzsPS+Rh1KkOLu6bJU+bVUUf1pU+4fjazU2Shy9ezF P5dw== X-Gm-Message-State: APjAAAV/KkVV3MY7yrK/BexI8oAGTCsnfEDez1Pze+9ltub3ZJrmxCO4 t/pZdwjOMZaA/ibqSduyFvucthTP X-Google-Smtp-Source: APXvYqxnKQ8sULferXkEvzI5vAS203iBasHX3NKJEH0Y5/py65EdJNAHfIlInoaxv+YTWh0+0aaUsA== X-Received: by 2002:a02:698d:: with SMTP id e135mr1165001jac.128.1567384678109; Sun, 01 Sep 2019 17:37:58 -0700 (PDT) Received: from mail-io1-f43.google.com (mail-io1-f43.google.com. [209.85.166.43]) by smtp.gmail.com with ESMTPSA id k66sm4580859iof.25.2019.09.01.17.37.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 01 Sep 2019 17:37:57 -0700 (PDT) Received: by mail-io1-f43.google.com with SMTP id b136so1763768iof.3; Sun, 01 Sep 2019 17:37:57 -0700 (PDT) X-Received: by 2002:a5e:8d0a:: with SMTP id m10mr313413ioj.231.1567384677562; Sun, 01 Sep 2019 17:37:57 -0700 (PDT) MIME-Version: 1.0 References: <201909011612.x81GC5DW097846@repo.freebsd.org> <201909011932.x81JWYts004074@slippy.cwsent.com> <201909012223.x81MN7jK005967@slippy.cwsent.com> In-Reply-To: <201909012223.x81MN7jK005967@slippy.cwsent.com> Reply-To: cem@freebsd.org From: Conrad Meyer Date: Sun, 1 Sep 2019 17:37:46 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r351659 - in head: contrib/libc++/include contrib/netbsd-tests/lib/libc/ssp gnu/lib/libssp include lib/libc/stdio To: Cy Schubert Cc: src-committers , svn-src-all , svn-src-head Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 46MB535PvXz43Q7 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of csecem@gmail.com designates 209.85.166.53 as permitted sender) smtp.mailfrom=csecem@gmail.com X-Spamd-Result: default: False [-4.74 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[cem@freebsd.org]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.987,0]; FORGED_SENDER(0.30)[cem@freebsd.org,csecem@gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[cem@freebsd.org,csecem@gmail.com]; TAGGED_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[53.166.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.75)[ip: (-3.05), ipnet: 209.85.128.0/17(-3.34), asn: 15169(-2.31), country: US(-0.05)]; RWL_MAILSPIKE_POSSIBLE(0.00)[53.166.85.209.rep.mailspike.net : 127.0.0.17]; RCVD_TLS_ALL(0.00)[] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2019 00:38:00 -0000 Hi Cy, On Sun, Sep 1, 2019 at 3:23 PM Cy Schubert wrot= e: > > In message om> > , Conrad Meyer writes: > > > Short version: no, we shouldn't [recommend the use of gets_s]. :-) > > > > Longer version: Annex K functions like gets_s have zero real adoption > > (Microsoft's APIs that inspired Annex K are not actually compatible > > with the version in the standards); broadly terrible APIs; and in this > > particular case and others, unnecessarily duplicate the functionality > > of existing long-standing standard C functions (e.g., fgets(3)). > > That's not quite true. From the man page: > > The gets_s() function is equivalent to fgets() with a stream of stdi= n, > except that the newline character (if any) is not stored in the stri= ng. I tried to make a distinction earlier that I don't think carried well over email. I wrote "unnecessarily duplicate(s) the _functionality_ of existing =E2=80=A6" =E2=80=94 not "is/are an exact duplicate(s) of =E2= =80=A6" =E2=80=94 because you're right, gets_s() has (trivial) behavioral differences from fgets(stdin). The thing that is important to me is that fgets(3) is portable, super well understood, and provides a superset of the functionality of gets_s(). One can easily construct the newline-free version of a line from one containing a trailing newline. I don't think this slight behavioral difference justifies implementing, using, or especially recommending gets_s(). (IMO, it was probably a historical mistake that gets(3) even had different behavior than fgets(3) to begin with. gets(3) maybe predated stdio FILE streams?) > Some apps may be sensitive to this subtle difference. gets_s() preserves > this behaviour. Correct conversion of gets()-using programs requires more analysis than blind replacement with either function. Anyway, gets() use is largely behind us so the point is mostly moot =E2=80= =94 there are few such programs to convert, and they should be viewed with an extremely high level of skepticism given they are still using gets(3) in 2019. > [Annex K functions] are part of the > standard They're an optional part of the standard. Everyone takes the option of "not." Literally no one implements Annex K. It's a bad set of APIs. > and though we support some _s functions it would behoove us to one > day (*) support them all. If and when the C standard committee adopts Annex K as a required part of the standard, then I agree we should make every attempt to support the full standard library. But in general, I am opposed to the further adoption of Annex K, and hope the C2x standard committee finally drops the annex.[1] (It is weakly defended[2], just to provide a counterargument.) [1]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm (pro-remova= l) [2]: https://www.nccgroup.trust/us/our-research/bounds-checking-interfaces-= field-experience-and-future-directions/ (pro-retention) > I'm also sure some ports will probably break. Check the exp-run PR: 222796 (comment #7). 13 ports. Out of 37601, according to FreshPorts. Of those 13, eight don't have a maintainer. Best, Conrad