Re: CVS commit: src
On Sun, Mar 04, 2012 at 04:12:25PM +, Matthias Scheler wrote: Module Name: src Committed By: tron Date: Sun Mar 4 16:12:25 UTC 2012 Modified Files: src/distrib/sets/lists/man: mi src/external/ibm-public/postfix: Makefile.inc src/external/ibm-public/postfix/lib/global: Makefile src/external/ibm-public/postfix/man/man5: Makefile src/sys/sys: cdefs_elf.h Log Message: Add support for SQLite look-up tables to postfix(1), see sqlite_table(5) for more details. While here stop installation of pcre_table(5) as this table type is not supported. The change to src/sys/sys/cdefs_elf.h has nothing to do with this feature and was committed by accident. I've revert that change and updated the commit message in the repository. Sorry ... Kind regards -- Matthias Scheler http://zhadum.org.uk/
Re: CVS commit: src/lib/libc
On Mar 3, 2012, at 5:55 PM, David Holland wrote: On Thu, Mar 01, 2012 at 11:14:16AM -0700, Warner Losh wrote: Maybe somebody can look at a full pkgsrc build to see how many instances of gets are in it? Given the way bulk builds work, and various logistical reasons that is unlikely to change, the only practical way to check this is to remove gets locally before doing a build. Perhaps I'll do this. Any such program is broken and needs to be patched. Your example is unpersuasive. So there's no way to troll through the build binaries for references to gets, at least in the dynamically linked binaries? That's unfortunate. My example was a place where it was completely safe to use. I offered only to counter those that said it is never safe, which is factually untrue. But given the extreme ease with which it is unsafe to use, I'm with the 'get it out' crowd, but only if it doesn't provoke wide-spread chaos. without data, it is hard to say for sure the level of chaos. Warner
Re: CVS commit: src/lib/libc
On Sun, Mar 04, 2012 at 01:06:03PM -0700, Warner Losh wrote: On Mar 3, 2012, at 5:55 PM, David Holland wrote: On Thu, Mar 01, 2012 at 11:14:16AM -0700, Warner Losh wrote: Maybe somebody can look at a full pkgsrc build to see how many instances of gets are in it? Given the way bulk builds work, and various logistical reasons that is unlikely to change, the only practical way to check this is to remove gets locally before doing a build. Perhaps I'll do this. Any such program is broken and needs to be patched. Your example is unpersuasive. So there's no way to troll through the build binaries for references to gets, at least in the dynamically linked binaries? That's unfortunate. My example was a place where it was completely safe to use. I offered only to counter those that said it is never safe, which is factually untrue. But given the extreme ease with which it is unsafe to use, I'm with the 'get it out' crowd, but only if it doesn't provoke wide-spread chaos. without data, it is hard to say for sure the level of chaos. Running 'objdump -D' and grepping for '\gets\' will probably find them. I wonder it it would be worth adding a function that is like gets, but takes a buffer length (ie discards the \n - and maybe the rest of the line). That could be used as a compile-time substitute when the buffer size is known - ie when 'sizeof buffer != sizeof (char *)' David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/lib/libc
On Sun, 04 Mar 2012, David Laight wrote: I wonder it it would be worth adding a function that is like gets, but takes a buffer length (ie discards the \n - and maybe the rest of the line). C2011 has char *gets_s(char *s, rsize_t n); It discards the \n, but does not discard the rest of the line, so you can't tell the difference between a line that was exactly the maximum length (followed by a \n which is discarded) or a line that was too long. fgets() can tell the difference, however. --apb (Alan Barrett)
Re: CVS commit: src/lib/libc
On Sun, Mar 04, 2012 at 08:20:20PM +, David Laight wrote: I wonder it it would be worth adding a function that is like gets, but takes a buffer length (ie discards the \n - and maybe the rest of the line). That could be used as a compile-time substitute when the buffer size is known - ie when 'sizeof buffer != sizeof (char *)' I don't think that makes too much sense. If you want to read a full line, use getline. If you don't, loop with fgets until the full line is read. Joerg
Re: CVS commit: src/lib/libc
On Sun, Mar 04, 2012 at 10:38:19PM +0200, Alan Barrett wrote: On Sun, 04 Mar 2012, David Laight wrote: I wonder it it would be worth adding a function that is like gets, but takes a buffer length (ie discards the \n - and maybe the rest of the line). C2011 has char *gets_s(char *s, rsize_t n); It discards the \n, but does not discard the rest of the line, so you can't tell the difference between a line that was exactly the maximum length (followed by a \n which is discarded) or a line that was too long. fgets() can tell the difference, however. Not checking that allowed users to get root privs. IIRC it was very long fields in the password file causing an entry to be split. (fixed long long ago) So that '_s' form isn't 'secure' (or whatever _s is supposed to mean). David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/lib/libc
On Sun, Mar 04, 2012 at 09:42:21PM +0100, Joerg Sonnenberger wrote: On Sun, Mar 04, 2012 at 08:20:20PM +, David Laight wrote: I wonder it it would be worth adding a function that is like gets, but takes a buffer length (ie discards the \n - and maybe the rest of the line). That could be used as a compile-time substitute when the buffer size is known - ie when 'sizeof buffer != sizeof (char *)' I don't think that makes too much sense. If you want to read a full line, use getline. If you don't, loop with fgets until the full line is read. I was thinging of a header file fix to allow code to compile without changing the source and with miminal 'security' issues. David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/sys/arch/i386/i386
On 5 March 2012 02:14, Manuel Bouyer bou...@netbsd.org wrote: Module Name: src Committed By: bouyer Date: Sun Mar 4 20:44:17 UTC 2012 Modified Files: src/sys/arch/i386/i386: machdep.c Log Message: Don't try to uvm_page_physload() the tmpgdt page: this always fails because only one physical segment is configured for Xen, and it's probably not worth it to create a second physseg with a single page (uvm has optimisations for the VM_PHYSSEG_MAX == 1 case) ic, so we're potentially leaking 2 pages at boot now -- ~Cherry
