Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Anton Khirnov <anton@khirnov.net>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH] lsws/swscale.h: introduce sws_get_gaussian_vec
Date: Wed, 06 Sep 2023 13:13:25 +0200
Message-ID: <169399880562.20400.15389167820793227268@lain.khirnov.net> (raw)
In-Reply-To: <ZPey4LnGeA+bez2H@mariano>

Quoting Stefano Sabatini (2023-09-06 00:59:44)
> > > > As I already said above - function parameter names in a prototype are
> > > > purely cosmetic and have no effect on anything besides doxygen. You can
> > > > change them at will and even remove them entirely without breaking API
> > > > or ABI.
> > > > 
> > > 
> > > > The other reasons do not strike me as strong enough to warrant an API
> > > > break.
> > > 
> 
> > > I disagree on this: the function is probably only used internally and
> > > by libavfilter, and the migration is trivial enough so should cause no
> > > disruption anyway.
> > 
> 
> > The migration is not trivial for someone who is not familiar with the
> > code (such as a distro package maintainer), since the new function has a
> > different signature. I really do not think we should break APIs for
> > frivolous reasons, which includes cosmetic ones.
> 
> Following this logic every API change should be considered not trivial
> for someone not familiar with the code,

A simple rename is a trivial API change. Almost everything else is not.

> and therefore should not be committed.

Yes, the baseline for every API change is that it is undesirable and you
must supply sufficiently strong arguments to overcome that.

> Also there is no evidence that external components are using this
> function.
>
> Besides the naming change, there are ergonomic and functional changes
> making the behavior of the code more correct.

I do not see the code being made more correct, but Michael observed in
this thread that it becomes longer and more convoluted.

I am not convinced that adding logging to this function is an
improvement. You have to pass an extra parameter to every call, making
the code longer and less readable. We do not need a dedicated error
message for every malloc.

-- 
Anton Khirnov
_______________________________________________
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-09-06 11:13 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-26 12:23 Stefano Sabatini
2023-08-26 15:15 ` Andreas Rheinhardt
2023-08-31 15:32   ` Stefano Sabatini
2023-08-31 16:51     ` Andreas Rheinhardt
2023-08-31 17:16       ` Stefano Sabatini
2023-09-01 16:54         ` Michael Niedermayer
2023-09-01 18:38           ` Stefano Sabatini
2023-09-02 20:07             ` Michael Niedermayer
2023-09-03  0:25               ` Stefano Sabatini
2023-09-03 16:34                 ` Michael Niedermayer
2023-08-26 15:15 ` Anton Khirnov
2023-08-31 15:06   ` Stefano Sabatini
2023-09-01 15:50     ` Anton Khirnov
2023-09-01 18:28       ` Stefano Sabatini
2023-09-05 11:19         ` Anton Khirnov
2023-09-05 22:59           ` Stefano Sabatini
2023-09-06 11:13             ` Anton Khirnov [this message]
2023-11-04 21:38               ` Stefano Sabatini

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=169399880562.20400.15389167820793227268@lain.khirnov.net \
    --to=anton@khirnov.net \
    --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