[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <12050afd-ab60-4bac-bd25-0c3cc925b38b@web.de>
Date: Mon, 3 Mar 2025 09:15:14 +0100
From: Markus Elfring <Markus.Elfring@....de>
To: Dan Carpenter <dan.carpenter@...aro.org>,
Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
freedreno@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
linux-arm-msm@...r.kernel.org
Cc: kernel-janitors@...r.kernel.org, Abhinav Kumar
<quic_abhinavk@...cinc.com>, Archit Taneja <architt@...eaurora.org>,
Daniel Vetter <daniel@...ll.ch>, David Airlie <airlied@...il.com>,
Jeykumar Sankaran <jsanka@...eaurora.org>,
Jordan Crouse <jordan@...micpenguin.net>,
Marijn Suijten <marijn.suijten@...ainline.org>,
Rob Clark <robdclark@...il.com>, Sean Paul <sean@...rly.run>,
Simona Vetter <simona@...ll.ch>, Vinod Koul <vkoul@...nel.org>,
cocci@...ia.fr, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RESEND] drm/msm/dpu: Delete a variable initialisation before a
null pointer check in two functions
>>> The address of a data structure member was determined before
>>> a corresponding null pointer check in the implementation of
>>> the functions “dpu_hw_pp_enable_te” and “dpu_hw_pp_get_vsync_info”.
>>>
>>> Thus avoid the risk for undefined behaviour by removing extra
>>> initialisations for the variable “c” (also because it was already
>>> reassigned with the same value behind this pointer check).
>
> There is no undefined behavior here.
Will any software development concerns evolve further also according to
undesirable null pointer dereferences?
https://wiki.sei.cmu.edu/confluence/display/c/EXP34-C.+Do+not+dereference+null+pointers
Regards,
Markus
Powered by blists - more mailing lists