[
https://issues.apache.org/jira/browse/MINIFICPP-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689490#comment-16689490
]
ASF GitHub Bot commented on MINIFICPP-645:
------------------------------------------
Github user phrocker commented on the issue:
https://github.com/apache/nifi-minifi-cpp/pull/439
> There is no delete, it was wrong before, this PR just fixes:
>
> ```
> void free_flowfile(flow_file_record *ff) {
> if (ff == nullptr) {
> return;
> }
> auto content_repo_ptr =
static_cast<std::shared_ptr<minifi::core::ContentRepository>*>(ff->crp);
> if (content_repo_ptr->get()) {
> std::shared_ptr<minifi::ResourceClaim> claim =
std::make_shared<minifi::ResourceClaim>(ff->contentLocation, *content_repo_ptr);
> (*content_repo_ptr)->remove(claim);
> }
> if (ff->ffp == nullptr) {
> auto map = static_cast<string_map*>(ff->attributes);
> delete map;
> }
> free(ff->contentLocation);
> free(ff);
> ```
> The last line is the one that frees.
Ah sorry, I was referencing the fact that over the course of PRs we've gone
back and forth a little between malloc/new. There is a free_flow(flow *) that
still uses delete. Happy to see a different PR if you prefer to do that, but it
all falls under the guise of this ticket IMO. Would you prefer I merge this and
then keep the ticket open as a blocker for the free? No real preference on my
part.
> Move from new to malloc in CAPI to facilitate eventual change from C++ to C
> ---------------------------------------------------------------------------
>
> Key: MINIFICPP-645
> URL: https://issues.apache.org/jira/browse/MINIFICPP-645
> Project: NiFi MiNiFi C++
> Issue Type: Improvement
> Reporter: Mr TheSegfault
> Assignee: Arpad Boda
> Priority: Blocker
> Labels: CAPI, nanofi
> Fix For: 0.6.0
>
>
> As gradually move to C we should move out of libminifi and remove the linter.
> Nothing that is returned via the API that is not an opaque pointer should use
> new, and conversely nothing that is passed in as a non-opaque pointer should
> be deleted versus freed
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)