From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ffmpeg-devel-bounces@ffmpeg.org>
Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100])
	by master.gitmailbox.com (Postfix) with ESMTP id CA174478F2
	for <ffmpegdev@gitmailbox.com>; Wed, 27 Sep 2023 10:26:17 +0000 (UTC)
Received: from [127.0.1.1] (localhost [127.0.0.1])
	by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 35CD668CAD0;
	Wed, 27 Sep 2023 13:26:14 +0300 (EEST)
Received: from haasn.dev (haasn.dev [78.46.187.166])
 by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 73AF768CA17
 for <ffmpeg-devel@ffmpeg.org>; Wed, 27 Sep 2023 13:26:07 +0300 (EEST)
Received: from haasn.dev (unknown [10.30.0.2])
 by haasn.dev (Postfix) with ESMTP id 1D67041827
 for <ffmpeg-devel@ffmpeg.org>; Wed, 27 Sep 2023 12:26:07 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=haasn.xyz; s=mail;
 t=1695810367; bh=edCd9gnV9i9Z8AM1qFNqNuYzu3Kg0lDQI+f64EZv8k8=;
 h=Date:From:To:Subject:In-Reply-To:References:From;
 b=GhlIjtOuaBvs3Cov4rveJGcuwjDj2tlxZMJDqLW3u+uaZLbqpoS7TzCiV30j9o3z5
 0DRRY3V6S5dgJEOKwhETS1wHgF4SNGojEEThuWxvkR7gRzqxKZpoShBmYhuq3+ZxIK
 /EHC6la7jaDkMkfiYbBS2WdYT9L6i5SmqgUtjpJs=
Date: Wed, 27 Sep 2023 12:26:06 +0200
Message-ID: <20230927122606.GD38009@haasn.xyz>
From: Niklas Haas <ffmpeg@haasn.xyz>
To: ffmpeg-devel@ffmpeg.org
In-Reply-To: <GV1P250MB0737F2B1DF2EFE345EA4D3178FC2A@GV1P250MB0737.EURP250.PROD.OUTLOOK.COM>
References: <20230927100630.50510-1-ffmpeg@haasn.xyz>
 <20230927100630.50510-4-ffmpeg@haasn.xyz>
 <GV1P250MB0737F2B1DF2EFE345EA4D3178FC2A@GV1P250MB0737.EURP250.PROD.OUTLOOK.COM>
MIME-Version: 1.0
Content-Disposition: inline
Subject: Re: [FFmpeg-devel] [PATCH 3/5] avcodec/fflcms2: add
 ff_icc_profile_sanitize
X-BeenThere: ffmpeg-devel@ffmpeg.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: FFmpeg development discussions and patches <ffmpeg-devel.ffmpeg.org>
List-Unsubscribe: <https://ffmpeg.org/mailman/options/ffmpeg-devel>,
 <mailto:ffmpeg-devel-request@ffmpeg.org?subject=unsubscribe>
List-Archive: <https://ffmpeg.org/pipermail/ffmpeg-devel>
List-Post: <mailto:ffmpeg-devel@ffmpeg.org>
List-Help: <mailto:ffmpeg-devel-request@ffmpeg.org?subject=help>
List-Subscribe: <https://ffmpeg.org/mailman/listinfo/ffmpeg-devel>,
 <mailto:ffmpeg-devel-request@ffmpeg.org?subject=subscribe>
Reply-To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: ffmpeg-devel-bounces@ffmpeg.org
Sender: "ffmpeg-devel" <ffmpeg-devel-bounces@ffmpeg.org>
Archived-At: <https://master.gitmailbox.com/ffmpegdev/20230927122606.GD38009@haasn.xyz/>
List-Archive: <https://master.gitmailbox.com/ffmpegdev/>
List-Post: <mailto:ffmpegdev@gitmailbox.com>

On Wed, 27 Sep 2023 12:20:37 +0200 Andreas Rheinhardt <andreas.rheinhardt@outlook.com> wrote:
> Why is this a separate function and not just a new parameter to
> ff_icc_profile_read_primaries() given that these seem to always be used
> a pair?

Because it mutates the profile. It seems strange to me for a function
named `ff_icc_profile_*read*_primaries` to modify the profile it's
reading from. If it were possible to easily add this sanitization logic
without touching the profile itself I would have merged the two.

Forcing it to be a separate function forces each caller to think about
whether they want to actually modify the profile or not. At present we
only have two callers, and both of them destroy the cmsHPROFILE after
calling this function, so mutating is fine. But is that a given?
_______________________________________________
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".