Hi Cy, On Sun, Sep 1, 2019 at 3:23 PM Cy Schubert <cy.schub...@cschubert.com> wrote: > > In message <CAG6CVpVMN6BkATaz7qqhaVHhUpqQLrP3kSWHpMzPz2AR5GnaQw@mail.gmail.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 stdin, > except that the newline character (if any) is not stored in the string.
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 …" — not "is/are an exact duplicate(s) of …" — 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 — 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-removal) [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 _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
