[SLOF] [PATCH 1/4] romfs/tools: Remove superfluous union around the rom header struct
Alexey Kardashevskiy
aik at ozlabs.ru
Fri Jul 20 13:35:14 AEST 2018
On 20/7/18 2:43 am, Segher Boessenkool wrote:
> On Thu, Jul 19, 2018 at 07:34:24PM +1000, Alexey Kardashevskiy wrote:
>> On 19/7/18 12:35 am, Segher Boessenkool wrote:
>>> On Wed, Jul 18, 2018 at 02:41:41PM +0200, Thomas Huth wrote:
>>>> - union {
>>>> - unsigned char pcArray[FLASHFS_HEADER_DATA_SIZE];
>>>> - struct stH stHeader;
>>>> - } uHeader;
>>>> + struct stH stHeader;
>>>> +
>>>> + assert(sizeof(stHeader) == FLASHFS_HEADER_DATA_SIZE);
>>>>
>>>> /* initialize Header */
>>>> - memset(uHeader.pcArray, 0x00, FLASHFS_HEADER_DATA_SIZE);
>>>> + memset(&stHeader, 0x00, FLASHFS_HEADER_DATA_SIZE);
>>>
>>> It would be nice to have a build-time assert for this.
>>>
>>> You can also get rid of this explicit memset by doing this as
>>>
>>> assert(sizeof(stHeader) == FLASHFS_HEADER_DATA_SIZE);
>>>
>>> struct stH stHeader = { 0 } ;
>>
>>
>> I do not really know where this flashfs/romfs format came from so I'll
>> simply ask why precisely we want this assert? Increasing
>> FLASHFS_HEADER_DATA_SIZE to 0x88 does not make any difference as the
>> header size is stored in a file header (is that even correct thing to say?)?
>
> The code is treating some binary data as a C struct. Not a good idea at all,
Besides missing "__attribute__ ((packed))", what is wrong with that?
> but yes it helps to verify the sizes! And the offsets, and the endianness,
> and that there is no padding anywhere, etc.
But the size itself does not matter there at all, why to stick to a
certain value? If we do not want the header to be too big, then there is
check with (mistyped) "Header File to long".
--
Alexey
More information about the SLOF
mailing list