Christian König in fact the compiler will very often replace {0} with
a memset call. I don't see a problem using {0} for local arrays with
primitive types.
There should also be no problem with memory alignment. Because the
compiler understands it. Using sizeof is also not a good idea.
More often everyone also makes mistakes with sizeof. It's best to
leave it as is, and there's no errors.
Indeed, when using structures and {0}, errors may occur, but I am not
aware of errors when using primitive types. I also looked at the
amdgpu code and {0} is used in many places.
Also from experience malloc+memset is the most dangerous chain, can
silently damage memory, causing a bunch of subtle problems, and it is
better to replace them with more safe calloc.
Such a problem, for example, was recently found by me in fontconfig
and it crashed intel quartus. Therefore, where possible, I try to
avoid memset.
Regards, Grigory.
ср, 6 апр. 2022 г. в 17:43, Christian König <christian.koenig@xxxxxxx>:
>
> Am 06.04.22 um 16:26 schrieb Jani Nikula:
> > On Tue, 05 Apr 2022, Christian König <christian.koenig@xxxxxxx> wrote:
> >> Am 05.04.22 um 19:36 schrieb Grigory Vasilyev:
> >>> Using memset on local arrays before exiting the function is pointless.
> >>> Compilator will remove this code. Also for local arrays is preferable to
> >>> use {0} instead of memset. Mistakes are often made when working with
> >>> memset.
> >> Well actually memset is preferred when working with structures which are
> >> given to the hardware parser because {0} won't initialize paddings.
> > Not that I'd know anything that's going on here... but it sure seems
> > strange to me to be passing unpacked structures where the padding might
> > matter to a "hardware parser".
>
> Well to me it is an absolute miracle why the heck compilers don't
> initialize paddings.
>
> We had so many ups moments over the years and I really don't see why it
> should be more optimal to do this.
>
> Anyway, the memset() is used intentionally here and I don't really want
> to change it. What we could do is removing the second superfluous memset
> and use sizeof() instead of hard coding the size.
>
> Regards,
> Christian.
>
> >
> > *shrug*
> >
> >
> > BR,
> > Jani.
> >
> >
> >> So please don't use {0} in any of the atom bios code.
> >>
> >> Regards,
> >> Christian.
> >>
> >>> Signed-off-by: Grigory Vasilyev <h0tc0d3@xxxxxxxxx>
> >>> ---
> >>> drivers/gpu/drm/amd/amdgpu/atom.c | 8 +-------
> >>> 1 file changed, 1 insertion(+), 7 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c b/drivers/gpu/drm/amd/amdgpu/atom.c
> >>> index be9d61bcb8ae..537e48fbbe6b 100644
> >>> --- a/drivers/gpu/drm/amd/amdgpu/atom.c
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/atom.c
> >>> @@ -1538,11 +1538,9 @@ struct atom_context *amdgpu_atom_parse(struct card_info *card, void *bios)
> >>> int amdgpu_atom_asic_init(struct atom_context *ctx)
> >>> {
> >>> int hwi = CU16(ctx->data_table + ATOM_DATA_FWI_PTR);
> >>> - uint32_t ps[16];
> >>> + uint32_t ps[16] = {0};
> >>> int ret;
> >>>
> >>> - memset(ps, 0, 64);
> >>> -
> >>> ps[0] = cpu_to_le32(CU32(hwi + ATOM_FWI_DEFSCLK_PTR));
> >>> ps[1] = cpu_to_le32(CU32(hwi + ATOM_FWI_DEFMCLK_PTR));
> >>> if (!ps[0] || !ps[1])
> >>> @@ -1551,10 +1549,6 @@ int amdgpu_atom_asic_init(struct atom_context *ctx)
> >>> if (!CU16(ctx->cmd_table + 4 + 2 * ATOM_CMD_INIT))
> >>> return 1;
> >>> ret = amdgpu_atom_execute_table(ctx, ATOM_CMD_INIT, ps);
> >>> - if (ret)
> >>> - return ret;
> >>> -
> >>> - memset(ps, 0, 64);
> >>>
> >>> return ret;
> >>> }
>
