Message ID | 20170402224444.57210-1-lq@chinaffmpeg.org |
---|---|
State | Accepted |
Commit | 44cd7502c739a97f9b37319f208e1bcc5b1899fd |
Headers | show |
Le quartidi 14 germinal, an CCXXV, Steven Liu a écrit : > change name from av_strreplace to av_strireplace > Use AVBprint to implement av_strireplace > add av_strireplace test case TEST_STRIREPLACE > > Signed-off-by: Steven Liu <lq@chinaffmpeg.org> > --- > libavutil/avstring.c | 76 +++++++--------------------------------------- > libavutil/avstring.h | 2 +- > libavutil/tests/avstring.c | 16 ++++++++++ > 3 files changed, 28 insertions(+), 66 deletions(-) This version looks fine to me. Maybe wait a little more for advice about the rename and the whole thing. Thanks.
2017-04-03 20:32 GMT+08:00 Nicolas George <george@nsup.org>: > Le quartidi 14 germinal, an CCXXV, Steven Liu a écrit : > > change name from av_strreplace to av_strireplace > > Use AVBprint to implement av_strireplace > > add av_strireplace test case TEST_STRIREPLACE > > > > Signed-off-by: Steven Liu <lq@chinaffmpeg.org> > > --- > > libavutil/avstring.c | 76 +++++++----------------------- > ---------------- > > libavutil/avstring.h | 2 +- > > libavutil/tests/avstring.c | 16 ++++++++++ > > 3 files changed, 28 insertions(+), 66 deletions(-) > > This version looks fine to me. > > Maybe wait a little more for advice about the rename and the whole > thing. > > Thanks. > > -- > Nicolas George > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > ping
On 4/5/2017 11:05 AM, Steven Liu wrote: > 2017-04-03 20:32 GMT+08:00 Nicolas George <george@nsup.org>: > >> Le quartidi 14 germinal, an CCXXV, Steven Liu a écrit : >>> change name from av_strreplace to av_strireplace >>> Use AVBprint to implement av_strireplace >>> add av_strireplace test case TEST_STRIREPLACE >>> >>> Signed-off-by: Steven Liu <lq@chinaffmpeg.org> >>> --- >>> libavutil/avstring.c | 76 +++++++----------------------- >> ---------------- >>> libavutil/avstring.h | 2 +- >>> libavutil/tests/avstring.c | 16 ++++++++++ >>> 3 files changed, 28 insertions(+), 66 deletions(-) >> >> This version looks fine to me. >> >> Maybe wait a little more for advice about the rename and the whole >> thing. >> >> Thanks. >> >> -- >> Nicolas George >> >> _______________________________________________ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> > ping You can't rename the function. It's already in the 3.3 branch. This is one of the reasons why giving people enough time for reviews is a must before pushing new public symbols. The rest should be ok since Nicolas reviewed it.
On Wed, 5 Apr 2017, James Almer wrote: > On 4/5/2017 11:05 AM, Steven Liu wrote: >> 2017-04-03 20:32 GMT+08:00 Nicolas George <george@nsup.org>: >> >>> Le quartidi 14 germinal, an CCXXV, Steven Liu a écrit : >>>> change name from av_strreplace to av_strireplace >>>> Use AVBprint to implement av_strireplace >>>> add av_strireplace test case TEST_STRIREPLACE >>>> >>>> Signed-off-by: Steven Liu <lq@chinaffmpeg.org> >>>> --- >>>> libavutil/avstring.c | 76 +++++++----------------------- >>> ---------------- >>>> libavutil/avstring.h | 2 +- >>>> libavutil/tests/avstring.c | 16 ++++++++++ >>>> 3 files changed, 28 insertions(+), 66 deletions(-) >>> >>> This version looks fine to me. >>> >>> Maybe wait a little more for advice about the rename and the whole >>> thing. >>> >>> Thanks. >>> >>> -- >>> Nicolas George >>> >>> _______________________________________________ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> >>> >> ping > > You can't rename the function. It's already in the 3.3 branch. > This is one of the reasons why giving people enough time for reviews > is a must before pushing new public symbols. Yet the 3.3 release wasn't tagged yet, so it is not _released_. So is there any practical reason for not renaming it before the release? Thanks, Marton
Le sextidi 16 germinal, an CCXXV, James Almer a écrit :
> You can't rename the function. It's already in the 3.3 branch.
AFAICS, it is only a branch yet, so I see no reason not to push this,
provided it is backported to the branch and done before the actual
release.
Thus, I think this discussion should be considered blocking for the
release.
Regards,
On 4/5/2017 1:49 PM, Marton Balint wrote: > > > On Wed, 5 Apr 2017, James Almer wrote: > >> On 4/5/2017 11:05 AM, Steven Liu wrote: >>> 2017-04-03 20:32 GMT+08:00 Nicolas George <george@nsup.org>: >>> >>>> Le quartidi 14 germinal, an CCXXV, Steven Liu a écrit : >>>>> change name from av_strreplace to av_strireplace >>>>> Use AVBprint to implement av_strireplace >>>>> add av_strireplace test case TEST_STRIREPLACE >>>>> >>>>> Signed-off-by: Steven Liu <lq@chinaffmpeg.org> >>>>> --- >>>>> libavutil/avstring.c | 76 +++++++----------------------- >>>> ---------------- >>>>> libavutil/avstring.h | 2 +- >>>>> libavutil/tests/avstring.c | 16 ++++++++++ >>>>> 3 files changed, 28 insertions(+), 66 deletions(-) >>>> >>>> This version looks fine to me. >>>> >>>> Maybe wait a little more for advice about the rename and the whole >>>> thing. >>>> >>>> Thanks. >>>> >>>> -- >>>> Nicolas George >>>> >>>> _______________________________________________ >>>> ffmpeg-devel mailing list >>>> ffmpeg-devel@ffmpeg.org >>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>>> >>>> >>> ping >> >> You can't rename the function. It's already in the 3.3 branch. >> This is one of the reasons why giving people enough time for reviews >> is a must before pushing new public symbols. > > Yet the 3.3 release wasn't tagged yet, so it is not _released_. So is there any practical reason for not renaming it before the release? > > Thanks, > Marton Library versions and feature sets in diverging branches. When you branch you do a feature freeze. Making a mess with this for a single function that should have not been applied in such short notice shouldn't be acceptable.
Le sextidi 16 germinal, an CCXXV, James Almer a écrit : > Library versions and feature sets in diverging branches. When you > branch you do a feature freeze. I do not agree with that. The delay between branching and tagging the release has exactly the purpose of fixing the big mistakes that were including. The feature freeze happens at the tagging, not the branching. Regards,
On Wed, 5 Apr 2017, James Almer wrote: > On 4/5/2017 1:49 PM, Marton Balint wrote: >> >> >> On Wed, 5 Apr 2017, James Almer wrote: >> >>> On 4/5/2017 11:05 AM, Steven Liu wrote: >>>> 2017-04-03 20:32 GMT+08:00 Nicolas George <george@nsup.org>: >>>> >>>>> Le quartidi 14 germinal, an CCXXV, Steven Liu a écrit : >>>>>> change name from av_strreplace to av_strireplace >>>>>> Use AVBprint to implement av_strireplace >>>>>> add av_strireplace test case TEST_STRIREPLACE >>>>>> >>>>>> Signed-off-by: Steven Liu <lq@chinaffmpeg.org> >>>>>> --- >>>>>> libavutil/avstring.c | 76 +++++++----------------------- >>>>> ---------------- >>>>>> libavutil/avstring.h | 2 +- >>>>>> libavutil/tests/avstring.c | 16 ++++++++++ >>>>>> 3 files changed, 28 insertions(+), 66 deletions(-) >>>>> >>>>> This version looks fine to me. >>>>> >>>>> Maybe wait a little more for advice about the rename and the whole >>>>> thing. >>>>> >>>>> Thanks. >>>>> >>>>> -- >>>>> Nicolas George >>>>> >>>>> _______________________________________________ >>>>> ffmpeg-devel mailing list >>>>> ffmpeg-devel@ffmpeg.org >>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>>>> >>>>> >>>> ping >>> >>> You can't rename the function. It's already in the 3.3 branch. >>> This is one of the reasons why giving people enough time for reviews >>> is a must before pushing new public symbols. >> >> Yet the 3.3 release wasn't tagged yet, so it is not _released_. So is there any practical reason for not renaming it before the release? >> >> Thanks, >> Marton > > Library versions and feature sets in diverging branches. When you > branch you do a feature freeze. > > Making a mess with this for a single function that should have not > been applied in such short notice shouldn't be acceptable. I don't think it would cause any problems for the users in practice. But we can also remove the function alltogether from the release, so anybody who want's to use the function (with the new name) will only have to check for a single version number. Regards, Marton
On 4/5/2017 2:38 PM, Marton Balint wrote: > > > On Wed, 5 Apr 2017, James Almer wrote: > >> On 4/5/2017 1:49 PM, Marton Balint wrote: >>> >>> >>> On Wed, 5 Apr 2017, James Almer wrote: >>> >>>> On 4/5/2017 11:05 AM, Steven Liu wrote: >>>>> 2017-04-03 20:32 GMT+08:00 Nicolas George <george@nsup.org>: >>>>> >>>>>> Le quartidi 14 germinal, an CCXXV, Steven Liu a écrit : >>>>>>> change name from av_strreplace to av_strireplace >>>>>>> Use AVBprint to implement av_strireplace >>>>>>> add av_strireplace test case TEST_STRIREPLACE >>>>>>> >>>>>>> Signed-off-by: Steven Liu <lq@chinaffmpeg.org> >>>>>>> --- >>>>>>> libavutil/avstring.c | 76 +++++++----------------------- >>>>>> ---------------- >>>>>>> libavutil/avstring.h | 2 +- >>>>>>> libavutil/tests/avstring.c | 16 ++++++++++ >>>>>>> 3 files changed, 28 insertions(+), 66 deletions(-) >>>>>> >>>>>> This version looks fine to me. >>>>>> >>>>>> Maybe wait a little more for advice about the rename and the whole >>>>>> thing. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> -- >>>>>> Nicolas George >>>>>> >>>>>> _______________________________________________ >>>>>> ffmpeg-devel mailing list >>>>>> ffmpeg-devel@ffmpeg.org >>>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>>>>> >>>>>> >>>>> ping >>>> >>>> You can't rename the function. It's already in the 3.3 branch. >>>> This is one of the reasons why giving people enough time for reviews >>>> is a must before pushing new public symbols. >>> >>> Yet the 3.3 release wasn't tagged yet, so it is not _released_. So is there any practical reason for not renaming it before the release? >>> >>> Thanks, >>> Marton >> >> Library versions and feature sets in diverging branches. When you >> branch you do a feature freeze. >> >> Making a mess with this for a single function that should have not >> been applied in such short notice shouldn't be acceptable. > > I don't think it would cause any problems for the users in practice. But we can also remove the function alltogether from the release, so anybody who want's to use the function (with the new name) will only have to check for a single version number. > > Regards, > Marton Fine by me. The thing didn't even get its own bump or APIChanges now that i look at it, so it might as well not exist. It would hardly be the worst "breakage" we've gone through.
Le sextidi 16 germinal, an CCXXV, James Almer a écrit : > > I don't think it would cause any problems for the users in practice. > > But we can also remove the function alltogether from the release, so > > anybody who want's to use the function (with the new name) will only > > have to check for a single version number. > Fine by me. The thing didn't even get its own bump or APIChanges > now that i look at it, so it might as well not exist. > It would hardly be the worst "breakage" we've gone through. I think removing the function from the release branch (before actual release if possible) and renaming it in master is a good solution. Thanks, Marton, for thinking of it. Steven, would you be fine with it? Michael? Regards,
On 4/5/2017 2:49 PM, Nicolas George wrote: > Le sextidi 16 germinal, an CCXXV, James Almer a écrit : >>> I don't think it would cause any problems for the users in practice. >>> But we can also remove the function alltogether from the release, so >>> anybody who want's to use the function (with the new name) will only >>> have to check for a single version number. > >> Fine by me. The thing didn't even get its own bump or APIChanges >> now that i look at it, so it might as well not exist. >> It would hardly be the worst "breakage" we've gone through. > > I think removing the function from the release branch (before > actual release if possible) and renaming it in master is a good > solution. Thanks, Marton, for thinking of it. > > Steven, would you be fine with it? > > Michael? > > Regards, Make sure to add a line in APIChanges when you do. Maybe also a version bump. In master of course.
2017-04-06 1:49 GMT+08:00 Nicolas George <george@nsup.org>: > Le sextidi 16 germinal, an CCXXV, James Almer a écrit : > > > I don't think it would cause any problems for the users in practice. > > > But we can also remove the function alltogether from the release, so > > > anybody who want's to use the function (with the new name) will only > > > have to check for a single version number. > > > Fine by me. The thing didn't even get its own bump or APIChanges > > now that i look at it, so it might as well not exist. > > It would hardly be the worst "breakage" we've gone through. > > I think removing the function from the release branch (before > actual release if possible) and renaming it in master is a good > solution. Thanks, Marton, for thinking of it. > > Steven, would you be fine with it? > yes, of course, i think just avformat/dashdec using it now, > > Michael? > > Regards, > > -- > Nicolas George > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >
On Wed, Apr 05, 2017 at 07:49:23PM +0200, Nicolas George wrote: > Le sextidi 16 germinal, an CCXXV, James Almer a écrit : > > > I don't think it would cause any problems for the users in practice. > > > But we can also remove the function alltogether from the release, so > > > anybody who want's to use the function (with the new name) will only > > > have to check for a single version number. > > > Fine by me. The thing didn't even get its own bump or APIChanges > > now that i look at it, so it might as well not exist. > > It would hardly be the worst "breakage" we've gone through. > > I think removing the function from the release branch (before > actual release if possible) and renaming it in master is a good > solution. Thanks, Marton, for thinking of it. > > Steven, would you be fine with it? > > Michael? Its in no release, and there seems consensus that it shouldnt be in a release at this point, so id say remove it from release/3.3 branch [...]
Le septidi 17 germinal, an CCXXV, Michael Niedermayer a écrit : > Its in no release, and there seems consensus that it shouldnt be > in a release at this point, so id say remove it from release/3.3 branch I think we can say that enough time has passed, and ideally it should be removed before the actual release. Steven: are you on it? Regards,
2017-04-10 4:39 GMT+08:00 Nicolas George <george@nsup.org>: > Le septidi 17 germinal, an CCXXV, Michael Niedermayer a écrit : > > Its in no release, and there seems consensus that it shouldnt be > > in a release at this point, so id say remove it from release/3.3 branch > > I think we can say that enough time has passed, and ideally it should be > removed before the actual release. > > Steven: are you on it? > yes, but i don't know how should i do next step. > > Regards, > > -- > Nicolas George > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >
On Mon, 10 Apr 2017, Steven Liu wrote: > 2017-04-10 4:39 GMT+08:00 Nicolas George <george@nsup.org>: > >> Le septidi 17 germinal, an CCXXV, Michael Niedermayer a écrit : >> > Its in no release, and there seems consensus that it shouldnt be >> > in a release at this point, so id say remove it from release/3.3 branch >> >> I think we can say that enough time has passed, and ideally it should be >> removed before the actual release. >> >> Steven: are you on it? >> > yes, but i don't know how should i do next step. > In the 3.3 branch you should revert the original av_strreplace patch (99e5d81ef997cb88b1a40e6f253f37f7cbf251d9). In the master branch you should apply your v3 patch (which renames the function and makes it use AVBPrint), and when applying, also make sure to add a line in APIChanges about av_strireplace and increase libavutil minor version. Regards, Marton
2017-04-10 7:09 GMT+08:00 Marton Balint <cus@passwd.hu>: > > > On Mon, 10 Apr 2017, Steven Liu wrote: > > 2017-04-10 4:39 GMT+08:00 Nicolas George <george@nsup.org>: >> >> Le septidi 17 germinal, an CCXXV, Michael Niedermayer a écrit : >>> > Its in no release, and there seems consensus that it shouldnt be >>> > in a release at this point, so id say remove it from release/3.3 branch >>> >>> I think we can say that enough time has passed, and ideally it should be >>> removed before the actual release. >>> >>> Steven: are you on it? >>> >>> yes, but i don't know how should i do next step. >> >> > In the 3.3 branch you should revert the original av_strreplace patch > (99e5d81ef997cb88b1a40e6f253f37f7cbf251d9). > > In the master branch you should apply your v3 patch (which renames the > function and makes it use AVBPrint), and when applying, also make sure to > add a line in APIChanges about av_strireplace and increase libavutil minor > version. > git checkout remotes/origin/release/3.3 -b 3.3 git revert 99e5d81ef997cb88b1a40e6f253f37f7cbf251d9 git push remotes/origin/release/3.3 Is that right? > > Regards, > Marton > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >
On Mon, 10 Apr 2017, Steven Liu wrote: > 2017-04-10 7:09 GMT+08:00 Marton Balint <cus@passwd.hu>: > >> >> >> On Mon, 10 Apr 2017, Steven Liu wrote: >> >> 2017-04-10 4:39 GMT+08:00 Nicolas George <george@nsup.org>: >>> >>> Le septidi 17 germinal, an CCXXV, Michael Niedermayer a écrit : >>>> > Its in no release, and there seems consensus that it shouldnt be >>>> > in a release at this point, so id say remove it from release/3.3 branch >>>> >>>> I think we can say that enough time has passed, and ideally it should be >>>> removed before the actual release. >>>> >>>> Steven: are you on it? >>>> >>>> yes, but i don't know how should i do next step. >>> >>> >> In the 3.3 branch you should revert the original av_strreplace patch >> (99e5d81ef997cb88b1a40e6f253f37f7cbf251d9). >> >> In the master branch you should apply your v3 patch (which renames the >> function and makes it use AVBPrint), and when applying, also make sure to >> add a line in APIChanges about av_strireplace and increase libavutil minor >> version. >> > git checkout remotes/origin/release/3.3 -b 3.3 > git revert 99e5d81ef997cb88b1a40e6f253f37f7cbf251d9 > git push remotes/origin/release/3.3 I usually simply do this: git checkout release/3.3 commit patches git push origin release/3.3 You can always use the --dry-run before push to be safe. Regards, Marton
2017-04-11 4:16 GMT+08:00 Marton Balint <cus@passwd.hu>: > > > On Mon, 10 Apr 2017, Steven Liu wrote: > > 2017-04-10 7:09 GMT+08:00 Marton Balint <cus@passwd.hu>: >> >> >>> >>> On Mon, 10 Apr 2017, Steven Liu wrote: >>> >>> 2017-04-10 4:39 GMT+08:00 Nicolas George <george@nsup.org>: >>> >>>> >>>> Le septidi 17 germinal, an CCXXV, Michael Niedermayer a écrit : >>>> >>>>> > Its in no release, and there seems consensus that it shouldnt be >>>>> > in a release at this point, so id say remove it from release/3.3 >>>>> branch >>>>> >>>>> I think we can say that enough time has passed, and ideally it should >>>>> be >>>>> removed before the actual release. >>>>> >>>>> Steven: are you on it? >>>>> >>>>> yes, but i don't know how should i do next step. >>>>> >>>> >>>> >>>> In the 3.3 branch you should revert the original av_strreplace patch >>> (99e5d81ef997cb88b1a40e6f253f37f7cbf251d9). >>> >>> In the master branch you should apply your v3 patch (which renames the >>> function and makes it use AVBPrint), and when applying, also make sure to >>> add a line in APIChanges about av_strireplace and increase libavutil >>> minor >>> version. >>> >>> git checkout remotes/origin/release/3.3 -b 3.3 >> git revert 99e5d81ef997cb88b1a40e6f253f37f7cbf251d9 >> git push remotes/origin/release/3.3 >> > > I usually simply do this: > > git checkout release/3.3 > commit patches > git push origin release/3.3 > > You can always use the --dry-run before push to be safe. Have revert 99e5d81ef997cb88b1a40e6f253f37f7cbf251d9 Thanks > > > Regards, > Marton > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >
diff --git a/libavutil/avstring.c b/libavutil/avstring.c index 52e6e6cd13..f03dd25141 100644 --- a/libavutil/avstring.c +++ b/libavutil/avstring.c @@ -231,80 +231,26 @@ int av_strncasecmp(const char *a, const char *b, size_t n) return c1 - c2; } -char *av_strreplace(const char *str, const char *from, const char *to) +char *av_strireplace(const char *str, const char *from, const char *to) { - /* Adjust each of the below values to suit your needs. */ - /* Increment positions cache size initially by this number. */ - size_t cache_sz_inc = 16; - /* Thereafter, each time capacity needs to be increased, - * multiply the increment by this factor. */ - const size_t cache_sz_inc_factor = 3; - /* But never increment capacity by more than this number. */ - const size_t cache_sz_inc_max = 1048576; - - char *pret, *ret = NULL; + char *ret = NULL; const char *pstr2, *pstr = str; - size_t i, count = 0; - uintptr_t *pos_cache_tmp, *pos_cache = NULL; - size_t cache_sz = 0; - size_t cpylen, orglen, retlen, tolen, fromlen = strlen(from); + size_t tolen = strlen(to), fromlen = strlen(from); + AVBPrint pbuf; - /* Find all matches and cache their positions. */ + av_bprint_init(&pbuf, 1, AV_BPRINT_SIZE_UNLIMITED); while ((pstr2 = av_stristr(pstr, from))) { - count++; - /* Increase the cache size when necessary. */ - if (cache_sz < count) { - cache_sz += cache_sz_inc; - pos_cache_tmp = av_realloc(pos_cache, sizeof(*pos_cache) * cache_sz); - if (!pos_cache_tmp) { - goto end_strreplace; - } else pos_cache = pos_cache_tmp; - cache_sz_inc *= cache_sz_inc_factor; - if (cache_sz_inc > cache_sz_inc_max) { - cache_sz_inc = cache_sz_inc_max; - } - } - - pos_cache[count-1] = pstr2 - str; + av_bprint_append_data(&pbuf, pstr, pstr2 - pstr); pstr = pstr2 + fromlen; + av_bprint_append_data(&pbuf, to, tolen); } - orglen = pstr - str + strlen(pstr); - /* Allocate memory for the post-replacement string. */ - if (count > 0) { - tolen = strlen(to); - retlen = orglen + (tolen - fromlen) * count; - } else { - retlen = orglen; - } - ret = av_malloc(retlen + 1); - if (!ret) { - goto end_strreplace; - } - - if (!count) { - /* If no matches, then just duplicate the string. */ - av_strlcpy(ret, str, retlen + 1); + av_bprint_append_data(&pbuf, pstr, strlen(pstr)); + if (!av_bprint_is_complete(&pbuf)) { + av_bprint_finalize(&pbuf, NULL); } else { - /* Otherwise, duplicate the string whilst performing - * the replacements using the position cache. */ - pret = ret; - memcpy(pret, str, pos_cache[0]); - pret += pos_cache[0]; - for (i = 0; i < count; i++) { - memcpy(pret, to, tolen); - pret += tolen; - pstr = str + pos_cache[i] + fromlen; - cpylen = (i == count-1 ? orglen : pos_cache[i+1]) - pos_cache[i] - fromlen; - memcpy(pret, pstr, cpylen); - pret += cpylen; - } - ret[retlen] = '\0'; + av_bprint_finalize(&pbuf, &ret); } -end_strreplace: - /* Free the cache and return the post-replacement string, - * which will be NULL in the event of an error. */ - av_free(pos_cache); return ret; } diff --git a/libavutil/avstring.h b/libavutil/avstring.h index 33be8bf484..04d2695640 100644 --- a/libavutil/avstring.h +++ b/libavutil/avstring.h @@ -270,7 +270,7 @@ int av_strncasecmp(const char *a, const char *b, size_t n); * Locale-independent strings replace. * @note This means only ASCII-range characters are replace */ -char *av_strreplace(const char *str, const char *from, const char *to); +char *av_strireplace(const char *str, const char *from, const char *to); /** * Thread safe basename. diff --git a/libavutil/tests/avstring.c b/libavutil/tests/avstring.c index 14bc7ffcea..887bd25a12 100644 --- a/libavutil/tests/avstring.c +++ b/libavutil/tests/avstring.c @@ -93,6 +93,22 @@ int main(void) TEST_STRNSTR(haystack, needle [2], strlen(haystack), NULL ); TEST_STRNSTR(haystack, strings[1], strlen(haystack), haystack ); + /*Testing av_strireplace()*/ + #define TEST_STRIREPLACE(haystack, needle, expected) \ + ptr = av_strireplace(haystack, needle, "instead"); \ + if (ptr == NULL) { \ + printf("error, received null pointer!\n"); \ + } else { \ + if (strcmp(ptr, expected) != 0) \ + printf( "expected: %s, received: %s\n", expected, ptr); \ + av_free(ptr); \ + } + + TEST_STRIREPLACE(haystack, needle [0], "Education consists mainly in what we have uninstead"); + TEST_STRIREPLACE(haystack, needle [1], "Education consists mainly in what we have instead"); + TEST_STRIREPLACE(haystack, needle [2], "Education consists mainly in what we have instead."); + TEST_STRIREPLACE(haystack, needle [1], "Education consists mainly in what we have instead"); + /*Testing av_d2str()*/ #define TEST_D2STR(value, expected) \ if((ptr = av_d2str(value)) == NULL){ \
change name from av_strreplace to av_strireplace Use AVBprint to implement av_strireplace add av_strireplace test case TEST_STRIREPLACE Signed-off-by: Steven Liu <lq@chinaffmpeg.org> --- libavutil/avstring.c | 76 +++++++--------------------------------------- libavutil/avstring.h | 2 +- libavutil/tests/avstring.c | 16 ++++++++++ 3 files changed, 28 insertions(+), 66 deletions(-)