From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id C5E134495C for ; Wed, 28 Sep 2022 09:35:25 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 9924268BBC4; Wed, 28 Sep 2022 12:35:23 +0300 (EEST) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.176]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id C239968B52E for ; Wed, 28 Sep 2022 12:35:16 +0300 (EEST) Received: from debian.lan (unknown [IPv6:2a00:66c0:a::72c]) by mail.frobbit.se (Postfix) with ESMTPSA id 2FCE020931 for ; Wed, 28 Sep 2022 11:35:16 +0200 (CEST) Message-ID: <82a446d0db78ab66aa9ba8353de585838ffefe0d.camel@haerdin.se> From: Tomas =?ISO-8859-1?Q?H=E4rdin?= To: FFmpeg development discussions and patches Date: Wed, 28 Sep 2022 11:35:15 +0200 In-Reply-To: References: <165778644704.15564.15015584182496894872@lain.khirnov.net> <165804661780.15564.263905578360823358@lain.khirnov.net> <3324e761a5215915b99679c51a97c2f2ec5a2b05.camel@acc.umu.se> Content-Type: multipart/mixed; boundary="=-83dJ7+8XTdw561lzMFvo" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH 3/8] avutil/mem: Add av_fast_realloc_array() X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --=-83dJ7+8XTdw561lzMFvo Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit tis 2022-09-27 klockan 17:23 +0200 skrev Tomas Härdin: > mån 2022-09-26 klockan 16:24 +0200 skrev Tomas Härdin: > > mån 2022-09-26 klockan 14:25 +0200 skrev Andreas Rheinhardt: > > > Anton Khirnov: > > > > Quoting Andreas Rheinhardt (2022-07-14 14:51:07) > > > > > Anton Khirnov: > > > > > > Quoting Andreas Rheinhardt (2022-07-12 16:12:16) > > > > > > > Anton really dislikes the av_fast_* naming and instead > > > > > > > wants > > > > > > > this to be > > > > > > > called av_realloc_array_reuse(). I don't care either way. > > > > > > > Any > > > > > > > more > > > > > > > opinions on this (or on the patch itself)? > > > > > > > > > > > > If people dislike _reuse(), I am open to other reasonable > > > > > > suggestions. > > > > > > This 'fast' naming sucks because > > > > > > - it tells you nothing about how this function is "fast" > > > > > > - it is added at the beginning rather than the end, which > > > > > > is > > > > > >   against standard namespacing conventions > > > > > > > > > > > > > > > > Isn't reusing the basic modus operandi for a reallocation > > > > > function? So > > > > > your suggested name doesn't seem to fit either. > > > > > > > > Ordinary realloc just keeps the data, I wouldn't call that > > > > "reuse" > > > > since > > > > it will often be a copy. This "fast" realloc OTOH reuses the > > > > actual > > > > buffer, same as all the other "fast" mem.h functions. > > > > > > > > But feel free to suggest another naming pattern if you can > > > > think > > > > of > > > > one. > > > > > > > > > > I see two differences between this function and ordinary realloc: > > > It > > > never shrinks the buffer and it overallocates. These two > > > properties > > > make > > > it more likely that these functions can avoid copies more often > > > than > > > plain realloc (but in contrast to realloc, we can not grow the > > > buffer > > > in > > > case there is free space after it), but it is nevertheless the > > > same > > > as > > > realloc. > > > > > > But I don't really care that much about the name and will > > > therefore > > > use > > > your name as I can't come up with anything better. > > > (Of course, I am still open to alternative suggestions.) > > > > > > - Andreas > > > > So this means av_realloc_array_reuse()? Eh, it works. I will add a > > function that also zeroes the newly allocated space, what should we > > call that? av_realloc_array_reusez()? > > av_realloc_array_reuse_zerofill()? > > Here's a draft patch that calls it av_reallocz_array_reuse(). Needs a > minor version bump of course This makes me realize something: av_realloc_array_reuse() requires that *nb_allocated == 0 initially but this isn't specified in the documentation. Patch attached relaxes this. /Tomas --=-83dJ7+8XTdw561lzMFvo Content-Disposition: attachment; filename*0=0001-lavu-mem-Do-not-require-nb_allocated-0-when-ptr-NULL.pat; filename*1=ch Content-Transfer-Encoding: base64 Content-Type: text/x-patch; name="0001-lavu-mem-Do-not-require-nb_allocated-0-when-ptr-NULL.patch"; charset="UTF-8" RnJvbSBkZjcyNjkxZjUxNGUyNDM3YjE5MTdkODA4YjZmY2QxNTNjMzkzYzIwIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/VG9tYXM9MjBIPUMzPUE0cmRpbj89IDxnaXRA aGFlcmRpbi5zZT4KRGF0ZTogV2VkLCAyOCBTZXAgMjAyMiAxMTozNDo0NSArMDIwMApTdWJqZWN0 OiBbUEFUQ0hdIGxhdnUvbWVtOiBEbyBub3QgcmVxdWlyZSAqbmJfYWxsb2NhdGVkID09IDAgd2hl biAqcHRyID09IE5VTEwKCi0tLQogbGliYXZ1dGlsL21lbS5jIHwgNiArKysrLS0KIDEgZmlsZSBj aGFuZ2VkLCA0IGluc2VydGlvbnMoKyksIDIgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvbGli YXZ1dGlsL21lbS5jIGIvbGliYXZ1dGlsL21lbS5jCmluZGV4IDc4MWRjYmFkZWQuLmJkMmVlMzQy ZmUgMTAwNjQ0Ci0tLSBhL2xpYmF2dXRpbC9tZW0uYworKysgYi9saWJhdnV0aWwvbWVtLmMKQEAg LTU2MSw3ICs1NjEsMTAgQEAgaW50IGF2X3JlYWxsb2NfYXJyYXlfcmV1c2Uodm9pZCAqcHRyLCBz aXplX3QgKm5iX2FsbG9jYXRlZCwKICAgICB2b2lkICphcnJheTsKICAgICBzaXplX3QgbmIsIG1h eF9hbGxvY19zaXplX2J5dGVzOwogCi0gICAgaWYgKG1pbl9uYiA8PSAqbmJfYWxsb2NhdGVkKQor ICAgIG1lbWNweSgmYXJyYXksIHB0ciwgc2l6ZW9mKGFycmF5KSk7CisKKyAgICAvLyBtYWtlIG5v IGRlbWFuZHMgb24gKm5iX2FsbG9jYXRlZCBpZiAqcHRyID09IE5VTEwKKyAgICBpZiAoYXJyYXkg JiYgbWluX25iIDw9ICpuYl9hbGxvY2F0ZWQpCiAgICAgICAgIHJldHVybiAwOwogCiAgICAgbWF4 X2FsbG9jX3NpemVfYnl0ZXMgPSBhdG9taWNfbG9hZF9leHBsaWNpdCgmbWF4X2FsbG9jX3NpemUs IG1lbW9yeV9vcmRlcl9yZWxheGVkKTsKQEAgLTU3MSw3ICs1NzQsNiBAQCBpbnQgYXZfcmVhbGxv Y19hcnJheV9yZXVzZSh2b2lkICpwdHIsIHNpemVfdCAqbmJfYWxsb2NhdGVkLAogICAgICAgICBy ZXR1cm4gQVZFUlJPUihFUkFOR0UpOwogCiAgICAgbmIgPSBjb21wdXRlX25iKG1pbl9uYiwgbWF4 X25iKTsKLSAgICBtZW1jcHkoJmFycmF5LCBwdHIsIHNpemVvZihhcnJheSkpOwogCiAgICAgYXJy YXkgPSBhdl9yZWFsbG9jKGFycmF5LCBuYiAqIGVsc2l6ZSk7CiAgICAgaWYgKCFhcnJheSkKLS0g CjIuMzAuMgoK --=-83dJ7+8XTdw561lzMFvo Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --=-83dJ7+8XTdw561lzMFvo--