On Tue, 4 Apr 2006, Joerg Schilling wrote:
JS>Steve Bennett <[EMAIL PROTECTED]> wrote:
JS>
JS>> I don't think unspecified means irrelevant.
JS>>
JS>> >
JS>> > struct test2 {
JS>> > char blerg[1];
JS>> > char type[4];
JS>> > char flibble[3];
JS>> > char more[2];
JS>> > char dummy[1];
Steve Bennett <[EMAIL PROTECTED]> wrote:
> I don't think unspecified means irrelevant.
>
> >
> > struct test2 {
> > char blerg[1];
> > char type[4];
> > char flibble[3];
> > char more[2];
> > char dummy[1];
> > };
>
> And the result:
>
> sizeof(test1) is 12
> offsetof(t
Steve Bennett <[EMAIL PROTECTED]> wrote:
> Results below.
>
> Joerg Schilling wrote:
> > Steve Bennett <[EMAIL PROTECTED]> wrote:
> >
> >
> >>Bad news!
> >>
> >>sizeof(test1) is 12
> >>offsetof(test1, more) is 8
> >>offsetof(test1, dummy) is 10
> >>
> >>I suppose this is the bit you are referrin
Results below.
Joerg Schilling wrote:
Steve Bennett <[EMAIL PROTECTED]> wrote:
Bad news!
sizeof(test1) is 12
offsetof(test1, more) is 8
offsetof(test1, dummy) is 10
I suppose this is the bit you are referring to:
the size
of the structure shall be equal to the offset of the last
el
Steve Bennett <[EMAIL PROTECTED]> wrote:
> Bad news!
>
> sizeof(test1) is 12
> offsetof(test1, more) is 8
> offsetof(test1, dummy) is 10
>
> I suppose this is the bit you are referring to:
> > the size
> > of the structure shall be equal to the offset of the last
> > element of an otherw
Bad news!
sizeof(test1) is 12
offsetof(test1, more) is 8
offsetof(test1, dummy) is 10
I suppose this is the bit you are referring to:
the size
of the structure shall be equal to the offset of the last
element of an otherwise identical structure that replaces
the flexible array
Steve Bennett <[EMAIL PROTECTED]> wrote:
> Bad news!
>
> sizeof(test1) is 12
> offsetof(test1, more) is 8
> offsetof(test1, dummy) is 10
>
> I suppose this is the bit you are referring to:
> > the size
> > of the structure shall be equal to the offset of the last
> > element of an otherw
Steve McIntyre <[EMAIL PROTECTED]> wrote:
> >> And just in case you are wondering, I ran all those previous tests again
> >> with -std=c99 with exactly the same results.
> >
> >Thank you for the test!
> >
> >So GCC is in clear violation with the C-99 standard.
>
> Which part of the C-99 standard,
On Thu, Mar 30, 2006 at 01:03:15AM +0200, Joerg Schilling wrote:
>Steve Bennett <[EMAIL PROTECTED]> wrote:
>
>> > After reading the C-99 Standard, it turned out that the last method
>> > is the "official" way to prevent tail padding of structures.
>> >
>> > Could you please run the last test agai
Steve Bennett <[EMAIL PROTECTED]> wrote:
> > After reading the C-99 Standard, it turned out that the last method
> > is the "official" way to prevent tail padding of structures.
> >
> > Could you please run the last test again but use:
> >
> > #pragma pack(1)
> >
> > struct test1
> > {
> >
Answers below
Joerg Schilling wrote:
Steve Bennett <[EMAIL PROTECTED]> wrote:
#include
struct test1
{
char blerg[1];
char type[4];
char flibble[3];
char more[2];
} __attribute__((packed));
_Pragma("pack(1)") struct test2
{
char blerg[1];
char type[4];
char flibble[3];
Steve Bennett <[EMAIL PROTECTED]> wrote:
> > #include
> >
> > struct test1
> > {
> > char blerg[1];
> > char type[4];
> > char flibble[3];
> > char more[2];
> > } __attribute__((packed));
> >
> > _Pragma("pack(1)") struct test2
> > {
> > char blerg[1];
> > char type[4];
Joerg Schilling wrote:
Steve Bennett <[EMAIL PROTECTED]> wrote:
Joerg,
I can't quite see where you are going with all this.
Could you run another test?
Sure.
#include
struct test1
{
char blerg[1];
char type[4];
char flibble[3];
char more[2];
} __attribute__((packed));
Steve Bennett <[EMAIL PROTECTED]> wrote:
> Joerg,
>
> I can't quite see where you are going with all this.
Could you run another test?
#include
struct test1
{
char blerg[1];
char type[4];
char flibble[3];
char more[2];
} __attribute__((packed));
_Pragma("pack(1)") struct test2
Steve Bennett <[EMAIL PROTECTED]> wrote:
> Joerg,
>
> I can't quite see where you are going with all this.
>
> I think we have explained quite clearly the behaviour of the GCC compiler on
> the arm platform.
>
> If you don't like any of our proposed solutions, that's fine.
> Please fix it *any* wa
Joerg,
I can't quite see where you are going with all this.
I think we have explained quite clearly the behaviour of the GCC compiler on
the arm platform.
If you don't like any of our proposed solutions, that's fine.
Please fix it *any* way you like, just so long as it works for the arm-gcc
(wh
Steve McIntyre <[EMAIL PROTECTED]> wrote:
> >I would call this default behavior of GCC a bug.
> >
> >I'll try to verify this with the C99 standard, but in case GCC is able
> >to create working code at all (using __attribute__((packed))), it seems like
> >the default behavior does not make sense.
On Tue, Mar 28, 2006 at 12:19:41AM +0200, Joerg Schilling wrote:
>Steve McIntyre <[EMAIL PROTECTED]> wrote:
>>
>> As the link that I posted up-thread said, #pragma pack(1) does not
>> force alignment within a structure on arm, as that would clash with
>> the arm ABI. If you _must_ do things that wa
Steve McIntyre <[EMAIL PROTECTED]> wrote:
> From the forst text from you, I asume that the problem is that the size
> >of char[4] is not 4 but 16.
>
> No, it's not.
>
> >So where is the real problem?
>
> Quick demonstration:
>
> 1. gcc on an i386 box:
>
> smcintyre:~$ gcc -v
> Reading specs from /
On Fri, Mar 24, 2006 at 06:03:49PM +0100, Joerg Schilling wrote:
>Steve Bennett <[EMAIL PROTECTED]> wrote:
>
>> Joerg Schilling wrote:
>> > Did you test with a recent GCC using
>> >
>> > #pragma pack(1)
>> >
>> > I would expect that this also results in reduced sizes.
>>
>> Yes, I certainly hav
Steve Bennett <[EMAIL PROTECTED]> wrote:
> Joerg Schilling wrote:
> > Did you test with a recent GCC using
> >
> > #pragma pack(1)
> >
> > I would expect that this also results in reduced sizes.
>
> Yes, I certainly have tested it (and Steve said he had too).
> It does not work.
"Does not wor
Joerg Schilling wrote:
Did you test with a recent GCC using
#pragma pack(1)
I would expect that this also results in reduced sizes.
Yes, I certainly have tested it (and Steve said he had too).
It does not work.
gcc -dumpversion
4.0.3
Which is just about as recent as it gets.
I believe
Steve Bennett <[EMAIL PROTECTED]> wrote:
> Sure, I'm happy to provide some feedback.
>
> You might say that the real problem is the arm gcc compiler.
No, processors that have been originally designed for DSP purposes, it is not
uncommon to have e.g. 24 bit "bytes".
> For whatever reason, it re
Sure, I'm happy to provide some feedback.
You might say that the real problem is the arm gcc compiler.
For whatever reason, it really likes to align things on 4 byte boundaries,
and pad structures to 4 byte boundaries, even where most other compilers don't.
(Such as the char arrays in the struct
Steve McIntyre <[EMAIL PROTECTED]> wrote:
> >But I would prefer to use standard C constructs:
> >
> >#pragma pack(1)
>
> Unfortunately, #pragma pack(1) doesn't fix the problem - I've just
> tested it on an arm machine here. __attribute__(packed) _does_ fix the
> problem. See http://lists.debian.or
Steve McIntyre <[EMAIL PROTECTED]> wrote:
> >But I would prefer to use standard C constructs:
> >
> >#pragma pack(1)
>
> Unfortunately, #pragma pack(1) doesn't fix the problem - I've just
> tested it on an arm machine here. __attribute__(packed) _does_ fix the
> problem. See http://lists.debian.or
On Wed, Mar 22, 2006 at 07:10:01PM +0100, Joerg Schilling wrote:
>"Adam D. Barratt" <[EMAIL PROTECTED]> wrote:
>
>> > From the viewpoint of C, there is no macro but just superfluous text.
>>
>> No, there's a macro. Specifically defined by
>>
>> #ifndef __GNUC__
>> #define __attribute__(X)
>> #endif
"Adam D. Barratt" <[EMAIL PROTECTED]> wrote:
> > From the viewpoint of C, there is no macro but just superfluous text.
>
> No, there's a macro. Specifically defined by
>
> #ifndef __GNUC__
> #define __attribute__(X)
> #endif
OOps, it seems I did oversee this.
Then it may make sense to think abou
On Wednesday, March 22, 2006 4:36 PM, Joerg Schilling
<[EMAIL PROTECTED]> wrote:
> Steve McIntyre <[EMAIL PROTECTED]> wrote:
>
>>> If you believe that this is a C preprocessor issue, then you seem
>>> to m=ss the needed knowledge in programming.
>>>
>>> The patch in question tries to add code that
Steve McIntyre <[EMAIL PROTECTED]> wrote:
> >If you believe that this is a C preprocessor issue, then you seem to miss
> >the
> >needed knowledge in programming.
> >
> >The patch in question tries to add code that is not valid C.
> >
> >I am not willing to add code that prevents compilation beca
Steve McIntyre <[EMAIL PROTECTED]> wrote:
> >I don't need logs in order to identify code that is not written in C.
> >
> >I asume that you understand C too, so it should be easy for you to
> >understand why this patch causes the compilation to fail on a C-Compiler.
>
> The only way this patch coul
On Wed, Mar 22, 2006 at 03:18:41PM +0100, Joerg Schilling wrote:
>Steve McIntyre <[EMAIL PROTECTED]> wrote:
>
>> >I don't need logs in order to identify code that is not written in C.
>> >
>> >I asume that you understand C too, so it should be easy for you to
>> >understand why this patch causes th
On Tue, Mar 21, 2006 at 05:12:08PM +0100, Joerg Schilling wrote:
>Steve McIntyre <[EMAIL PROTECTED]> wrote:
>
>> On Sat, Mar 18, 2006 at 01:35:03PM +0100, Joerg Schilling wrote:
>> >Patches that cause the compilation to fail anywhere except on Linux
>> >have no chance for getting included - sorry.
Steve McIntyre <[EMAIL PROTECTED]> wrote:
> On Sat, Mar 18, 2006 at 01:35:03PM +0100, Joerg Schilling wrote:
> >Patches that cause the compilation to fail anywhere except on Linux
> >have no chance for getting included - sorry.
>
> Please post logs showing compilation failing somewhere else and we
On Sat, Mar 18, 2006 at 01:35:03PM +0100, Joerg Schilling wrote:
>Patches that cause the compilation to fail anywhere except on Linux
>have no chance for getting included - sorry.
Please post logs showing compilation failing somewhere else and we'll
fix the patch.
--
Steve McIntyre, Cambridge, U
Patches that cause the compilation to fail anywhere except on Linux
have no chance for getting included - sorry.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.
Package: mkisofs
Version: 4:2.01+01a03-5
Severity: normal
/tmp/reportbug-mkisofs-20060206-3618-5vNNYZ
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: arm (armv5tel)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.
37 matches
Mail list logo
