Re: [Qemu-devel] Re: [PATCH 07/17] block/vvfat.c: fix warnings with _FORTIFY_SOURCE

[Markus Armbruster]

[Some quoted material restored]

"Kirill A. Shutemov" <address@hidden> writes:

> On Wed, Jan 20, 2010 at 3:03 PM, Markus Armbruster <address@hidden> wrote:
>> "Kirill A. Shutemov" <address@hidden> writes:
>>> On Wed, Jan 20, 2010 at 2:15 PM, Markus Armbruster <address@hidden> wrote:
>>>> Kevin Wolf <address@hidden> writes:
>>>>> Regardless if deliberately overflowing the buffer works or doesn't
>>>>> making it explicit is better. Someone might reorder the struct or add
>>>>> new fields in between (okay, unlikely in this case, but still) and
>>>>> you'll overflow into fields you never wanted to touch.
>>>>
>>>> Moreover, compilers are free to put padding between members name and
>>>> extension.
>>>
>>> No, compiler can't add anything between. 'char' is always byte-aligned.
>>
>> You got some reading to do then.
>
> Do you want to say that it's not true? Could you provide an example
> when 'char' isn't byte-aligned?

I was wrong, because I overlooked __attribute__((packed)).

ISO/IEC 9899:1999 6.7.2.1 guarantees a number of things for structs,
chiefly members stay in order, no padding before the first member.  But
it does not restrict padding between members or at the end in any way,
so compilers may pad there how they see fit.  In particular, there is no
rule that a compiler may only add padding to satisfy the next member's
alignment requirement.

__attribute__((packed)) tightens the spec to eliminate padding.

Regardless, the deliberate buffer overflow to hopefully save a few bytes
and cycles is a dirty, brittle trick for no good reason.  If this really
must be hand-optimized (numbers, please), do it cleanly, the way Dan
suggested.