Date: Sun, 01 Sep 2019 20:36:53 -0700 From: Cy Schubert <Cy.Schubert@cschubert.com> To: cem@freebsd.org Cc: Cy Schubert <Cy.Schubert@cschubert.com>, 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: <201909020336.x823ar42054344@slippy.cwsent.com> In-Reply-To: <CAG6CVpW4Mj-w7SeB=nu7MHiH%2BgvkMeB9v8ojLgpnrvmN0Oo%2Bgg@mail.gmail.com> References: <201909011612.x81GC5DW097846@repo.freebsd.org> <201909011932.x81JWYts004074@slippy.cwsent.com> <CAG6CVpVMN6BkATaz7qqhaVHhUpqQLrP3kSWHpMzPz2AR5GnaQw@mail.gmail.com> <201909012223.x81MN7jK005967@slippy.cwsent.com> <CAG6CVpW4Mj-w7SeB=nu7MHiH%2BgvkMeB9v8ojLgpnrvmN0Oo%2Bgg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <CAG6CVpW4Mj-w7SeB=nu7MHiH+gvkMeB9v8ojLgpnrvmN0Oo+gg@mail.gmail.c om> , Conrad Meyer writes: > Hi Cy, > > On Sun, Sep 1, 2019 at 3:23 PM Cy Schubert <Cy.Schubert@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(). If Microsoft chooses to ignore or anotherfunctions is their problem. However in this case, according to the following they do support gets_s(). https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/gets-s-getw s-s?view=vs-2019 Having said all that, glibc is the odd man out here. In that case I'll pull back my horns. It's sufficient not to not say anything or to highlight both. BTW. we've had gets_s(3) in our tree for 17 months now. We don't need to add anything. It's already there. It is an application developer choice to use one function or another. As someone who also works on the ports side, the newline is significant distinction. As gets_s() is closer in function to gets() than fgets() is, all one needs to concern oneself with is buffer length. As there are no _other_ differences nothing else needs to be addressed. This is important to ports maintainers and who must replace gets() with something else. Agreed this shouldn't be an issue every time but gets_s() is still in our toolbox. > > (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?) I totally agree. > > > 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. That's where gets_s() is handy. It requires less analysis. Remember, my main concern here are our ports maintainers. Upstream developers should always do analysis. It's not the job of the ports team to perform significant rewrites of upstream software. IMO, if upsteam software needs significant rewrite a port maintainer should notify the upstream maintainer. If the upstream cannot or will not, requiring a maintainer of a port to make significant changes, DEPRECATED= and EXPIRATION_DATE= are the best answer. We are not here to rewrite other people's software for them. > > 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. I'm not arguing for keeping gets(3). We already have gets_s(3). Let's use it where it makes sense. Nor am I saying to use it in exclusion of fgets(3). It (gets_s()) is in our libc. If it eases the job of maintaining a port, use it instead. > > > [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. Microsoft and we have chosen to implement some Annex K functions. We haven't implemented all of them. I don't know if they implemented all _s functions. Linux glibc has not. I don't agree that it's a completely bad set of APIs. gets_s() will help ports maintainers. AFAIK, no ports rely on gets() but that's not to say some new port might not. Don't forget, my motivation for implementing gets_s(3) in libc was to ease the pain of deprecating gets() for ports. > > > 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.) Again I disagree. > > [1]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm (pro-removal) This explains glibc's not implementing the _s functions. His focus is almost entirely on string copy and memory copy functions. Implementation of string and memory copy functions would be more complex than the gets_s() I added to FreeBSD. In terms of error detection (for calls to constraint handlers), gets_s() is simple compared to strcpy_s(). I can understand his issues. It would appear a similar lack of consideration of implementation details went into defining the _s string functions as the lack of consistency considerations went into the development of gets() and fgets(). https://en.cppreference.com/w/c/string/byte/strcpy, where clobbring the rest of the destination is IMO "not optimal." Throwing out the baby (functions which were properly defined) with the bath water (functions which make one wonder what they were smoking) isn't the right answer either. > [2]: https://www.nccgroup.trust/us/our-research/bounds-checking-interfaces-fi > eld-experience-and-future-directions/ > (pro-retention) I don't have time to read completely through all of this tonight. The assertion that there are unfounded criticisms as well as actual flaws. The flaws are such that replacing some functions with _s will require some care. Fortunately with gets_s() this is not a concern, except of course having to specify a buffer length. A constraint handler is not required. IMO constraint handlers add unnecessary complexity, good thing they are optional. > > > 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. Already did. Should someone choose to fix them we the tools are there. I doubt you will convince me nor I convince you. I'm not sure if you or anyone else has a copy of the standard. (I suspect you already have these but maybe someone else might find them useful.) http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3631.pdf > > Best, > Conrad > -- Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201909020336.x823ar42054344>