svn commit: r351659 - in head: contrib/libc++/include contrib/netbsd-tests/lib/libc/ssp gnu/lib/libssp include lib/libc/stdio
Conrad Meyer
cem at freebsd.org
Mon Sep 2 00:38:00 UTC 2019
Hi Cy,
On Sun, Sep 1, 2019 at 3:23 PM Cy Schubert <Cy.Schubert at cschubert.com> wrote:
>
> In message <CAG6CVpVMN6BkATaz7qqhaVHhUpqQLrP3kSWHpMzPz2AR5GnaQw at 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
More information about the svn-src-all
mailing list