Re: CVS commit: src/lib/libc

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

joerg@ wrote:

> 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).

Again, how can you support/control/update third party products
not to use deprecated functions?  Our libc is designed for NetBSD?

Anyway, the removal must be handled by Core.

---
Izumi Tsutsui