On 14.08.2010 08:57, David Holland wrote:
On Wed, Aug 11, 2010 at 11:49:10PM +0200, Jean-Yves Migeon wrote:
- esp_aeesctr_mature %s: unsupported algorithm.\n,
- algo-name));
+ %s: unsupported encryption algorithm %d\n,
+ __func__,
On Sat, Aug 14, 2010 at 01:36:15PM +0200, Jean-Yves Migeon wrote:
I would say don't do __func__ for messages like this; it doesn't
really serve much purpose vs. typing in a name, causes the observable
behavior to change silently if the code gets reorganized, and makes it
much harder to
On Thu, 12 Aug 2010, Bernd Ernesti wrote:
if (dev_priv == NULL) {
DRM_ERROR(called with no initialization\n);
- DRM_SPINUNLOCK(dev_priv-cs.cs_mutex);
...
Hmm, you didn't mention why you are doing that in your initial mail.
Use of pointer after
On Wed, Aug 11, 2010 at 11:49:10PM +0200, Jean-Yves Migeon wrote:
[..]
I will commit the attached patch on Saturday, unless someone objects.
[..]
Index: external/bsd/drm/dist/shared-core/radeon_cs.c
===
RCS file:
On Thu, 12 Aug 2010, Bernd Ernesti wrote:
if (dev_priv == NULL) {
DRM_ERROR(called with no initialization\n);
- DRM_SPINUNLOCK(dev_priv-cs.cs_mutex);
...
Hmm, you didn't mention why you are doing that in your initial mail.
Use of pointer after determining it's
On 12.08.2010 06:49, Bernd Ernesti wrote:
On Wed, Aug 11, 2010 at 11:49:10PM +0200, Jean-Yves Migeon wrote:
[..]
I will commit the attached patch on Saturday, unless someone objects.
[..]
Index: external/bsd/drm/dist/shared-core/radeon_cs.c
On 10.08.2010 19:11, Matthias Drochner wrote:
jeanyves.mig...@free.fr said:
But the NULL deref fixes will go in eventually, and I will probably
ask for a pull up too ;)
But then...
algo = esp_algorithm_lookup(sav-alg_enc);
- if (!algo) {
+ if (algo == NULL) {
On 10.08.2010 19:11, Matthias Drochner wrote:
jeanyves.mig...@free.fr said:
But the NULL deref fixes will go in eventually, and I will probably
ask for a pull up too ;)
But then...
algo = esp_algorithm_lookup(sav-alg_enc);
- if (!algo) {
+ if (algo == NULL) {
On Mon, Aug 09, 2010 at 10:49:05PM +0200, Jean-Yves Migeon wrote:
Note also that I applied the spatch against sys/; the rest of src could
get a scan. But I would prefer to look for other static analyzers first,
perhaps there are more suitable (and faster) ones.
If you're talking about static
jeanyves.mig...@free.fr said:
But the NULL deref fixes will go in eventually, and I will probably
ask for a pull up too ;)
But then...
algo = esp_algorithm_lookup(sav-alg_enc);
- if (!algo) {
+ if (algo == NULL) {
ipseclog((LOG_ERR,
-
On Tue, 10 Aug 2010 12:11:32 -0500, Eric Haszlakiewicz e...@nimenees.com
wrote:
On Mon, Aug 09, 2010 at 10:49:05PM +0200, Jean-Yves Migeon wrote:
Note also that I applied the spatch against sys/; the rest of src could
get a scan. But I would prefer to look for other static analyzers
first,
On Tue, 10 Aug 2010 19:11:56 +0200, Matthias Drochner
m.droch...@fz-juelich.de wrote:
jeanyves.mig...@free.fr said:
But the NULL deref fixes will go in eventually, and I will probably
ask for a pull up too ;)
But then...
algo = esp_algorithm_lookup(sav-alg_enc);
- if
On Tue, Aug 10, 2010 at 07:40:38PM +0200, Jean-Yves Migeon wrote:
On Tue, 10 Aug 2010 12:11:32 -0500, Eric Haszlakiewicz e...@nimenees.com
wrote:
On Mon, Aug 09, 2010 at 10:49:05PM +0200, Jean-Yves Migeon wrote:
Note also that I applied the spatch against sys/; the rest of src could
get
On Sun, 8 Aug 2010 14:45:59 -0400, Matthew Mondor
mm_li...@pulsar-zone.net wrote:
On Sun, 08 Aug 2010 18:05:11 +0200
Jean-Yves Migeon jeanyves.mig...@free.fr wrote:
Opinions? Any interest in it? My intent is to put NetBSD specific
scripts on wiki.n.o, and provide links for more generic
On Mon Aug 09 2010 at 11:20:29 +0200, Jean-Yves Migeon wrote:
It is 'error-prone, in the sense that it can raise false positives. But
when you get more familiar with it, you can either fix the cocci patch
(easy for __arraycount, I missed one of the cases... less obvious for
aprint stuff), and
On Mon, 9 Aug 2010 13:27:38 +0300, Antti Kantee po...@cs.hut.fi wrote:
I really dislike untested wide-angle churn, especially if there is 0
measurable gain. Converting code to __arraycount is a prime example.
The only benefit of __arraycount is avoiding typing and therefore typos.
Neither of
On 09.08.2010 18:45, Antti Kantee wrote:
On Mon Aug 09 2010 at 18:19:28 +0200, Jean-Yves Migeon wrote:
That said, if $someone can produce a set of rules which showably find
bugs in NetBSD code and do not produce a lot of false positives, I'm
very interested in seeing nightly runs.
Alright,
Date:Mon, 09 Aug 2010 18:19:28 +0200
From:Jean-Yves Migeon jeanyves.mig...@free.fr
Message-ID: e2568087e60b3c2943d03413cd7e5...@localhost
I agree with pooka, no code changes to existing code just to make the
code look better.
| However, I would prefer to have code
Dear all,
I occasionally see fixes committed for things like __arraycount() or
roundup() substitutions, done on a per-file-per-interest basis.
Would there be any use of fixing/cleaning (at least, kernel) code by
using devel/coccinelle [1] ?
I know, this sounds like janitor work, but using such
On Sun, 08 Aug 2010 18:05:11 +0200
Jean-Yves Migeon jeanyves.mig...@free.fr wrote:
Opinions? Any interest in it? My intent is to put NetBSD specific
scripts on wiki.n.o, and provide links for more generic ones.
That seems like a handy tool to save time and avoid a number of
typos, if it's used
20 matches
Mail list logo
