Messages in this thread | | | Date | Sun, 02 Sep 2001 00:41:15 +0100 | From | Anton Altaparmakov <> | Subject | Re: [RFC] lazy allocation of struct block_device |
| |
At 22:26 01/09/2001, Jamie Lokier wrote: >Andries.Brouwer@cwi.nl wrote: > >[...] > > However, a union is not so bad. It seems a pity to avoid unions > > and waste 4 bytes for every inode with separate i_bdev and i_cdev > > instead of a single i_bcdev. > >Please, a union of different pointer types is much nicer. You can have >i_bdev and i_cdev without wasting any bytes. > >This form works with GCC 2.96: > > union { > struct char_device * i_cdev; > struct block_device * i_bdev; > };
It sure does. One of the nicest new gcc features IMHO!
>If you're using a really old compiler that doesn't support anonymous unions, >(GCC 2.95 might be in this category, I'm not sure),
GCC 2.95 does NOT support this. I only found out after I had people complain to me that Linux-NTFS userspace tools would not compile for them and it turned out they were using gcc-2.95... and I 2.96. - I have since then verified this myself:
egcs and gcc up to 2.95 do not support unnamed structs/unions.
gcc-2.96 and gcc-3.0 support them fine.
> then you'll need this: > > #define i_bdev __i_bcdev_union.i_bdev > #define i_cdev __i_bcdev_union.i_cdev > union { > struct char_device * i_cdev; > struct block_device * i_bdev; > } __i_bcdev_union;
Neat trick! Thanks! I was wondering what to do with NTFS TNG driver (which uses unnamed structs/unions extensively) and this just might solve my problems without having to rewrite half the driver... (-;
Best regards,
Anton
-- "Nothing succeeds like success." - Alexandre Dumas -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/ ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |