Christoph,
On Mon, 2002-08-19 at 14:56, Christoph Hellwig wrote:
> On Mon, Aug 19, 2002 at 02:52:08PM -0400, Danny Cox wrote:
> > > I don't think that's valid. And at least gcc 3.2 doesn't complain..
> >
> > Yes, but 2.96 does. I'd think that several folks use 2.96, since
> > that's the standard gcc from RH 7.2.
>
> Gcc '2.96' is a development snapshot. Even if redhat ships it it's by
> now ways official.
Okay, one more try, and I'll admit defeat, and shut up:
"Official" or not, many folks who use XFS will compile it with gcc
2.96, because that's the version they get by default. They must make
the changes if they wish to acutally *use* XFS. Even given that it's a
simple change, I doubt that a non-C-programmer can do it.
> > > In this case not, as the kmem_zone_t is an object opaque to it's user.
> > > Compare it to kmem_cache_t in þhe core Linux code.
> >
> > Okay, point taken. Nevertheless, the types between the .c and .h files
> > should be consistent, whatever is chosen, no?
>
> No. Using structs in headers and typedefs in the actual source is very
> common, because you can use pointers to struct without needing the actual
> declararion.
Yes, it's common. Yes, it's acceptable C. But it forces some people
to make changes to their XFS tree that will continue to haunt them until
they upgrade to a new compiler, and others to completly abandon XFS
because it won't compile for them.
You seem to be pushing a legalistic stance: "This is the proper way to
do it, so we're not going to change.", while I'm pushing for a relativly
small code change that will allow more people to use XFS, and thereby
gain a wider exposure/acceptance.
--
kernel, n.: A part of an operating system that preserves the
medieval traditions of sorcery and black art.
Danny