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 9DEC64A521 for ; Fri, 29 Mar 2024 13:10:18 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 6B60C68D599; Fri, 29 Mar 2024 15:10:15 +0200 (EET) Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 6AEB268D4F8 for ; Fri, 29 Mar 2024 15:10:09 +0200 (EET) Received: by mail-lj1-f172.google.com with SMTP id 38308e7fff4ca-2d6ff0422a2so27648451fa.2 for ; Fri, 29 Mar 2024 06:10:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jkqxz-net.20230601.gappssmtp.com; s=20230601; t=1711717808; x=1712322608; darn=ffmpeg.org; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Ji3hga/GpoGWfskH/qIViLzcks+ZfwPUZO4KvC3xIyI=; b=gfGHhk8rft3z8zYHXFAzRx4egZsXVReI1d7bQRSq0Nb+W2TZRFk2R778WRMxaDZ/AT o302GBw8/4Sl3ksmCXmQQO1b7PS5S5hMsnfmsIG7Yetqc5BxCUHYTK8SeJugRzVonrfB iZJKRScXXH2t/099IXSNz4D+N8rFAJdwYiuMOcDcP2BFnWJ5BxhXh3tA934mxwd4l+Kq /Yn31MZzTDdhKvDwr3myH1jeiD/KkgOec925Fa++2lg9sHoVKl/Q8PY00//xGrzc4rGu iILl4s8PEN3pyXiABsr7ydQ+0U+yP1edr0Oa3vydP5aTtcgJC1Ox2+phLccwAdXQW7Rx e5qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711717808; x=1712322608; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Ji3hga/GpoGWfskH/qIViLzcks+ZfwPUZO4KvC3xIyI=; b=grGMO09GUNM3LQx7LOdib9RtoAjDaQNeBG+CMEizbbSy2thyYnIqNpJHP14OXYPXQv PPSmKsYihA9dnfRwg9f/v3WuSKdvZyEhTwhnLB63jthn3jAubvyEfHoxgeHPKH1BDLsF wZGoSCvRa/J/meK+0AZJF48dzWupwngBZntcuCjGm9XmCTC9uEFDeuPxKU+KMxegkh/n UsWJ4B9oAAUWECPYyYrptf5FPdcDuEIrv+bjJOEcNU7AmYMSXvoEpbrPvhmoF+f0C+IM Ih7SfWvCE+wAuR32VPOe35C1StdofZsGdOQSxbEE/h5SgvvwZUyDppGNQV0HsFtD8Xgl lzTw== X-Gm-Message-State: AOJu0YwDotRNTkZ7zKRMHf1biDsPEHKP7rlW4AnYaW+vsWodAIbuoHYt KlThdeOoHgBejfv9SWf0nvqz+wrkQuJiYPaFESfAgu0XToJUlKSqSr2q3IRv2WuShPkSUt1C653 M X-Google-Smtp-Source: AGHT+IFgDVQmn481va3qE9ivvv7aXtS0QRF8pKJW/3WV0dQPTJ7RIBXCDmuD1jy00j1SnvsITSi/Hg== X-Received: by 2002:a2e:bc1b:0:b0:2d6:d7ff:5d3a with SMTP id b27-20020a2ebc1b000000b002d6d7ff5d3amr1600164ljf.14.1711717808140; Fri, 29 Mar 2024 06:10:08 -0700 (PDT) Received: from [192.168.0.15] (cpc92302-cmbg19-2-0-cust1183.5-4.cable.virginm.net. [82.1.212.160]) by smtp.gmail.com with ESMTPSA id t12-20020a05600c450c00b004154853f778sm4247354wmo.48.2024.03.29.06.10.07 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Mar 2024 06:10:07 -0700 (PDT) Message-ID: <441463cf-447d-4f12-aecb-84f00bfc544e@jkqxz.net> Date: Fri, 29 Mar 2024 13:10:31 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20240328131518.766-1-tong1.wu@intel.com> From: Mark Thompson In-Reply-To: <20240328131518.766-1-tong1.wu@intel.com> Subject: Re: [FFmpeg-devel] [PATCH] avcodec/hevc_ps: fix the problem of memcmp losing effectiveness 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 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 28/03/2024 13:15, tong1.wu-at-intel.com@ffmpeg.org wrote: > From: Tong Wu > > HEVCHdrParams* receives a pointer which points to a dynamically > allocated memory block. It causes the memcmp always returning 1. > Add a function to do the comparision. A condition is also added to > avoid malloc(0). > > Signed-off-by: Tong Wu > --- > libavcodec/hevc_ps.c | 20 ++++++++++++++++---- > libavcodec/hevc_ps.h | 4 +++- > 2 files changed, 19 insertions(+), 5 deletions(-) It doesn't seem like this method works at all, even before the recent change with the pointer. Structs can contain arbitrary padding, and any write to the struct makes the padding unspecified. memcmp() is therefore never valid as a method of comparing after writing some fields, as done here. (It could only be valid if the structs compared were made by memcpy() with no fields written directly.) The problem is mostly harmless because the nondeterministic replacement of structs which we were expecting to be equivalent doesn't actually change anything, so why don't we just remove the comparison and always replace? Thanks, - Mark _______________________________________________ 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".