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 6427C4ABF0 for ; Sun, 14 Jul 2024 12:34:57 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id ED7DD68D9F8; Sun, 14 Jul 2024 15:34:54 +0300 (EEST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 070F968D913 for ; Sun, 14 Jul 2024 15:34:48 +0300 (EEST) X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from metallschleimette ([91.62.13.127]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M72oH-1sR4Ux1Bb5-0004eJ for ; Sun, 14 Jul 2024 14:34:48 +0200 Date: Sun, 14 Jul 2024 14:34:47 +0200 To: FFmpeg development discussions and patches Message-ID: References: <20240709113626.1836680-1-michael@niedermayer.cc> <172053107806.21847.11044848590089039731@lain.khirnov.net> <20240709132810.GA4991@pb2> <172053807774.21847.8430412564103918732@lain.khirnov.net> <20240709220032.GE4991@pb2> <172059983713.21847.3731174080920299257@lain.khirnov.net> <20240710134447.GH4991@pb2> <172061946320.21847.12226005313940119391@lain.khirnov.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <172061946320.21847.12226005313940119391@lain.khirnov.net> X-Provags-ID: V03:K1:0Q77w5NumC25dEC/ELhypbKGsxE4yFP8AzJ5jjO+NIj1k7s8MzF C30nMmmc8LBLDsIS3GW5VxjcjH+5BXNCLSn7GlY1TG5sJGzQSNru4NINR99PpgWvhCYyQx5 VN5yNrwvpu/hwce3/m9TKw8JpkDaSsGNkfVeEJAG6lKpXN7FTALKC1ugTJigsqRC7ZYk/IA S3O7IJyv44OzEQ0s16l6Q== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:Vtpjl9CzlGY=;gf5+4c/zmQXdml5rB48Nn+QvpmL /IAqxaGUzk74ml6AIxe1ogKHhRtKzkAf8vS5RJ9gfgA9ToE0f4/SwElILgnj7AcHXxkm1fpIo eOkT2NnLmDv+eP/dJDs5+9W2m7wU1jyXTxgIOpsrlFeK6twGuXtVIYMFc1hfgXp88NG3GXtmh Cg99Uhu8BWQLUYM4JBjeZmlaj8Gnao6/V/VSHD1ux1QaVqS0I9zFFUHKvsn3fg+gzpradVGjG GyVWx0rnMaa1UYojBWR9Hx9saBxYIoHCw8oUfA4HLH6moaQcClp4TDmOKV/oM0tJqvz0mOtgb 4ZuKyXWalE5qlFFVKWJ4AAMV+hddoUilZSXWPnKTqyMarDJPSeWsxe8keYYc3m5uqAiQgzg6q r7xhflNAhnmATMzj3pn+G+KHlCwOOhyYDDZU9t7UJdvyuTm06xd+p68egSoJ8VNVHHXGihws3 ol1yreWrltv5pyPAfBH6hdRDiVN+VDZDnVDl1ZnreZFBe4enpxxZbDMPAnLPjMhMCRreIE5IC k9do1AVN9lH+JD7qv/4r6VmTWJoEUc/dlhTtBmLZ2UmsErrJZVC0eyk8TurAuvXKdGss4youn yEh7xLPrgmVd2E0EwOsYEW+YP0+Rk/mSYdWfEgh2Bl7/lYkZyWMLNWPuPm5GWXsMaUIrTOHRc WvNKhVCNYCyxn8YiURApJqRrQ8LTTBkXjHSiUBSg/xAECeyln/1ESnmaKhDWoB6H+2TP9hOLa 2eMyX3ilI7hBK4xEhbtvM86iKH1GxRZnVfGOHRDpFrf0ssSMJj2gnBwkpZpl6rG7X7E88unKk j4LufLGM0RnIWcSJw1qcDQtg== Subject: Re: [FFmpeg-devel] [PATCH] avutil/imgutils: av_image_check_size2() ensure width and height fit in 32bit 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: , From: Alexander Strasser via ffmpeg-devel Reply-To: FFmpeg development discussions and patches Cc: Alexander Strasser Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 2024-07-10 15:51 +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2024-07-10 15:44:47) > > Do you still object to a 32bit check on width and height ? > > If not i intend to apply a patch adding such limits > > If you object i will take this to the TC > > In my first reply in this thread I asked for a very simple thing - > justify this commit, as the commit message provided ZERO arguments for > why is this done and what it actually improves. > > Instead of answering the question you keep painting ever wordier walls > of text. I'm not reading all that. Just answer the question, in the form > suitable for a commit message. As most of the time a communications problem AFAICS :( The answer Anton was probably looking for: The intention of av_image_check_size2 (and it it's predecessors) always was to use a bigger integer type (64bit) to check width and height fit into the limits of the next smaller integer type (32bit). Unfortunately it wasn't spelled out explicitly in the commit message back then, and the implementation incorrectly assumed that INT_MAX would always refer to 32bit signed max. Alexander _______________________________________________ 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".