> "B. James Phillippe" <bryan@terran.org> said:
>
> [...]
>
> > 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.
>
> If it was that way, size_t as a type would be completely pointless, would
> it?
That's like saying if I find a nice pair of glasses on the sidewalk, I
should put HCl in my eyes until the prescription matches. What is the
point of all the abstract types (size_t, time_t, pid_t, off_t, etc)? The
point is that we have a type whose exact nature is not needed to be known
by the programmer such that the properties of that type can be changed
without breaking code that uses it.
For instance, changing a foo_t from a unsigned char to an unsigned long,
should not break the code unless the author abuses the type and relies on
some inside knowledge.
Making "size_t" the same C type across all architectures does not defeat
it's purpose. By using size_t instead of "unsigned long" (for example),
the programmer can switch types by defining size_t privately to something
else. It also allows the kernel to change the meaning of size_t, to say
long long, for example (would be stupid, but it's for sake of argument).
In any case, I don't see the reason why the types need to be different
between Linux ports. It seems only to introduce more headaches when
porting.
-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/