[Linux-NTFS-Dev] Re: [PATCH 8/10] Re: [2.6-BK-URL] NTFS: 2.1.19 sparse annotation, cleanups and a b
Development moved to https://sourceforge.net/projects/ntfs-3g/
Brought to you by:
antona,
cha0smaster
From: Anton A. <ai...@ca...> - 2004-09-26 07:47:40
|
On Fri, 24 Sep 2004, Linus Torvalds wrote: > On Fri, 24 Sep 2004, Anton Altaparmakov wrote: > > On Fri, 24 Sep 2004, Linus Torvalds wrote: > > > > > > Btw, Al is fixing this. We'll make enum's properly typed, rather than just > > > plain integers. It's not traditional C behaviour, but it gives you better > > > type safety, and Al points out that other C compilers (the Plan 9 one, to > > > be specific) have done the same thing for similar reasons. > > Well, when I said "Al is fixing this", I lied. > > I just fixed it myself. Great. (-: > > This is good news. Once that is done I will be very happy to go back to > > using enums as I also agree that they can and in this case do look a > > lot nicer... > > Try the current sparse, I think it should work for you. > > So if you make an enum where the initializer expression is a little-endian > expression, the type of that (single) enumerator will be little-endian. > > HOWEVER, the type of an enum _variable_ will still be just "int". So > > enum myenum { > one = 1ULL, > two = 2, > }; > > has the strange behaviour that if you use "one" in an expression, it will > have the type "unsigned long long", but if you use a "enum myenum" entry > (even if it has the value "1"), it will be an "int": > > sizeof(one) == 8 > sizeof(enum myenum) == 4 > > So I would stronly suggest (and I may make sparse warn) against using > non-integertyped enum values with any enum that actually has any backing > store (ie if you ever use a variable of type "enum myenum", that would > result in a warning - you can really just use the values "one" and "two" > directly). Ah, I was using them for backing store as well and I was using the __attribute__((packed)) gcc extension to make them the bit-width I wanted in combination with a "filler element" at the end of the enum. So for example to get a 16-bit enum type I was using: typedef enum { RESTART_VOLUME_IS_CLEAN = const_cpu_to_le16(0x0002), REST_AREA_SPACE_FILLER = 0xffff /* Just to make flags 16-bit. */ } __attribute__ ((__packed__)) RESTART_AREA_FLAGS; And then when defining the structure containing these flags I would just do: typedef struct { ... RESTART_AREA_FLAGS flags; ... } __attribute__ ((__packed__)) RESTART_AREA; Also I use the enum type as parameters to functions, for example in the above case I might have: int blah(RESTART_AREA_FLAGS flags); So this use doesn't work with the sparse update either. At the moment I have changed everything to just a bunch of #defines followed by a: typedef le16 RESTART_AREA_FLAGS; So I guess with your sparse update I can now go to a point in between the old one and the new one: enum { RESTART_VOLUME_IS_CLEAN = const_cpu_to_le16(0x0002), } __attribute__ ((__packed__)) RESTART_AREA_FLAGS; typedef le16 RESTART_AREA_FLAGS; So I get the enum rather than bunch of defines and I get my proper types as well. That only looses the ability for the compiler to warn if people use the wrong constant when trying to set such a variable or pass a wrong constant into a function but that is not nearly as useful a warning as the wrong endianness bitwise warnings we have now gained so I am not going to worry about losing it. Best regards, Anton -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/ |