Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Stefano Sabatini <stefasab@gmail.com>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 1/3] avutil/dict: add av_dict_pop
Date: Fri, 26 May 2023 08:05:44 +0200
Message-ID: <20230526060544.GB3241@mariano> (raw)
In-Reply-To: <8CA999C7-1502-4FAB-ACD9-9BC02ED68058@gmail.com>

On date Monday 2023-05-22 11:23:24 +0200, Marvin Scholz wrote:
> On 22 May 2023, at 1:52, Stefano Sabatini wrote:
> 
> > On date Monday 2023-05-01 13:44:54 +0200, Marvin Scholz wrote:
> >> This new API allows to remove an entry and obtain ownership of the
> >> key/value that was associated with the removed entry.
> 
> Thanks for the review!
> 
> >> ---
> >>  doc/APIchanges         |  4 ++++
> >>  libavutil/dict.c       | 27 +++++++++++++++++++++++++++
> >>  libavutil/dict.h       | 20 ++++++++++++++++++++
> >>  libavutil/tests/dict.c | 34 ++++++++++++++++++++++++++++++++++
> >>  libavutil/version.h    |  2 +-
> >>  tests/ref/fate/dict    | 12 ++++++++++++
> >>  6 files changed, 98 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/doc/APIchanges b/doc/APIchanges
> >> index 0b609e3d3b..5b807873b7 100644
> >> --- a/doc/APIchanges
> >> +++ b/doc/APIchanges
> >> @@ -2,6 +2,10 @@ The last version increases of all libraries were on 2023-02-09
> >>
> >>  API changes, most recent first:
> >>
> >> +2023-04-29 - xxxxxxxxxx - lavu 58.7.100 - dict.c
> >> +  Add av_dict_pop() to remove an entry from a dict
> >> +  and get ownership of the removed key/value.
> >> +
> >>  2023-04-10 - xxxxxxxxxx - lavu 58.6.100 - frame.h
> >>    av_frame_get_plane_buffer() now accepts const AVFrame*.
> >>
> >> diff --git a/libavutil/dict.c b/libavutil/dict.c
> >> index f673977a98..ac41771994 100644
> >> --- a/libavutil/dict.c
> >> +++ b/libavutil/dict.c
> >> @@ -173,6 +173,33 @@ int av_dict_set_int(AVDictionary **pm, const char *key, int64_t value,
> >>      return av_dict_set(pm, key, valuestr, flags);
> >>  }
> >>
> >> +int av_dict_pop(AVDictionary **pm, const char *key,
> >> +                char **out_key, char **out_value, int flags)
> >> +{
> >> +    AVDictionary *m = *pm;
> >> +    AVDictionaryEntry *entry = NULL;
> >> +    entry = (AVDictionaryEntry *)av_dict_get(m, key, NULL, flags);
> >> +    if (!entry)
> >> +        return AVERROR(ENOENT);
> >> +
> >> +    if (out_key)
> >> +        *out_key = entry->key;
> >> +    else
> >> +        av_free(entry->key);
> >> +
> >> +    if (out_value)
> >> +        *out_value = entry->value;
> >> +    else
> >> +        av_free(entry->value);
> >> +
> >> +    *entry = m->elems[--m->count];
> >
> >> +    if (m && !m->count) {
> >> +        av_freep(&m->elems);
> >> +        av_freep(pm);
> >> +    }
> >
> > I'm not sure this is the right behavior. Should we clear the
> > dictionary when it is empty? What if you need to refill it later?
> >
> 

> Thats the same behaviour as if you use av_dict_set to remove all items
> and IMO this should be consistent.

> Additionally NULL means an empty AVDictionary, suddenly
> having a non-NULL but empty dictionary seems like a very bad idea.

Sorry for the slow reply, I see.

[...]
> >> +/**
> >> + * Remove the entry with the given key from the dictionary.
> >> + *
> >
> >> + * Search for an entry matching `key` and remove it, if found. Optionally
> >
> > Not sure the `foo` syntax is supported by doxygen (and probably we
> > should eschew it for consistency with the other doxys).
> >
> 
> I tested it locally and it works fine and its much more readable than the
> alternatives.
> 
> However if you feel it should be removed I am happy to do that, I have no
> strong opinions there.

Please let's avoid to add more syntax variance (also I'm not sure when
the `var` syntax was introduced).

[...]

Should we also support the case with multiple same-key values?

Also maybe we should mention that this operation might alterate the
order of the entries (unless we add a new flag to shift the
trailing data when an entry is removed).

Another general question, since I see that dict.h is deprecated, do
you think it might be possible to switch to tree.h?
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

  reply	other threads:[~2023-05-26  6:05 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-01 11:44 Marvin Scholz
2023-05-01 11:44 ` [FFmpeg-devel] [PATCH 2/3] avformat/tee: use av_dict_pop Marvin Scholz
2023-06-25 12:07   ` "zhilizhao(赵志立)"
2023-05-01 11:44 ` [FFmpeg-devel] [PATCH 3/3] avutil/dict: constify av_dict_get return Marvin Scholz
2023-06-05 10:05   ` Anton Khirnov
2023-05-21 23:52 ` [FFmpeg-devel] [PATCH 1/3] avutil/dict: add av_dict_pop Stefano Sabatini
2023-05-22  9:23   ` Marvin Scholz
2023-05-26  6:05     ` Stefano Sabatini [this message]
2023-05-26  9:11       ` Marvin Scholz
2023-05-26 20:02         ` Michael Niedermayer
2023-05-26 20:51           ` Marvin Scholz
2023-05-26 20:06         ` James Almer
2023-06-04 14:25         ` Stefano Sabatini
2023-06-04 14:34           ` Marvin Scholz
2023-06-05  8:08             ` Stefano Sabatini
2023-06-05 10:09               ` Anton Khirnov
2023-06-05 10:04 ` Anton Khirnov
2023-06-25 10:49 ` [FFmpeg-devel] [PATCH v2 " Marvin Scholz
2023-06-25 10:49   ` [FFmpeg-devel] [PATCH v2 2/3] avformat/tee: use av_dict_pop Marvin Scholz
2023-07-02  8:47     ` Stefano Sabatini
2023-06-25 10:49   ` [FFmpeg-devel] [PATCH v2 3/3] avutil/dict: constify av_dict_get return Marvin Scholz
2023-07-02  9:06     ` Stefano Sabatini
2023-07-02  8:43   ` [FFmpeg-devel] [PATCH v2 1/3] avutil/dict: add av_dict_pop Stefano Sabatini
2023-07-02 11:49     ` Marvin Scholz
2023-07-03  0:18   ` Andreas Rheinhardt
2023-07-03  9:11     ` Marvin Scholz
2023-07-03 18:02       ` Andreas Rheinhardt
2023-07-03 22:41         ` Marvin Scholz
2023-10-20  8:18         ` Anton Khirnov
2023-10-20 14:00           ` Andreas Rheinhardt
2023-10-20 14:33             ` Anton Khirnov
2023-10-20 15:42               ` Andreas Rheinhardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230526060544.GB3241@mariano \
    --to=stefasab@gmail.com \
    --cc=ffmpeg-devel@ffmpeg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git