[LONG MAIL]: The story of the tiny TAPE_GET_MEDIA_PARAMETERS searching the man in the moon
Sun Jun 17 15:51:00 GMT 2001
On Fri, Jun 15, 2001 at 10:02:27PM -0400, Christopher Faylor wrote:
> On Fri, Jun 15, 2001 at 09:27:10PM -0400, Earnie Boyd wrote:
> >Christopher Faylor wrote:
> >> The problem is apparently that the native gcc compiler and a cross
> >> compiler seem to disagree on default structure packing.
> >Perhaps the -fnative-struct patch should be interesting to help?
> Perhaps, but the reason I forwarded it here is because I'm swamped and
> don't have time for much investigation in strange (gcc) code.
> The theory is that someone in this cooperative project might be interested
> in helping out.
> I'd hoped that Corinna would provide more details. She should be back online
> on Monday. Maybe we'll hear from her then.
I only can repeat the mail I originally sent to Chris. I actually tried
to debug gcc on Friday but I don't know too much about gcc and I didn't
find anything obvious in an hour or so. Nevertheless, I was a somewhat
busy with my travel preparations on Friday.
Ok, the original mail I sent to Chris so everyone can see at least the
result of the problem:
============= SNIP =============
To get info on tapes, the fhandler_tape code calls TapeGetParameters()
len = sizeof mp;
TapeGetParameters(..., &len, &mp);
len is an in/out parameter. It should be preloaded with the buffer
size on input and contains the correct required buffersize after
The above call failed which surprised me REALLY since the code is
over a year old and I was pretty sure that it worked before.
I added debug output and found that sizeof mp is returned
as 28 while len contains 32 as required buffersize after the call.
Interesting enough, the buffersize for the second possible
buffer type (TAPE_GET_DRIVE_PARAMETERS) is 32.
I changed the sizeof so that it's set to 32 and now it worked.
I checked in the change and that could be the end of the
story but it isn't.
Actually I checked the code of my `mt' implementation if I already
had done the same there. mt isn't using the ioctl interface of
Cygwin but instead uses native WinNT calls since mt is older
than the changes to Cygwin. Surprisingly enough I found that I
had used the same `sizeof mp' there.
What was going on here? Why does that work in `mt' but not in the
DLL? I was already suspecting some conspiracy (FBI, Aliens...).
I compiled mt again and it still worked... uhm... ok, now I saw
the difference. The DLL is cross compiled while mt was compiled
The same structure TAPE_GET_MEDIA_PARAMETERS has a size of 28 bytes
when cross compiled, while it is (correctly) 32 bytes when compiled
natively. I checked that I really used the same winnt.h file in
As I already mentioned I'm using the tier1-00r1p2 for cross compiling.
And since that problem already exists in 1.3.2, I suspect that your
compiler which you're using for building Cygwin has the same problem.
At least the current native gcc-2.95.3 doesn't have it. Otherwise
mt would have used the same wrong value of 28.
The difference is only explainable by the pack algorithm. The
cross compiler uses a default structure packing of 4 Bytes and
the native gcc a default packing of 8 Bytes, probably.
============= SNAP =============
Just a guess: Perhaps, the cross compiler uses the packing
algorithm of the HOST instead of the TARGET.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Developer mailto:firstname.lastname@example.org
Red Hat, Inc.
More information about the Cygwin-developers