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
