From owner-svn-src-all@freebsd.org Sun Sep 1 22:23:14 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 1EA8DC8275; Sun, 1 Sep 2019 22:23:14 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 46M75Y4k3vz3RF4; Sun, 1 Sep 2019 22:23:13 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id 4YFZib1yAUIS24YFai9N2C; Sun, 01 Sep 2019 16:23:11 -0600 X-Authority-Analysis: v=2.3 cv=N41X6F1B c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=J70Eh1EUuV4A:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=2QSLavsyAAAA:8 a=3JZJobP_s7psWMEtP5AA:9 a=CjuIK1q_8ugA:10 a=UJ0tAi3fqDAA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=9H_80fVQ3bbXSWzY4Kdq:22 a=Z5ABNNGmrOfJ6cZ5bIyy:22 a=jd6J4Gguk5HxikPWLKER:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 74AA473F; Sun, 1 Sep 2019 15:23:07 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id x81MN7aP005970; Sun, 1 Sep 2019 15:23:07 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id x81MN7jK005967; Sun, 1 Sep 2019 15:23:07 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201909012223.x81MN7jK005967@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: cem@freebsd.org cc: Cy Schubert , src-committers , svn-src-all , svn-src-head Subject: Re: svn commit: r351659 - in head: contrib/libc++/include contrib/netbsd-tests/lib/libc/ssp gnu/lib/libssp include lib/libc/stdio In-reply-to: References: <201909011612.x81GC5DW097846@repo.freebsd.org> <201909011932.x81JWYts004074@slippy.cwsent.com> Comments: In-reply-to Conrad Meyer message dated "Sun, 01 Sep 2019 14:20:58 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 01 Sep 2019 15:23:07 -0700 X-CMAE-Envelope: MS4wfL26JoVKDNHjvoab91s1STefOGHY25ZCMZkcfA7rb5i0JC/JzSYhMtHgWlnL/cZushTkr5T0BGEggn37Uilu47K/qYPYam7qDzQ7d/bqxpYIBCGZt7Ue C3lAA6iPHQbqKcGnaqXZATfooNcBSNSxOvVdx9gBt7W6+inaXYR4J809FAqP/rN+llD4E6iJBnDPninP8/nJKEM6+Ra7vxQwPXNJwqEUQ5/wXEMgKuW1ASRG cPjWbIjO3r8u4hg8v1KtXC7aln8SWVV7KpSyFZ3bv0zTSPamb53ePXb3pQJ3E1Wg X-Rspamd-Queue-Id: 46M75Y4k3vz3RF4 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.95 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.95)[-0.947,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.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: Sun, 01 Sep 2019 22:23:14 -0000 In message , Conrad Meyer writes: > On Sun, Sep 1, 2019 at 12:32 PM Cy Schubert wrote > : > > In message <201909011612.x81GC5DW097846@repo.freebsd.org>, Ed Maste writes: > > > Author: emaste > > > Date: Sun Sep 1 16:12:05 2019 > > > New Revision: 351659 > > > URL: https://svnweb.freebsd.org/changeset/base/351659 > > > > > > Log: > > > libc: remove gets > > > ... > > > > Should we encourage the use of gets_s() in the man page or in other doc? > > Hi Cy, > > Short version: no, we shouldn't. :-) > > 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 stdin, except that the newline character (if any) is not stored in the string. See: https://en.cppreference.com/w/c/io/gets https://en.cppreference.com/w/c/io/fgets Some apps may be sensitive to this subtle difference. gets_s() preserves this behaviour. > > Also, it's been a *long* time since gets(3) was known to be extremely > broken and rejected by -D_FORTIFY_SOURCE and friends; at least twenty > years just going by the C99 standard. I don't think developers need > an advisory about using alternatives to gets(3) at this point in time. It's not an advisory to highlight the _s function. They are part of the standard and though we support some _s functions it would behoove us to one day (*) support them all. I'm also sure some ports will probably break. Encouraging the use of gets_s() over fgets() due to this difference may avoid bugs in software that rely in the subtle difference. * One day doesn't mean we do it tomorrow but over time is desireable. > > Best, > Conrad -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.