This patch removes some ARRAY_SIZE macro duplicates. There is also one in

arch/um/include/user.h, which isn't fixed here because comments in that file

explicitly state a preference for the 'less fancy' version. If that's the

case as well for any of the other replacements please comment.
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>

---
 Documentation/spi/spidev_test.c    |    2 --

 arch/i386/boot/compressed/relocs.c |    1 -

 arch/m68k/amiga/amisound.c         |    3 +--

 arch/powerpc/boot/types.h          |    2 --

 arch/sparc64/kernel/pci.c          |    6 ++----

 drivers/acpi/utilities/uteval.c    |    4 ++--

 drivers/net/irda/actisys-sir.c     |    6 ++----

 drivers/net/lp486e.c               |    4 +---

 drivers/net/sk98lin/skgemib.c      |    5 -----

 drivers/net/skfp/smt.c             |    4 +---

 drivers/net/skfp/srf.c             |   18 +++++++-----------

 drivers/net/wireless/ipw2100.c     |   13 ++++---------

 drivers/serial/68328serial.c       |    6 ++----

 drivers/video/sgivwfb.c            |    4 ++--

 include/acpi/acmacros.h            |    2 --

 include/linux/netfilter/xt_sctp.h  |   12 +++++-------

 include/net/ip_vs.h                |    1 -

 include/video/sgivw.h              |    1 -

 net/ipv4/ipvs/ip_vs_proto_tcp.c    |    2 +-

 scripts/mod/file2alias.c           |    2 --

 20 files changed, 30 insertions(+), 68 deletions(-)
diff --git a/Documentation/spi/spidev_test.c b/Documentation/spi/spidev_test.c

index 218e862..0f23aac 100644

--- a/Documentation/spi/spidev_test.c

+++ b/Documentation/spi/spidev_test.c

@@ -21,8 +21,6 @@

 #include <linux/types.h>

 #include <linux/spi/spidev.h>
-#define ARRAY_SIZE(a) (sizeof(a) / sizeof((a)[0]))

-

 static void pabort(const char *s)

 {

 	perror(s);

diff --git a/arch/i386/boot/compressed/relocs.c b/arch/i386/boot/compressed/relocs.c

index 2d77ee7..5d8dbff 100644

--- a/arch/i386/boot/compressed/relocs.c

+++ b/arch/i386/boot/compressed/relocs.c

@@ -11,7 +11,6 @@

 #include <endian.h>

 ...
[ message continues ]

I got a bunch of rejects against various development trees, a

build error in net/ipv4/ipvs/ip_vs_proto_udp.c and now
net/netfilter/xt_sctp.c: In function 'match_packet':

net/netfilter/xt_sctp.c:58: error: size of array 'type name' is negative

net/netfilter/xt_sctp.c:106: error: size of array 'type name' is negative

-

among other things, one of the creepy issues here is the definition in

include/linux/netfilter/xt_sctp.h of the macro:
...

#define SCTP_CHUNKMAP_COPY(destmap, srcmap)                     \

        do {                                                    \

                int i;                                          \

                for (i = 0; i < ELEMCOUNT(chunkmap); i++)       \

                        destmap[i] = srcmap[i];                 \

        } while (0)

...
  i'm not a big fan of macros that refer to objects that aren't

parameters to the macro, especially when all the rest of them *do*.
rday
p.s.  ELEMCOUNT is simply an alternative to ARRAY_SIZE, which could

certainly be rewritten that way.
--

========================================================================

Robert P. J. Day

Linux Consulting, Training and Annoying Kernel Pedantry

Waterloo, Ontario, CANADA
http://crashcourse.ca

========================================================================

-

On Mon, 1 Oct 2007, Robert P. J. Day wrote:
                                            ^^^^^^^^
whoops, i take it back ... isn't this just a flat-out error, where the

macro should be written with the correction above?
rday
--

========================================================================

Robert P. J. Day

Linux Consulting, Training and Annoying Kernel Pedantry

Waterloo, Ontario, CANADA
http://crashcourse.ca

========================================================================

-

However, arch/m68k/amiga/amisound.c:

Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Gr{oetje,eeting}s,
						Geert
--

Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But

when I'm talking to journalists I just say "programmer" or something like that.

							    -- Linus Torvalds

-

Well yes.  If the change had been split up into separate per-subsystem patches I

wouldn't have needed to drop the whole lot.  Hint.

-