svn commit: r351659 - in head: contrib/libc++/include contrib/netbsd-tests/lib/libc/ssp gnu/lib/libssp include lib/libc/stdio

[Conrad Meyer]

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