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
r
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
>
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 ssl_rs
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
>
>
> 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
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 fi
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
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 -00
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
> Date: Thu, 08 May 2014 14:44:30 +0100
> From: Mark Cave-Ayland
>
> 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 (TTE) entry for 0x180
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
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
On 08 May 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, s
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
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 retur
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 ge
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 coexistenc
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
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 outpu
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 :
> Hi tech,
>
> I thin
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 s
21 matches
Mail list logo
