Dale Johannesen wrote:
> This is wrong, because 4 bytes starting at 73 goes outside the original
> object and can
> cause a page fault.
FYI You can write a testcase for this by using mmap to allocate a page
of memory, putting a copy of the structure 76 bytes from the end of the
mmapped region, and
Dale Johannesen <[EMAIL PROTECTED]> writes:
> The test of f->b comes out as
>
>testl $1048512, 73(%eax)
>
> This is wrong, because 4 bytes starting at 73 goes outside the
> original object and can
> cause a page fault. The change from referencing a word at offset 72
> to offset 73
> happen
* Florian Weimer:
> * Dale Johannesen:
>
>> The test of f->b comes out as
>>
>> testl $1048512, 73(%eax)
>>
>> This is wrong, because 4 bytes starting at 73 goes outside the
>> original object and can cause a page fault.
>
> sizeof (struct Flags) is 76, so this isn't a bug, IMHO.
Scratch that,
* Dale Johannesen:
> The test of f->b comes out as
>
> testl $1048512, 73(%eax)
>
> This is wrong, because 4 bytes starting at 73 goes outside the
> original object and can cause a page fault.
sizeof (struct Flags) is 76, so this isn't a bug, IMHO.
The following demonstrates a bug in combine
(x86 -mtune=pentiumpro -O2):
struct Flags {
int filler[18];
unsigned int a:14;
unsigned int b:14;
unsigned int c:1;
unsigned int d:1;
unsigned int e:1;
unsigned int f:1;
};
extern int bar(int), baz();
int foo (struct Flags *f) {
if (f->
