Bug#493637: insserv_1.12.0-1(m68k/unstable): alignment issues.

2008-08-05 Thread Wouter Verhelst
On Tue, Aug 05, 2008 at 04:14:07PM +0200, Petter Reinholdtsen wrote: > [Wouter Verhelst] > > it's usually safe to trust the compiler to know what will be > > fastest. > > I agree. > > > Why have them in the first place? If you just remove them all, that > > will surely fix the issue. > > To me i

Bug#493637: insserv_1.12.0-1(m68k/unstable): alignment issues.

2008-08-05 Thread Petter Reinholdtsen
[Wouter Verhelst] > it's usually safe to trust the compiler to know what will be > fastest. I agree. > Why have them in the first place? If you just remove them all, that > will surely fix the issue. To me it is more a question of how to be sure all of them are removed in a way that get insserv

Bug#493637: insserv_1.12.0-1(m68k/unstable): alignment issues.

2008-08-05 Thread Wouter Verhelst
On Mon, Aug 04, 2008 at 10:09:07PM +0200, Petter Reinholdtsen wrote: > [Dr. Werner Fink] > > Beside speed there is no problem to drop the alignment. > > Nevertheless it is very strange that the struct re_pattern_buffer, > > the real type of regex_t, and found in /usr/include/regex.h is not > > alig

Bug#493637: insserv_1.12.0-1(m68k/unstable): alignment issues.

2008-08-04 Thread Petter Reinholdtsen
I got this reply from upstream regarding this issue: [Dr. Werner Fink] > Beside speed there is no problem to drop the alignment. > Nevertheless it is very strange that the struct re_pattern_buffer, > the real type of regex_t, and found in /usr/include/regex.h is not > aligned within power of 2. >

Bug#493637: insserv_1.12.0-1(m68k/unstable): alignment issues.

2008-08-04 Thread Wouter Verhelst
On Sun, Aug 03, 2008 at 08:55:23PM +0200, Petter Reinholdtsen wrote: > > If the issue is that you want to use these structs in a protocol of > > some sort or other, then it's probably best to use > > attribute(__packed__), which has the same effect as the above, but > > with the added benefit of th

Bug#493637: insserv_1.12.0-1(m68k/unstable): alignment issues.

2008-08-04 Thread Wouter Verhelst
On Mon, Aug 04, 2008 at 11:03:34AM +0200, Petter Reinholdtsen wrote: > > On m68k, some bits of memory must be aligned on a 2-byte boundary. The > > above makes that impossible. > > I notice all the other architectures handled this code. This make me > wonder if this could be seen as a bug in the

Bug#493637: insserv_1.12.0-1(m68k/unstable): alignment issues.

2008-08-04 Thread Petter Reinholdtsen
> On m68k, some bits of memory must be aligned on a 2-byte boundary. The > above makes that impossible. I notice all the other architectures handled this code. This make me wonder if this could be seen as a bug in the compiler on m68k. Why does it not calculate the required 2-byte alignment if i

Bug#493637: insserv_1.12.0-1(m68k/unstable): alignment issues.

2008-08-03 Thread Petter Reinholdtsen
> If the issue is that you want to use these structs in a protocol of > some sort or other, then it's probably best to use > attribute(__packed__), which has the same effect as the above, but > with the added benefit of the compiler generating some stubs in code > so that it can be safely accessed

Bug#493637: insserv_1.12.0-1(m68k/unstable): alignment issues.

2008-08-03 Thread wouter
Package: insserv Version: 1.12.0-1 Severity: important There was an error while trying to autobuild your package: > Automatic build of insserv_1.12.0-1 on arrakis by sbuild/m68k 98 > Build started at 20080801-0340 [...] > ** Using build dependencies supplied by package: > Build-Depends: debhelp