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 mista
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 wi
* Jason McIntyre [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?
> >
> > When
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
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 a
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 c
Whoops! Sorry for the confusion; disregard.
On Jun 24, 2014, at 3:31 AM, Otto Moerbeek 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 _dl_real
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 s
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 w
> 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
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: skipp
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.
Hi,
Looking at some corner-cases I've realised that collapse_redirspec
does a poor job of weeding out incompatibilities in the redirect
pool specifications and hence inferring the rule address family
from it.
An example is a rule like this:
pass out nat-to em0
Let's say that em0 has an IPv4 ad
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
> lib/
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 b
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.
>
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
==
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 function
18 matches
Mail list logo
