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 256ED454AE for ; Thu, 2 Mar 2023 11:33:11 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 80ED368AB19; Thu, 2 Mar 2023 13:33:07 +0200 (EET) Received: from mail-oi1-f173.google.com (mail-oi1-f173.google.com [209.85.167.173]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 2B03968A54A for ; Thu, 2 Mar 2023 13:33:01 +0200 (EET) Received: by mail-oi1-f173.google.com with SMTP id q15so13233058oiw.11 for ; Thu, 02 Mar 2023 03:33:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; 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=wKxN0oOEWs4zfQB8WEmfnjru6TLw78eCRDRQ2IG4zCo=; b=PRL70USlegY6D0EMsOhiNYIdjb93UFmOUo0qPDJASHOx26pJhmfd/VH4m4az5c5Uzd yzI1m+yI1TOI3hWuEzoJe8hxJ/46E2qWO1CwesqZgo3LT3Jhfw0fVezgBImX90tHm3HT Z8cDYrhdk+koj2ZnFlHje7hByXb087cpJ+po45FlUQtEGsaa3jhLns6z7qXSGvA6nZuO bbCbGNPFKX+V2QXj/sBS51zb46dkXZySkRuR7br3wuKF1tm1RfwyIM6KHMAYCOicgZvc Fz6k2gGwLCQp7/DZUMno9hqAf25U4kkXa6APO1whrGiPaBEaHYfHJPFPWTYJVxofQRYj 9GAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=wKxN0oOEWs4zfQB8WEmfnjru6TLw78eCRDRQ2IG4zCo=; b=G2dFXDtb09FDiwkXC5pkFfF4P+11vbZq+hvBkgr6pRvGGxq98d2T75X5anKnM9XPs3 rdYStU961ZA71sfZz2/iBOpnACduylHa3X4+7HVCxYZh27sdYwUgjJ79X2FwGEbgRJV8 8pUpaxvmkAVPX07bVaGoNWFG+zNENpbVkYXWzvA/1KeBYx5a3wTfgMcjg3NnNyuhGvcS CIMNMpYFfFyXfcm7cpN8T0z0kJrvBlLl9CxT9gKmCjfx2b3f5IJQHaSKvPJyD0BG/ymi AYc+obBO1mZ1BiAa1FY2Zpuuv5yQ7Vc9QcKyphJ9cudC3rNa/n41iC/xFiRu2tU+ngMO CggQ== X-Gm-Message-State: AO0yUKUKxBv13R153Ac9o3FJERPQ4O11xcHya45QEKMJxByUqS4OE72Q nwDobtvO8bFFcc0uDrfRosSVRc8wWKw= X-Google-Smtp-Source: AK7set8Bkc1MeTJpQ2ftXDKqjrDpEimVpLlQBdAHGjkXXVsRjP2BFbrGH+hfIhprfCu7fLTfhBvyYA== X-Received: by 2002:a05:6808:345:b0:383:fcc0:fa5c with SMTP id j5-20020a056808034500b00383fcc0fa5cmr4387254oie.46.1677756779375; Thu, 02 Mar 2023 03:32:59 -0800 (PST) Received: from [192.168.0.14] (host197.190-225-105.telecom.net.ar. [190.225.105.197]) by smtp.gmail.com with ESMTPSA id bc15-20020a056808170f00b00383efcce195sm7054982oib.8.2023.03.02.03.32.58 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Mar 2023 03:32:58 -0800 (PST) Message-ID: <721e5b23-d729-3566-3d90-12c19b7716d7@gmail.com> Date: Thu, 2 Mar 2023 08:33:09 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20230301185008.2167529-1-jdorfman@google.com> <167774795226.10789.12520983573867396589@lain.khirnov.net> From: James Almer In-Reply-To: <167774795226.10789.12520983573867396589@lain.khirnov.net> Subject: Re: [FFmpeg-devel] [PATCH] libavcodec/h264dec: avoid arithmetic on null pointers 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 3/2/2023 6:05 AM, Anton Khirnov wrote: > Quoting Jeremy Dorfman (2023-03-01 19:50:08) >> null pointer arithmetic is undefined behavior in C. >> --- >> libavcodec/h264dec.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c >> index 2d691731c5..ef698f2630 100644 >> --- a/libavcodec/h264dec.c >> +++ b/libavcodec/h264dec.c >> @@ -912,8 +912,8 @@ static int finalize_frame(H264Context *h, AVFrame *dst, H264Picture *out, int *g >> av_log(h->avctx, AV_LOG_DEBUG, "Duplicating field %d to fill missing\n", field); >> >> for (p = 0; p<4; p++) { >> - dst_data[p] = f->data[p] + (field^1)*f->linesize[p]; >> - src_data[p] = f->data[p] + field *f->linesize[p]; >> + dst_data[p] = f->data[p] ? f->data[p] + (field^1)*f->linesize[p] : NULL; >> + src_data[p] = f->data[p] ? f->data[p] + field *f->linesize[p] : NULL; > > Why would that be NULL? Seems like something that should not happen. None of the supported pixel formats in this decoder use four planes, so at least the last one will always be NULL. FF_PTR_ADD() is what we did in similar situations, like in sws_receive_slice(), when we don't use some helper to get the exact number of used planes from the pixfmt descriptor. _______________________________________________ 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".