linux-kernel - Re: [PATCH] net/ipv4/af_inet.c: use ARRAY

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0709020235420.22012@localhost.localdomain>
Date:	Sun, 2 Sep 2007 02:36:05 -0400 (EDT)
From:	"Robert P. J. Day" <rpjday@...dspring.com>
To:	rae l <crquan@...il.com>
cc:	Linux kernel mailing list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] net/ipv4/af_inet.c: use ARRAY_SIZE macro from kernel.h
 instead

On Sun, 2 Sep 2007, rae l wrote:

> On 9/2/07, Robert P. J. Day <rpjday@...dspring.com> wrote:

> > denis:
> >
> > if you're planning on doing this ARRAY_SIZE cleanup fairly
> > rigorously, here's an overview of what you're looking (based on a
> > fairly dumb scanning script that undoubtedly generates some false
> > positives).  of course, the respective subsystem maintainers are
> > welcome to deal with them first, of course.
> >
> > p.s.  and when you submit those patches, it's necessary to submit
> > them to only the appropriate subsystem mailing lists, not to the
> > LKML in general.

> I didn't realize that there's so many places to switch to
> ARRAY_SIZE, so now I wonder is this cleaning work valuable to the
> whole kernel tree? or we can keep the current state and just
> encourage new code to use ARRAY_SIZE?

that is *so* not my call.  i just thought that, if you were about to
embark on this clean-up, you knew what was ahead of you.  if you're
still interested in doing it, my best advice is to do it a subsystem
at a time, and submit the patches just to those subsystems or the
appropriate maintainers, rather than to the whole LKML, in order to
keep the traffic down.

and i'd encourage you to keep working on this.  and if you have any
more general questions, you're better off asking on the kernel
janitors list, not LKML.

http://kerneljanitors.org/

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca
========================================================================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/