Re: size_t definition : Intel v Alpha (fwd)

B. James Phillippe (bryan@terran.org)
Mon, 27 Sep 1999 22:35:44 -0700 (PDT)


I like to poke sticks into hornet nests.

-bp

--
# bryan at terran dot org
# http://www.terran.org/~bryan

---------- Forwarded message ---------- Subject: Re: size_t definition : Intel v Alpha Date: Mon, 27 Sep 1999 22:19:48 -0700 From: B. James Phillippe <bryan@terran.org> To: Erik de Castro Lopo <erikd@zip.com.au> Newsgroups: comp.os.linux.development.system

On Sat, 25 Sep 1999, Erik de Castro Lopo wrote:

> On Intel size_t is unsigned int but on Alpha it is > unsigned long. I can understand why it is unsigned long > on Alpha, but not why it is unsigned int on Intel. ... > Can anybody explain this?

This has bugged me before, too, when porting code to my Alpha.

It comes from the Linux kernel includes <asm/posix_types.h> and <linux/types.h>. Personally I think it's a mistake in the kernel definitions, to be different C data types across architectures. It's fine for the sizes of a native type to differ; if "long" is a different number of bytes or byte-order on some other architecture. But when the data types themselves are different in the headers, you have problems when using abstract data types (eg. size_t). Effectively it's like saying that foo() takes an int on x86 and a long on Alpha (or Sparc64, or PPC, or ...). IMO it would be most proper if size_t were defined as unsigned long on all architectures.

-bp

--
# bryan at terran dot org
# http://www.terran.org/~bryan

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/