Bug#442854: hex-a-hop: [m68k] FTBFS: packfile.h:57: error: size of array 'static_assert1' is negative

[Jens Seidel]

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