Date: Sun, 1 Sep 2019 17:37:46 -0700 From: Conrad Meyer <cem@freebsd.org> To: Cy Schubert <Cy.Schubert@cschubert.com> Cc: src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r351659 - in head: contrib/libc++/include contrib/netbsd-tests/lib/libc/ssp gnu/lib/libssp include lib/libc/stdio Message-ID: <CAG6CVpW4Mj-w7SeB=nu7MHiH%2BgvkMeB9v8ojLgpnrvmN0Oo%2Bgg@mail.gmail.com> In-Reply-To: <201909012223.x81MN7jK005967@slippy.cwsent.com> References: <201909011612.x81GC5DW097846@repo.freebsd.org> <201909011932.x81JWYts004074@slippy.cwsent.com> <CAG6CVpVMN6BkATaz7qqhaVHhUpqQLrP3kSWHpMzPz2AR5GnaQw@mail.gmail.com> <201909012223.x81MN7jK005967@slippy.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Cy, On Sun, Sep 1, 2019 at 3:23 PM Cy Schubert <Cy.Schubert@cschubert.com> wrot= e: > > In message <CAG6CVpVMN6BkATaz7qqhaVHhUpqQLrP3kSWHpMzPz2AR5GnaQw@mail.gmai= l.c > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG6CVpW4Mj-w7SeB=nu7MHiH%2BgvkMeB9v8ojLgpnrvmN0Oo%2Bgg>