Re: CVS commit: src/lib/libc

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Fri, Mar 02, 2012 at 12:10:26AM +0900, Izumi Tsutsui wrote:
> joerg@ wrote:
> 
> > On Thu, Mar 01, 2012 at 07:35:02PM +0900, Izumi Tsutsui wrote:
> > > yamt@ wrote:
> > > 
> > > > > Module Name:  src
> > > > > Committed By: dholland
> > > > > Date:         Fri Feb 24 16:06:39 UTC 2012
> > > > > 
> > > > > Modified Files:
> > > > >       src/lib/libc: shlib_version
> > > > > 
> > > > > Log Message:
> > > > > Note that gets() is finally dead in C11 and can be removed if we ever
> > > > > bump libc.
> > > > 
> > > > it doesn't sound good or realistic to me.
> > > 
> > > Indeed.  Can you please remove this entry?
> > > 
> > > Removing use of deprecated functions in NetBSD tree is the right thing,
> > > but it doesn't mean stopping C89/C99 support in NetBSD environment.
> > > Having __warn_references() for such functions is enough for users.
> > 
> > I disagree on this. gets(3) is actively harmful, so moving it into
> > libcompat sounds perfectly sane.
> 
> How can you support/control/update third party products
> not to use deprecated functions?
> 
> Are you claiming NetBSD should ignore such silly applications,
> while you are also blaming ISO C11 *_s functions suck? ;-p
> 
> In libc implementaion, we should consider support of STANDARD
> (including compat support) first, before individual design issue.

Code that is using gets(3) is almost always broken. It doesn't just
suck, it is plainly broken. There are a bunch of other functions that
have been removed by POSIX2008 like index(3), which are a bit harder to
argue about. There is still code using them and they are not broken, so
moving them out of the normal namespace into a legacy namespace
and only providing the prototypes (with __RENAME) if actively requested
is fine. But there is basically no legitamate reason for using gets(3).

Joerg