|
From: Anton A. <ai...@ca...> - 2002-12-02 11:33:16
|
On 2 Dec 2002, Richard Russon wrote:
> I've just committed a few changes to the ntfsprogs.
>
> I've added compat.[ch] to hide a host of minor tweaks that will be
> needed to get things to compile on Windows. This is enough to get
> around most of the GCCisms of the code, e.g. __attribute__.
>
> One thing I've had to change is the reliance on void * arithmetic.
> I was quite alarmed when I realised that gcc allows:
I wasn't alarmed. I liked and used it. (-;
> void *v = "abc";
> v++;
>
> It seems that they've decided to define sizeof (void) == 1. Sensible,
> but I don't think it's a standard. At the moment, I've just cast the
> pointers to (u8*). A warning for this can be turned on using
> -Wpointer-arith
Ok, fair enough, but don't expect me to remember it...
> We also seem to be relying on the size of __packed__ enums. It's a
> nice feature, but it's another gcc extension. In our code we can:
I _don't_ care. I don't want pragmas everywhere! gcc doesn't understand
pragmas anyway so the only way to be compatible with MSVC would be to do
some disgusting things like:
#ifdef MSVC
#define __PACKED__ <insert correct pragma crap here>
#define __UNPACKED__ <insert correct pragme crap here>
#define __attrbiute__ <what do we put here so it disappears?!?>
#define __packed__ <what do we put here so it disappears?!?>
#else
#define __PACKED__ <what do we put here so it disappears?!?>
#define __UNPACKED__ <what do we put here so it disappears?!?>
#endif
And then we rewrite:
> typedef enum {
> ABC = 4,
> } RICH __attribute__ ((__packed__));
to:
__PACKED__
typedef enum {
ABC = 4,
} RICH __attriute__ ((packed__));
__UNPACKED__
I am sorry but that is so disgusting I don't want to see it!
> The size of the type for the enum will be minimised, in this case to
> 1 byte. Then we can use it in a struct, e.g.:
>
> struct x {
> int a;
> RICH r;
> int b;
> };
>
> We rely on the enum being just one byte, but that's not portable.
Linux-NTFS only compiles with gcc (and as you know we are even very picky
about which version of gcc...). That is not by accident, it is by
design...
> One solution is to create and use the enumeration, but create a
> strictly sized type for the struct, e.g.
>
> enum rich {
> ABC = 4,
> };
> typedef u8 RICH;
>
> struct x {
> int a;
> RICH r;
> int b;
> };
I don't like that. It makes type checking impossible. The whole point of
enums is to allow type checking.
> The next problem is the casting of parameters for Dprintf. At the
> moment a lot of variables are cast to long long. Windows doesn't
> like "long long" and prefers "__int64". Being two words, I can't
> #define my way out of this.
Interesting one! That is really amusing. Windows can go to hell...
> I remember some reason (in kernel space) for this casting. Some reason
> why we couldn't use the pre-defined types. Anton? Now we're in
> userspace, can we change:
>
> Dprintf ("Big number %Lu\n", (unsigned long long) num);
>
> to:
>
> Dprintf ("Big number %Lu\n", (u64) num);
We can't do that because %Lu is by definition unsigned long long and not
u64. There are architectures where %L != 64-bit. This has been pointed out
repeatedly on lkml now (by one of the Dave's, DaveM perhaps? or maybe it
was HPA, not sure, but in either case I would take his word for it).
> If not, can we not simply #define our types instead of typedef'ing them?
Doesn't allow type checking. Which is why I don't like it. Just like for
the enums.
I don't believe in code that compiles on all compilers and all OS. All
commercial code I have seen (ok I may not have seen much but I have seen
some huge codebases which compile on 30+ architectures and pretty much
every OS in existence) always keeps separate code for each OS, and I would
really like to keep it this way considering the amount of header file uck
required for MSVC on Windows. If we keep going like this the MacOS people
will come next and add their own compatibility stuff and then the nice
clean (IMO) header files will turn into non-intelligible gobbledigook.
Sorry about the downbeat email, but I said from the beginning that I
didn't like the idea of compiling under MSVC and I predicted it would lead
to a lot of ugliness. And the above just proves how right I was (I
actually underestimated the amount of ugliness). The two compilers are
just way too different. )-:
Cheers,
Anton
--
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
|
