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 ha
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",
> > +
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__, sav->alg_enc));
I would say don'
On 12.08.2010 08:17, Hubert Feyrer wrote:
> 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 init
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 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
> > ===
>
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 determi
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: /cvsroot/
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 Tue, Aug 10, 2010 at 07:40:38PM +0200, Jean-Yves Migeon wrote:
>
> On Tue, 10 Aug 2010 12:11:32 -0500, Eric Haszlakiewicz
> 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.
On Tue, 10 Aug 2010 19:11:56 +0200, 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) {
> +
On Tue, 10 Aug 2010 12:11:32 -0500, Eric Haszlakiewicz
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,
>> perhaps there
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,
- "e
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
On Tue, 10 Aug 2010 07:35:15 +0700, Robert Elz wrote:
> Date:Mon, 09 Aug 2010 18:19:28 +0200
> One obvious example is that it makes it much harder in the future to
> pullups of
> fixes to code in this area to earlier NetBSD versions - the diffs show
all
> of this meaningless churn as well
Date:Mon, 09 Aug 2010 18:19:28 +0200
From:Jean-Yves Migeon
Message-ID:
I agree with pooka, no code changes to existing code just to make the
code look better.
| However, I would prefer to have code using roundup/MIN/MAX rather than
| rewriting them down. It tend
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.
>>
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, let's get a bit more practical.
On Mon, 9 Aug 2010 13:27:38 +0300, Antti Kantee 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 those apply
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),
On Sun, 8 Aug 2010 14:45:59 -0400, Matthew Mondor
wrote:
> On Sun, 08 Aug 2010 18:05:11 +0200
> Jean-Yves Migeon 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
On Sun, 08 Aug 2010 18:05:11 +0200
Jean-Yves Migeon 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 right. Thanks for
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
25 matches
Mail list logo
