Hello,

Here's some trivial changes following Peter's call to arms against
free() and friends in gitlab issue #1798 in an attempt to enforce
our memory management guidelines [1].

We only have 2 "free()" occurences that needs fixing in the ppc tree.
The hard part is to be dilligent to to not introduce new ones.

Michael, feel free to take it via qemu-trivial.


[1] https://www.qemu.org/docs/master/devel/style.html#low-level-memory-management 

Daniel Henrique Barboza (2):
  hw/ppc: use g_free() in spapr_tce_table_post_load()
  target/ppc: use g_free() in test_opcode_table()

 hw/ppc/spapr_iommu.c   | 2 +-
 target/ppc/translate.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.41.0

On Fri, 28 Jul 2023 at 21:57, Daniel Henrique Barboza
<danielhb413@gmail.com> wrote:
> Here's some trivial changes following Peter's call to arms against
> free() and friends in gitlab issue #1798 in an attempt to enforce
> our memory management guidelines [1].

To clarify, this isn't a "call to arms". The issue is marked up as
a "bite-sized task", which is to say that it's a potential easy
place to start for newcomers to the community who might be making
their first contribution to the codebase. The changes it suggests
aren't urgent; at most they're a nice-to-have, since glib
guarantees that you can mix malloc/free and g_malloc/g_free.

We've had this sitting around as a suggestion on the wiki page
for bite-sized-tasks for years, and occasionally people come
through and have a go at it. I wanted to clean up and expand
on the description of what we had in mind for the change, to
give those people a better chance of successfully completing
the task.

thanks
-- PMM

On 7/29/23 12:35, Peter Maydell wrote:
> On Fri, 28 Jul 2023 at 21:57, Daniel Henrique Barboza
> <danielhb413@gmail.com> wrote:
>> Here's some trivial changes following Peter's call to arms against
>> free() and friends in gitlab issue #1798 in an attempt to enforce
>> our memory management guidelines [1].
> 
> To clarify, this isn't a "call to arms". The issue is marked up as
> a "bite-sized task", which is to say that it's a potential easy
> place to start for newcomers to the community who might be making
> their first contribution to the codebase. The changes it suggests
> aren't urgent; at most they're a nice-to-have, since glib
> guarantees that you can mix malloc/free and g_malloc/g_free.

I failed to realized it was a byte sized task :/ and my Coccinelle comment
in the bug makes me fell dumb hehe (given that Coccinelle is not newcomer
friendly).

> 
> We've had this sitting around as a suggestion on the wiki page
> for bite-sized-tasks for years, and occasionally people come
> through and have a go at it. I wanted to clean up and expand
> on the description of what we had in mind for the change, to
> give those people a better chance of successfully completing
> the task.

What we can do then, since I already sent these, is perhaps link these patches
as example/template in the gitlab issue later on.


Thanks,

Daniel

> 
> thanks
> -- PMM

30.07.2023 20:13, Daniel Henrique Barboza wrote:
> 
> 
> On 7/29/23 12:35, Peter Maydell wrote:
>> On Fri, 28 Jul 2023 at 21:57, Daniel Henrique Barboza
>> <danielhb413@gmail.com> wrote:
>>> Here's some trivial changes following Peter's call to arms against
>>> free() and friends in gitlab issue #1798 in an attempt to enforce
>>> our memory management guidelines [1].
>>
>> To clarify, this isn't a "call to arms". The issue is marked up as
>> a "bite-sized task", which is to say that it's a potential easy
>> place to start for newcomers to the community who might be making
>> their first contribution to the codebase. The changes it suggests
>> aren't urgent; at most they're a nice-to-have, since glib
>> guarantees that you can mix malloc/free and g_malloc/g_free.
> 
> I failed to realized it was a byte sized task :/ and my Coccinelle comment
> in the bug makes me fell dumb hehe (given that Coccinelle is not newcomer
> friendly).
> 
>>
>> We've had this sitting around as a suggestion on the wiki page
>> for bite-sized-tasks for years, and occasionally people come
>> through and have a go at it. I wanted to clean up and expand
>> on the description of what we had in mind for the change, to
>> give those people a better chance of successfully completing
>> the task.
> 
> What we can do then, since I already sent these, is perhaps link these patches
> as example/template in the gitlab issue later on.

Applied to my trivial-patches branch adding suggested commit comment
fixes while at it, hopefully there's nothing more to do :)

Thanks,

/mjt