On Mon, Sep 17, 2007 at 04:57:11PM +0200, Bas Wijnen wrote:
> On Mon, Sep 17, 2007 at 03:34:25PM +0200, Jens Seidel wrote:
> >
> > I do not have access to a m68k machine. Bas, could you please provide
> > the output of typeof(Entry), where Entry is defined in packfile.h?
>
> I don't have one either, but I can see if I may be able to get the test
I thought developers have access to all kind of machines to be able to
port and test ...
OK, I need to first investigate how
class Entry {
int32_t len;
char name[1];
}
is structured on i386. Is it
octet1 >
octet2 > of
octet3 > len
octet4 >
name[0]
unused
unused
unused
or
octet1 >
octet2 > of
octet3 > len
octet4 >
unused
unused
unused
name[0]
? After this I can do the padding.
> I saw the problem because I just browsed the buildd logs of my
> (maintained and sponsored) packages.
OK. I saw a problem on the Hurd as well. It's the typical Hurd problem:
there exist no maximal path length, everything is unrestricted ...
> If you know sizes, you can use this notation (this creates a struct
> where the 32-bit value is not 32-bit-aligned):
>
> struct descriptor_register
> {
> unsigned limit : 16;
> unsigned base : 32 __attribute__((packed));
> unsigned padding : 16;
> };
Ah, thanks. This will probably work. But __attribute__((packed)) looks
gcc specific :-(
> > The problem is that hex-a-hop reads a char data stream and interprets it as
> > an array of type Entry. I knew that this could cause trouble so I added the
> > assert test.
>
> Sounds like it's better to rewrite the parsing from "compiler, this here
> is an array of these things" to manually parsing the data and filling
> the array. Reading binary data directly from disk is a very good way to
> get non-portable programs. ;-)
Right! But first I want to fix it using the current code to see what
problems occur if binary data is used.
I did already byte (or octet??) swapping, int->int32_t and now I will
also add paddings. This should be the last issue I hope.
> But I think I already heard you mention something like that before, and
> it was too hard to fix it all in patches, right? If upstream isn't
> interested/responding, then a fork may be a good idea...
Not too hard, it was just the first time I did it. I know for sure that
reading/writing text files doesn't has these problems. Maybe XML will be
the solution.
> > Is the build machine a 64 bit system?
>
> I know nothing more about it than what's on the website. I don't think
> m68k machines are 64 bit, but I'm not very familiar with them.
But it should also not 16 bit, I assume. So why does this machine have a
different alignment from other 32 (and 64 bit!) cpus?
I will ask on a porter list for help and create a test case ...
> If there's no other way, I think I can get shell access to a Debian
> machine, I'm not sure how complex it is to arrange that.
This is what I assumed :-)
Jens
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
