Re: CVS commit: src/lib/libc
hi, 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. YAMAMOTO Takashi To generate a diff of this commit: cvs rdiff -u -r1.228 -r1.229 src/lib/libc/shlib_version Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/lib/libc
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. --- Izumi Tsutsui
Re: CVS commit: src/lib/libc
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. Joerg
Re: CVS commit: src/lib/libc
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. --- Izumi Tsutsui
Re: CVS commit: src/lib/libc
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
Re: CVS commit: src/lib/libc
Code that is using gets(3) is almost always broken. It doesn't just No argument there, but that's not the question. The questions are should NetBSD provide a compliant C99 environment? (obviously yes) is moving gets(3) to libcompat consistent with the above (it seems not, since your goal seems to be to force other people to make changes because you don't like what they are doing) should NetBSD be in the business of making it difficult to do things which are bad practice? (Here I would say warnings are fine, and that standards compliance is more important.) pgpedoZHN3TCz.pgp Description: PGP signature
Re: CVS commit: src/lib/libc
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
Re: CVS commit: src/lib/libc
On Thu, Mar 01, 2012 at 10:37:39AM -0500, Greg Troxel wrote: Code that is using gets(3) is almost always broken. It doesn't just No argument there, but that's not the question. The questions are should NetBSD provide a compliant C99 environment? (obviously yes) is moving gets(3) to libcompat consistent with the above (it seems not, since your goal seems to be to force other people to make changes because you don't like what they are doing) should NetBSD be in the business of making it difficult to do things which are bad practice? (Here I would say warnings are fine, and that standards compliance is more important.) So provide the trivial wrapper for fgets when compiled with -ansi -pedantic. If there is no way to determine if -pedantic was present, we might need to fix that. The important thing here is that using gets(3) is not bad practice, it is plainly a bug. Using strcpy without checking the string length first is bad practise. *But* strcpy can be used safely and even without explicit checks, it can be correct, e.g. if the programmer does ensure that the buffer limits are correct by other means. On the other hand, there is no way to use gets(3) without mandating line lengths on the input, so in effect, it can't be used correctly. It is just as simple as that. My strong dislike of *_s from C11 is not relevant. Those functions are not part of the core standard, but an (optional) annex. Joerg
Re: CVS commit: src/distrib/utils/sysinst
Am 01.03.12 17:31, schrieb Izumi Tsutsui: Module Name: src Committed By:mbalmer Date:Thu Mar 1 16:22:16 UTC 2012 Modified Files: src/distrib/utils/sysinst: msg.mbr.de msg.mbr.en msg.mbr.es msg.mbr.fr msg.mbr.pl msg.mi.de msg.mi.en msg.mi.es msg.mi.fr msg.mi.pl src/distrib/utils/sysinst/arch/arc: msg.md.en src/distrib/utils/sysinst/arch/atari: msg.md.de msg.md.en msg.md.es src/distrib/utils/sysinst/arch/cobalt: msg.md.en src/distrib/utils/sysinst/arch/evbarm: msg.md.de msg.md.en msg.md.es src/distrib/utils/sysinst/arch/hp300: msg.md.de src/distrib/utils/sysinst/arch/i386: msg.md.de msg.md.en msg.md.es msg.md.pl src/distrib/utils/sysinst/arch/mac68k: msg.md.de msg.md.en msg.md.es msg.md.pl src/distrib/utils/sysinst/arch/ofppc: msg.md.en msg.md.es msg.md.pl src/distrib/utils/sysinst/arch/prep: msg.md.en msg.md.es msg.md.pl src/distrib/utils/sysinst/arch/sparc: msg.md.de msg.md.en msg.md.es src/distrib/utils/sysinst/arch/x68k: msg.md.pl Log Message: Put back spaces at EOL where needed (in a message file, a space at EOL means a line break, a line break means a space...) This should fix PR 46042. Did you check all changes? I mechanically reverted all whitespace changes so we have the state we had before the copyright changes. Trailing spaces in most of MD msg files are not line break, but actually extra junk. It looks only following files needs to be changed: src/distrib/utils/sysinst/msg.mbr.de src/distrib/utils/sysinst/msg.mbr.en src/distrib/utils/sysinst/msg.mbr.es src/distrib/utils/sysinst/msg.mbr.fr src/distrib/utils/sysinst/msg.mbr.pl src/distrib/utils/sysinst/msg.mi.de src/distrib/utils/sysinst/msg.mi.en src/distrib/utils/sysinst/msg.mi.es src/distrib/utils/sysinst/msg.mi.fr src/distrib/utils/sysinst/msg.mi.pl src/distrib/utils/sysinst/arch/evbarm/msg.md.de src/distrib/utils/sysinst/arch/i386/msg.md.en --- Izumi Tsutsui -- \~.The NetBSD Foundation \~' Marc Balmer, Developer / Marketing NetBSD \ mbal...@netbsd.org http://www.NetBSD.org/
Re: CVS commit: src/distrib/utils/sysinst
mbalmer@ wrote: Log Message: Put back spaces at EOL where needed (in a message file, a space at EOL means a line break, a line break means a space...) This should fix PR 46042. Did you check all changes? I mechanically reverted all whitespace changes so we have the state we had before the copyright changes. Ok, it's fine for pullups. I'll cleanup actual junk spaces later. --- Izumi Tsutsui
Re: CVS commit: src/lib/libc
On Fri, 02 Mar 2012, Izumi Tsutsui wrote: Again, how can you support/control/update third party products not to use deprecated functions? Our libc is designed for NetBSD? You can't make them not use deprecated functions, but I think you can tell them to link with libdeprecated, or to add -DI_WANT_GETS to CFLAGS. --apb (Alan Barrett)
Re: CVS commit: src/lib/libc
Again, how can you support/control/update third party products not to use deprecated functions? Our libc is designed for NetBSD? You can't make them not use deprecated functions, but I think you can tell them to link with libdeprecated, or to add -DI_WANT_GETS to CFLAGS. We could *tell* them, but no lazy third parties would bother to add extra configure checks for paranoiac non C89 compliant environment. --- Izumi Tsutsui
Re: CVS commit: src/lib/libc
On Mar 1, 2012, at 10:58 AM, Izumi Tsutsui wrote: Again, how can you support/control/update third party products not to use deprecated functions? Our libc is designed for NetBSD? You can't make them not use deprecated functions, but I think you can tell them to link with libdeprecated, or to add -DI_WANT_GETS to CFLAGS. We could *tell* them, but no lazy third parties would bother to add extra configure checks for paranoiac non C89 compliant environment. Let's gratuitously break third parties because one cannot think of a good way to use gets. I hit warnings on some package years ago that did use gets 100% safely because it was used in a pipeline where the produce never produced (and could never produce) strings longer than the consumer had buffer space for. The original author demurred when I sent (trivial) patches to fix the receiver to use fgets instead. He insisted he had better things to do with his time than to cope with the paranoid and complained that strcpy was next since it could be used unsafely. Rather than argue, I just got on with my life and even forgot the name of the package that had these warnings... Maybe somebody can look at a full pkgsrc build to see how many instances of gets are in it? Warner
Re: CVS commit: src/lib/libc
On Thu, Mar 01, 2012 at 05:07:32PM +0100, Joerg Sonnenberger wrote: My strong dislike of *_s from C11 is not relevant. Those functions are not part of the core standard, but an (optional) annex. gets() is pretty bad for anything that is system or suid. For a normal user app it doesn't matter that much. Invalid input genetates a core dump and/or corrupted user data. For a test program it doesn't really matter that much. Of course, you could have a libc.so in another directory that contains things like gets() and other deprecated stuff and a .NEEDED entry for the real libc - and use that to compile/run old binaries. Oh - except they've broken that feature of the linker. My objection to the *_s() forms is that they are not really inherently more 'secure' than the older functions. They just include some of the checks the coder should have done. So are just variants of the old function not 'secure' versions. Microsoft's exception-throwing functions are even worse! (Mind you Microsoft's _snprintf() is particulary borked.) David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/doc
On Fri, Mar 02, 2012 at 07:06:31AM +, Alan Barrett wrote: Module Name: src Committed By: apb Date: Fri Mar 2 07:06:31 UTC 2012 Modified Files: src/doc: 3RDPARTY Log Message: tzcode2012b and tzdata2012b ahve been released. We have updated to tzdata2012b. What was the resolution with the patent issues and whatnot? - Jukka.
