Subject: mtools 3.6

From: Stefan Hanske <[email-masked]>
Date: Thu, 28 May 1998 15:16:02 +0200 (METDST)

There is a patch for mtools 3.6 available under
  http://www.rzuser.uni-heidelberg.de/~shanske/links.

The problem with mtools I had was that gcc didn't layout the structure
vfat_subentry as it's ment to be and since this struct is written to disc
'as is' (as a block of memory instead of fields) this is a problem that
corrupts discs. Have a look at the following code:

struct unicode_char {
			char lchar;
			char uchar;
};

struct vfat_subentry {
			...
			struct unicode_char text1[x] PACKED;
			...
};

This should advise gcc to create x copies of unicode_char in
vfat_subentry, allocating 2*x bytes of memory. I don't know why but gcc
makes it use 4 bytes per copy instead.

Thats what I called the PACKED bug. Any suggestions?? Is this repeatable
on other machines???

----------------------------------------------------------
|mailto: Stefan Hanske ([email-masked] |
|WWW : http://www.rzuser.uni-heidelberg.de/~shanske      |
|phone: I'm not silly                                    |
|--------------------------------------------------------|
| And don't forget to remember what you remembered not   |
| to forget to remember...				 |
----------------------------------------------------------

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Paul Koning <[email-masked]>
Date: Thu, 28 May 1998 09:25:17 -0400

>>>>> "Stefan" == Stefan Hanske <[email-masked]> writes:

 Stefan> The problem with mtools I had was that gcc didn't layout the
 Stefan> structure vfat_subentry as it's ment to be and since this
 Stefan> struct is written to disc 'as is' (as a block of memory
 Stefan> instead of fields) this is a problem that corrupts
 Stefan> discs. Have a look at the following code:

struct unicode_char {
			char lchar;
			char uchar;
};

struct vfat_subentry {
			...

 Stefan> This should advise gcc to create x copies of unicode_char in
 Stefan> vfat_subentry, allocating 2*x bytes of memory. I don't know
 Stefan> why but gcc makes it use 4 bytes per copy instead.

 Stefan> Thats what I called the PACKED bug. Any suggestions?? Is this
 Stefan> repeatable on other machines???

I once made the assumption that the standard alignment and sizing of
data items (each primitive of n bytes is aligned/sized to n bytes) is
the exact standard alignment/size rule.  C/C++ language experts
pointed out that this is not true; the standard says that it is the
MINIMUM alignment and implementations may force larger alignment.

So the minimum size of struct unicode_char is 2 and the minimum
alignment is 1, but implementations are allowed to increase that.

Most don't, but ARM does.  This has caused problems in lots of places
that make the same assumption I did...

You might try one of the following:

struct unicode_char {
			char lchar;
			char uchar;
} PACKED;

or

struct unicode_char {
			char lchar PACKED;
			char uchar PACKED;
};

So what this means, if I understood everything right, is that the bug
is in mtools (for making a language assumption not supported by the
standard) rather than in gcc.

	paul

---

From: Stefan Hanske <[email-masked]>
Date: Thu, 28 May 1998 15:36:08 +0200 (METDST)

> You might try one of the following:

I tried, no success. I think I've tried nearly everything to keep the
structure of vfat_subentry as is but there was no way.

---

From: Philip Blundell <[email-masked]>
Date: Thu, 28 May 1998 15:09:23 +0100

>standard) rather than in gcc.

That's right.  You can often use __attribute__ to turn off this padding, but 
you shouldn't rely on it in code that's supposed to be portable.  And there 
are times when even that isn't sufficient, for example the infamous `unaligned
short' problem.

p.

---

From: Paul Koning <[email-masked]>
Date: Thu, 28 May 1998 10:19:54 -0400

>>>>> "Philip" == Philip Blundell <[email-masked]> writes:

 >> So what this means, if I understood everything right, is that the
 >> bug is in mtools (for making a language assumption not supported
 >> by the standard) rather than in gcc.

 Philip> That's right.  You can often use __attribute__ to turn off
 Philip> this padding, but you shouldn't rely on it in code that's
 Philip> supposed to be portable.  And there are times when even that
 Philip> isn't sufficient, for example the infamous `unaligned short'
 Philip> problem.

That's fine when you don't say "packed" but I would argue that packed
structs shouldn't be treated that way.  I remember someone claiming
that the compiler should be entitled to pad things even if they are
marked "packed" -- I objected strongly then and will continue to do
so.

So if it's not possible to make the right thing happen with
application of "packed" in all the right places, then I would say
there IS a compiler bug.  After all, what sense does it make to have
"packed" that doesn't pack?

	paul