On Tue, Oct 01, 2019 at 09:58:55PM +0300, Dan Carpenter wrote:
> On Tue, Oct 01, 2019 at 06:13:21PM +0300, Denis Efremov wrote:
> > Just found an official documentation to this issue:
> > https://gcc.gnu.org/gcc-4.9/porting_to.html
> > "Null pointer checks may be optimized away more aggressively
>
Hi,
On 09.10.2019 12:35, Hans de Goede wrote:
> Hi Denis,
>
> On 30-09-2019 13:01, Denis Efremov wrote:
>> memcpy() in phy_ConfigBBWithParaFile() and PHY_ConfigRFWithParaFile() is
>> called with "src == NULL && len == 0". This is an undefined behavior.
>> Moreover this if pre-condition "pBufLen &
Hi Denis,
On 30-09-2019 13:01, Denis Efremov wrote:
memcpy() in phy_ConfigBBWithParaFile() and PHY_ConfigRFWithParaFile() is
called with "src == NULL && len == 0". This is an undefined behavior.
Moreover this if pre-condition "pBufLen && (*pBufLen == 0) && !pBuf"
is constantly false because it i
On 01.10.2019 21:58, Dan Carpenter wrote:
> On Tue, Oct 01, 2019 at 06:13:21PM +0300, Denis Efremov wrote:
>> Just found an official documentation to this issue:
>> https://gcc.gnu.org/gcc-4.9/porting_to.html
>> "Null pointer checks may be optimized away more aggressively
>> ...
>> The pointers pas
On Tue, Oct 01, 2019 at 06:13:21PM +0300, Denis Efremov wrote:
> Just found an official documentation to this issue:
> https://gcc.gnu.org/gcc-4.9/porting_to.html
> "Null pointer checks may be optimized away more aggressively
> ...
> The pointers passed to memmove (and similar functions in ) must b
From: Denis Efremov
> Sent: 01 October 2019 16:13
...
> Just found an official documentation to this issue:
> https://gcc.gnu.org/gcc-4.9/porting_to.html
> "Null pointer checks may be optimized away more aggressively
> ...
> The pointers passed to memmove (and similar functions in ) must be
> non-
On 10/1/19 5:36 PM, David Laight wrote:
>> From: Dan Carpenter
>> Sent: 01 October 2019 14:57
>> Subject: Re: [PATCH] staging: rtl8723bs: hal: Fix memcpy calls
> ...
>> That's true for glibc memcpy() but not for the kernel memcpy(). In the
>> kernel there a
> From: Dan Carpenter
> Sent: 01 October 2019 14:57
> Subject: Re: [PATCH] staging: rtl8723bs: hal: Fix memcpy calls
...
> That's true for glibc memcpy() but not for the kernel memcpy(). In the
> kernel there are lots of places which do a zero size memcpy().
And probabl
On Mon, Sep 30, 2019 at 05:25:43PM +0300, Denis Efremov wrote:
> On 9/30/19 4:18 PM, David Laight wrote:
> > From: Denis Efremov
> >> Sent: 30 September 2019 12:02
> >> memcpy() in phy_ConfigBBWithParaFile() and PHY_ConfigRFWithParaFile() is
> >> called with "src == NULL && len == 0". This is an un
On 9/30/19 4:18 PM, David Laight wrote:
> From: Denis Efremov
>> Sent: 30 September 2019 12:02
>> memcpy() in phy_ConfigBBWithParaFile() and PHY_ConfigRFWithParaFile() is
>> called with "src == NULL && len == 0". This is an undefined behavior.
>
> I'm pretty certain it is well defined (to do nothi
On 9/30/19 4:18 PM, David Laight wrote:
> From: Denis Efremov
>> Sent: 30 September 2019 12:02
>> memcpy() in phy_ConfigBBWithParaFile() and PHY_ConfigRFWithParaFile() is
>> called with "src == NULL && len == 0". This is an undefined behavior.
>
> I'm pretty certain it is well defined (to do nothi
Hi,
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.3.1, v5.2.17, v4.19.75, v4.14.146,
v4.9.194, v4.4.194.
v5.3.1: Build OK!
v5.2.1
From: Denis Efremov
> Sent: 30 September 2019 12:02
> memcpy() in phy_ConfigBBWithParaFile() and PHY_ConfigRFWithParaFile() is
> called with "src == NULL && len == 0". This is an undefined behavior.
I'm pretty certain it is well defined (to do nothing).
> Moreover this if pre-condition "pBufLen &
13 matches
Mail list logo
