Can't you keep this struct private (in its own C file), and instead accessors to the few items you actually need to expose (would expect only the list of CLG_LogRecord ?)

This should also avoid the need to link ListBase headers here (we avoid as much as possible linking headers into other headers)

No need to init this to NULL since you already use calloc ;)

Please do not change that, using dereferenced pointer as size indicator is preferred way to do in Blender code (that way if you e.g. change type of ctx you do not risk missing to update that sizeof clause ).

better to use BLI_listbase_clear

This could be done in a (less verbose) for loop.

Also please use BLI_listbase_clear at the end

You should rather edit the relevant CMake file to add that intern module in the path? And also add build dependency on it, probably

Can switch those two, then you can use reports directly to get report

You probably want to change the type of report depending on type or severity of the log?

This looks very suspicious to me? You borrow reference of wm->reports into sinfo->active_reports, but then free them from the space data??? Think you should check in which mode the space info is at init time? Or at the very least add a comment stating that it is never in INFO_VIEW_G_CLOG in init function (if that is the case).

Also please set pointer to NULL after having freed the space data.

yes, definitively ;)

Please use a more generic name, not tied up to some specific internal tool (like e.g. INFO_VIEW_LOG

Should probably ensure that this is not NULL? At least with an BLI_assert if it ixs never expected to be.

Also, should ensure those reports were generated from clog, and not already from WM? You cannot really rely on this update call being only called from one specific RNA property change, seems very weak.

And finally, some other code in C might directly change the DNA value, completely by-passing the RNA update.

So what I would do here is:

• Handle this switch of reports source in spaceinfo update function.
• Store in spaceinfo the current source of its active_reports.
• use that info and current mode to know whether you need to update to active_reports, and free them first, etc. (in the space info update function).

then that RNA update callback should only tag the space info for update.

Think you need to free existing ones first here as well?

Why do you even need to expose this publicly actually?

it was only for clog_to_report_list. It will be unnecessary when I create access function for g_ctx->log_records

yes, this is todo

Which info update callback are you talking about?
It is callback in SpaceType draw or refresh?

• art->draw = info_main_region_draw;
• SpaceType->refresh

Or maybe I shall create new tag?

• WM_main_add_notifier(NC_SPACE | ND_SPACE_INFO_CHANGE_VIEW, log_record);
• or reuse existing tag ND_SPACE_INFO_REPORT and only check SpaceInfo->view and SpaceInfo->active_reports to check if source has changed