On Wed, May 07, 2014 at 12:13:42PM -0700, patrick keshishian wrote:
On Wed, May 07, 2014 at 02:47:32PM +0100, Dimitris Papastamos wrote:
Hi,
This piece of code now uses poll() instead of select().
I have not got round to test this yet, but I will as soon as I have
a working setup.
Can't say if this was the motivation here, but some people like to put
constants before variables for comparisons so as to easily catch the
difference between
if (a = 5) ...
and
if (5 = a) ..
when you really meant if (a == 5).
2014-05-08 0:13 GMT+02:00 Fritjof Bornebusch frit...@alokat.org:
On Wed, May 07, 2014 at 07:44:51PM +0200, Ingo Schwarze wrote:
While LC_CTYPE and LC_COLLATE make some sense, LC_MONETARY, LC_NUMERIC,
and LC_TIME are badly overengineered, pointless bloat, causing nothing
but surprising, erratic behaviour and portability problems when trying
to parse output
On Thu, May 08, 2014 at 09:45:22AM +0200, Janne Johansson wrote:
Can't say if this was the motivation here, but some people like to put
constants before variables for comparisons so as to easily catch the
difference between
if (a = 5) ...
and
if (5 = a) ..
when you really meant if (a == 5).
Hi all,
Following a discussion on the NANOG mailing regarding the overlap
between MAC addresses assigned to VRRP [1] and virtual host IDs as used
in the CARP protocol, it was suggested to use a range dedicated to CARP
[2]. Ytti assigned 74-66-30-FF-FE-00 .. 74-66-30-FF-FE-FF.
* Improve
On 06/05/14 19:18, Mark Cave-Ayland wrote:
(cut)
As soon as I step into address 0x1001804 then this is where things start
to go wrong; the TLB (TTE) entry for 0x180 which is accessed by %sp
is marked as privileged, but ASI 0x11 is user access only. QEMU's
current behaviour for this is to
This is wrong in several ways.
Never cast sizeof down, always cast the comparison variable up.
I'll specifically call out this change:
- if (snprintf(buf, sizeof(buf)) = (int)sizeof(buf))
+ if ((size_t)snprintf(buf, sizeof(buf)) = sizeof(buf))
The top way fails when snprintf
On Thu, May 08, 2014 at 12:35:56PM -0400, Ted Unangst wrote:
This is wrong in several ways.
Never cast sizeof down, always cast the comparison variable up.
I'll specifically call out this change:
- if (snprintf(buf, sizeof(buf)) = (int)sizeof(buf))
+ if ((size_t)snprintf(buf,
On 08 May 2014, at 18:43, Alexandre Ratchov a...@caoua.org wrote:
On Thu, May 08, 2014 at 12:35:56PM -0400, Ted Unangst wrote:
This is wrong in several ways.
Never cast sizeof down, always cast the comparison variable up.
I'll specifically call out this change:
-if (snprintf(buf,
On Thu, May 08, 2014 at 18:43, Alexandre Ratchov wrote:
On Thu, May 08, 2014 at 12:35:56PM -0400, Ted Unangst wrote:
This is wrong in several ways.
Never cast sizeof down, always cast the comparison variable up.
I'll specifically call out this change:
-if (snprintf(buf, sizeof(buf))
On Thu, May 08, 2014 at 12:07:30PM +0200, Stefan Sperling wrote:
On Wed, May 07, 2014 at 07:44:51PM +0200, Ingo Schwarze wrote:
While LC_CTYPE and LC_COLLATE make some sense, LC_MONETARY, LC_NUMERIC,
and LC_TIME are badly overengineered, pointless bloat, causing nothing
but surprising,
Date: Thu, 08 May 2014 14:44:30 +0100
From: Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk
On 06/05/14 19:18, Mark Cave-Ayland wrote:
Hi Mark,
Interesting to see sparc64 support in QEMU.
As soon as I step into address 0x1001804 then this is where things start
to go wrong; the TLB
Hi,
Marc Espie wrote on Thu, May 08, 2014 at 07:20:52PM +0200:
On Thu, May 08, 2014 at 12:07:30PM +0200, Stefan Sperling wrote:
On Wed, May 07, 2014 at 07:44:51PM +0200, Ingo Schwarze wrote:
While LC_CTYPE and LC_COLLATE make some sense, LC_MONETARY, LC_NUMERIC,
and LC_TIME are badly
Hi tech,
there is no way you can go, after usage() was called, so dont't do it.
fritjof
Index: ci.c
===
RCS file: /cvs/src/usr.bin/rcs/ci.c,v
retrieving revision 1.216
diff -u -p -r1.216 ci.c
--- ci.c27 Oct 2013 18:31:24
Hi,
My wireless card AR9485 is not recognized by kernel (5.5). I'm having the
error following error message:
Atheros AR9485 rev 0x01 at pci2 dev 0 function 0 not configured
As far as I understand it means it's not supported but I can find a 2012
email on tech list mentionning the ar9485 device
On 2014/05/08 22:57, Sébastien Morand wrote:
Hi,
My wireless card AR9485 is not recognized by kernel (5.5). I'm having the
error following error message:
Atheros AR9485 rev 0x01 at pci2 dev 0 function 0 not configured
As far as I understand it means it's not supported but I can find a
You could try adding the ID to the athn driver to get it to match:
Index: if_athn_pci.c
===
RCS file: /cvs/src/sys/dev/pci/if_athn_pci.c,v
retrieving revision 1.14
diff -u -p -r1.14 if_athn_pci.c
--- if_athn_pci.c 6
On 2014/05/08 23:43, Sébastien Morand wrote:
You could try adding the ID to the athn driver to get it to match:
Index: if_athn_pci.c
===
RCS file: /cvs/src/sys/dev/pci/if_athn_pci.c,v
retrieving revision 1.14
diff -u
Hi tech@,
In case this is considered important enough...
Remove unused ret from SSL_use_PrivateKey().
- Michael
Index: ssl_rsa.c
===
RCS file: /cvs/src/lib/libssl/src/ssl/ssl_rsa.c,v
retrieving revision 1.11
diff -u -r1.11
Your diff does not solve a problem.
In case this is considered important enough...
Remove unused ret from SSL_use_PrivateKey().
- Michael
Index: ssl_rsa.c
===
RCS file: /cvs/src/lib/libssl/src/ssl/ssl_rsa.c,v
retrieving
On Thu, May 08, 2014 at 22:39, Theo de Raadt wrote:
Your diff does not solve a problem.
Specifically, I don't think it's worth changing such code back or
forth either way, but using an extra variable to store the return value
from a function can make debugging easier. I may want to look at the
21 matches
Mail list logo