Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Mark Thompson <sw@jkqxz.net>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] avcodec/hevc_ps: fix the problem of memcmp losing effectiveness
Date: Fri, 29 Mar 2024 15:55:21 +0000
Message-ID: <9085952b-8ea6-4d8e-a6a1-b1584e47c352@jkqxz.net> (raw)
In-Reply-To: <GV1P250MB0737CB23746232CE6C81C1B08F3A2@GV1P250MB0737.EURP250.PROD.OUTLOOK.COM>

On 29/03/2024 14:00, Andreas Rheinhardt wrote:
> James Almer:
>> On 3/29/2024 10:10 AM, Mark Thompson wrote:
>>> On 28/03/2024 13:15, tong1.wu-at-intel.com@ffmpeg.org wrote:
>>>> From: Tong Wu <tong1.wu@intel.com>
>>>>
>>>> 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 <tong1.wu@intel.com>
>>>> ---
>>>>    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 struct is zero allocated, so shouldn't the padding be exactly the
>> same for two equal VPSs after parsing?
>>
> 
> In practice it is (and the current code already relied on this); yet as
> has already been said padding bytes take unspecified values at any store
> (to any member). In practice, if the compiler uses instructions that
> clobber the padding, the padding in both structs is clobbered in the
> same way.

This seems like a strong assumption beyond that of the C specification which needs to be documented.

Are you expecting that there is no case where ABI-undefined top bits of registers can leak into the padding fields, or that all functions called here will necessarily set those top bits to the same values, or something else?

- 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".

  reply	other threads:[~2024-03-29 15:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-28 13:15 tong1.wu-at-intel.com
2024-03-29 12:45 ` James Almer
2024-03-29 15:15   ` Wu, Tong1
2024-03-29 13:10 ` Mark Thompson
2024-03-29 13:29   ` James Almer
2024-03-29 14:00     ` Andreas Rheinhardt
2024-03-29 15:55       ` Mark Thompson [this message]
2024-03-29 15:58         ` Andreas Rheinhardt
2024-03-29 16:33           ` Mark Thompson
2024-04-03  8:56           ` Anton Khirnov
2024-03-29 14:02   ` Andreas Rheinhardt
2024-03-29 14:49     ` Wu, Tong1
  -- strict thread matches above, loose matches on Subject: below --
2024-03-28  9:11 tong1.wu-at-intel.com
2024-03-28  9:43 ` Hendrik Leppkes
2024-03-28 13:18   ` Wu, Tong1

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=9085952b-8ea6-4d8e-a6a1-b1584e47c352@jkqxz.net \
    --to=sw@jkqxz.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