OpenBSD bcrypt return value on errors

2012-02-25 Thread Loganaden Velvindron
According to http://www.openwall.com/lists/oss-security/2011/11/15/3, it would be preferable to use something else than ':' when an error is encountered. According to crypt(3), crypt() should return NULL values on errors. Index: src/lib/libc/crypt/bcrypt.c

Re: Unbound in base

2012-02-25 Thread Björn Ketelaars
> The latest iteration includes: > > - Removal of ldns-includes, -library and -manpages; > - Static link of ldns; > - No shared libraries. There was a nasty config-error in Makefile.bsd-wrapper which has been fixed in: http://gateway.hydroxide.nl/OpenBSD/unbound-wip.8.tar.gz This iteration als

Re: NEW: libc getdelim(3) and getline(3)

2012-02-25 Thread Antoine Jacoutot
On Sat, Feb 25, 2012 at 04:50:21PM +, Christian Weisgerber wrote: > Philip Guenther wrote: > > > Now that the base is unlocked, we can consider diffs to > > a) rename getdelim() and getline() symbols that are already in the tree, and > > b) add getdelim() and getline() to libc. > > > > Note

Re: NEW: libc getdelim(3) and getline(3)

2012-02-25 Thread Christian Weisgerber
Philip Guenther wrote: > Now that the base is unlocked, we can consider diffs to > a) rename getdelim() and getline() symbols that are already in the tree, and > b) add getdelim() and getline() to libc. > > Note that (a) will need to go in before (b)... I also expect some fallout in the ports t

SMBus support for AMD CS5536 (glxpcib)

2012-02-25 Thread Mike Belopuhov
hi, here's a diff that adds support for the SMBus controller found on AMD CS5536: glxpcib0 at pci0 dev 15 function 0 "AMD CS5536 ISA" rev 0x03: rev 3, 32-bit 3579545Hz timer, watchdog, gpio, i2c gpio0 at glxpcib0: 32 pins iic0 at glxpcib0 maxtmp0 at iic0 addr 0x4c: lm86 # sysctl hw.sensors hw.s

Re: vgafb(4) cleaning #3

2012-02-25 Thread Jonathan Armani
On Thu, Feb 23, 2012 at 06:12:51PM +0100, Martin Pieuchot wrote: > Diff below is a rewrite the vgafb_pci_probe(). The idea is to save the > different PCI bars in the device structure for later access in drm(4). > It also simplifies the code to make it looks more like vga(4). > > Ok? > > Martin >

Re: NEW: libc getdelim(3) and getline(3)

2012-02-25 Thread Steffen Daode Nurpmeso
diff3(1). --steffen Index: usr.bin/diff3/diff3prog.c === RCS file: /Users/steffen/arena/code.openbsd/src/usr.bin/diff3/diff3prog.c,v retrieving revision 1.11 diff -a -p -u -r1.11 diff3prog.c --- usr.bin/diff3/diff3prog.c 27 Oct 200

Re: NEW: libc getdelim(3) and getline(3)

2012-02-25 Thread Steffen Daode Nurpmeso
lpr(1). --steffen Index: usr.sbin/lpr/common_source/common.c === RCS file: /Users/steffen/arena/code.openbsd/src/usr.sbin/lpr/common_source/common.c,v retrieving revision 1.33 diff -a -p -u -r1.33 common.c --- usr.sbin/lpr/common_so

Re: NEW: libc getdelim(3) and getline(3)

2012-02-25 Thread Steffen Daode Nurpmeso
uudecode(1). --steffen Index: usr.bin/uudecode/uudecode.c === RCS file: /Users/steffen/arena/code.openbsd/src/usr.bin/uudecode/uudecode.c,v retrieving revision 1.17 diff -a -p -u -r1.17 uudecode.c --- usr.bin/uudecode/uudecode.c 27 O

Re: PCI_PWR_D[0-3] vs. PCI_PMCSR_STATE_D[0-3]

2012-02-25 Thread Jonathan Gray
My impression on going over the netbsd commits where this came from is that this was intended to be used with pci_set_powerstate and friends. So I think the definitions should go, the bge changes go in, but the ifdef'd out chunks with cardbus_setpowerstate should be deleted entirely rather than mo

ksh(1), big one

2012-02-25 Thread Steffen Daode Nurpmeso
Wanted or not, here is the promised big diff which does the following: 1. Encapsulate struct table iteration usage (*All* direct accesses encapsulated with struct tstate.) 2. ktinit() shouldn't expect pow2 size requests.. (It's really better that way.) 3. Turn struct table over to node-based

ksh(1), smaller one

2012-02-25 Thread Steffen Daode Nurpmeso
And this smaller diff excludes the node-based table. Since revision 1.8 (extra sanity checking for afree()) is the youngest commit of alloc.c i guess that checking should not be removed. But that unidirectional list walk is a real killer: with the test from one of my former mails and 1 variab