Re: audio(9) manual page

2014-06-24 Thread Alexandre Ratchov
On Tue, Jun 24, 2014 at 03:58:41AM +0400, Alexander Polakov wrote: So I have been trying to write a new audio driver (for Xonar DS if anyone interested) and therefore reading audio(9). I was confused for a while by the use of will here. I think it's not clear enough that these functions

Undefined symbol in ld.so

2014-06-24 Thread William Orr
ld.so in -current isn't building right now, due to an undefined reference to _dl_realloc caused by the recent addition of _dl_reallocarray. The following diff implements _dl_realloc, largely copied from the implementation in lib/libc/stdlib/malloc.c. tested on amd64 Index: malloc.c

Re: Undefined symbol in ld.so

2014-06-24 Thread Nigel Taylor
On 06/24/14 09:30, William Orr wrote: ld.so in -current isn't building right now, due to an undefined reference to _dl_realloc caused by the recent addition of _dl_reallocarray. The following diff implements _dl_realloc, largely copied from the implementation in lib/libc/stdlib/malloc.c.

Re: audio(9) manual page

2014-06-24 Thread Jason McIntyre
On Tue, Jun 24, 2014 at 09:13:47AM +0200, Alexandre Ratchov wrote: On Tue, Jun 24, 2014 at 03:58:41AM +0400, Alexander Polakov wrote: So I have been trying to write a new audio driver (for Xonar DS if anyone interested) and therefore reading audio(9). I was confused for a while by the

Re: Undefined symbol in ld.so

2014-06-24 Thread Otto Moerbeek
On Tue, Jun 24, 2014 at 01:30:55AM -0700, William Orr wrote: ld.so in -current isn't building right now, due to an undefined reference to _dl_realloc caused by the recent addition of _dl_reallocarray. The following diff implements _dl_realloc, largely copied from the implementation in

Re: pfctl: stricter redirect specs

2014-06-24 Thread Mike Belopuhov
On Tue, Jun 24, 2014 at 15:07 +0200, Mike Belopuhov wrote: I have carefully tested that and do not expect any unrelated fallout. And for the reasons stated above I don't believe anyone is using this since it's largely error prone. and a regress chunk that avoids using such combination.

Re: pfctl: stricter redirect specs

2014-06-24 Thread Stuart Henderson
On 2014/06/24 15:07, Mike Belopuhov wrote: I propose to avoid the confusion by flagging such situations as errors, e.g.: % echo 'pass out nat-to { ::1 1.1.1.1 }' | ./obj/pfctl -o none -vnf - stdin:1: translation spec contains addresses with different address families stdin:1: skipping

Re: infnan.3

2014-06-24 Thread Theo de Raadt
It's obvious that whole page needs a content update by a VAX expert. that is correct. All the rest of the discussion is moot. Only miod and martynas can swing this the right way. I disagree with Ted about making this a seperate page, since that would remove a vital component of floating point

Re: infnan.3

2014-06-24 Thread Ingo Schwarze
Hi, Theo de Raadt wrote on Tue, Jun 24, 2014 at 09:09:49AM -0600: Ingo Schwarze wrote: It's obvious that whole page needs a content update by a VAX expert. that is correct. All the rest of the discussion is moot. Only miod and martynas can swing this the right way. I disagree with Ted

Re: PATCH: ftp: allow @ in username for Basic Auth

2014-06-24 Thread Sébastien Marie
Hi, As I see not activity or feedback for this one line patch, I think it need more explain ? Currently, when you pass an URL with user/pass embed, the code parse it badly. For example: https://mym...@example.com:my-passw...@another-domain.example.com/blabla Just before the code search if the

Re: Undefined symbol in ld.so

2014-06-24 Thread William Orr
Whoops! Sorry for the confusion; disregard. On Jun 24, 2014, at 3:31 AM, Otto Moerbeek o...@drijf.net wrote: On Tue, Jun 24, 2014 at 01:30:55AM -0700, William Orr wrote: ld.so in -current isn't building right now, due to an undefined reference to _dl_realloc caused by the recent addition of

Re: PATCH: ftp: allow @ in username for Basic Auth

2014-06-24 Thread Philip Guenther
On Tue, Jun 24, 2014 at 9:01 AM, Sébastien Marie semarie-open...@latrappe.fr wrote: As I see not activity or feedback for this one line patch, I think it need more explain ? Sorry, the patch is incorrect; per RFC 3986, the parser is correct to split the authority on the first '@'. The

POSIX-compliant page fault error codes

2014-06-24 Thread Matthew Dempsky
POSIX specifies these error cases for memory faults: SIGSEGV/SEGV_MAPERR: Accessing an unmapped page. SIGSEGV/SEGV_ACCERR: Reading from a non-readable or writing to a non-writable page. SIGBUS/BUS_ADRERR: Accessing a mapped page that exceeds the end of the underlying mapped file. I

newfs_msdos: proper boot signature

2014-06-24 Thread Tobias Stoeckmann
Hi, time to merge another fix from NetBSD (and FreeBSD who applied it too): If sector size is not 512, the boot signature is placed at a wrong position. It always has to be at offset 510/511, not sector size - 2. # dd if=/dev/zero of=fat.iso bs=1M count=1 # vnconfig vnd0c fat.iso # newfs_msdos

Re: audio(9) manual page

2014-06-24 Thread Alexander Polakov
* Jason McIntyre j...@kerhand.co.uk [140625 00:41]: On Tue, Jun 24, 2014 at 09:13:47AM +0200, Alexandre Ratchov wrote: I see what you mean. As the manual describes the interface between two layers we may need to be more precise about who calls who. Wouldn't the following be less ambigous?

Re: POSIX-compliant page fault error codes

2014-06-24 Thread Matthew Dempsky
On Tue, Jun 24, 2014 at 11:04:10AM -0700, Matthew Dempsky wrote: SIGBUS/BUS_ADRERR: Accessing a mapped page that exceeds the end of the underlying mapped file. Generating SIGBUS for this case has proven controversial due to concern that this is Linux invented behavior and not compatible

Re: POSIX-compliant page fault error codes

2014-06-24 Thread Theo de Raadt
Matthew -- fine, you collected information. Thank you. It is quite clear that POSIX set in stone an accident, a significant error in my opinion. Anyone with enough expertise can recognize this is an accident in the SVR4 codebase, which ended up being ratified (in quotes, because the more