Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Jul 2015 17:32:04 -0500
From:      Pedro Giffuni <pfg@FreeBSD.org>
To:        Ian Lepore <ian@freebsd.org>
Cc:        src-committers@freebsd.org, svn-src-all@freebsd.org,  svn-src-head@freebsd.org
Subject:   Re: svn commit: r285644 - head/contrib/sqlite3
Message-ID:  <55A830E4.6090408@FreeBSD.org>
In-Reply-To: <1437085366.1334.367.camel@freebsd.org>
References:  <201507162207.t6GM7ECT009955@repo.freebsd.org> <1437085366.1334.367.camel@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help


On 07/16/15 17:22, Ian Lepore wrote:
> On Thu, 2015-07-16 at 22:07 +0000, Pedro F. Giffuni wrote:
>> Author: pfg
>> Date: Thu Jul 16 22:07:13 2015
>> New Revision: 285644
>> URL: https://svnweb.freebsd.org/changeset/base/285644
>>
>> Log:
>>    sqlite: clean a couple of invocations of memcpy(3)
>>    
>>    Found almost accidentally by our native gcc when enhanced with
>>    FORTIFY_SOURCE.
>>    
>>    Submitted by:	Oliver Pinter
>>    Sponosored by:	Google Inc. GSoC 2015
>>
>> Modified:
>>    head/contrib/sqlite3/sqlite3.c
>>
>> Modified: head/contrib/sqlite3/sqlite3.c
>> ==============================================================================
>> --- head/contrib/sqlite3/sqlite3.c	Thu Jul 16 19:40:18 2015	(r285643)
>> +++ head/contrib/sqlite3/sqlite3.c	Thu Jul 16 22:07:13 2015	(r285644)
>> @@ -49487,9 +49487,9 @@ static void walIndexWriteHdr(Wal *pWal){
>>     pWal->hdr.isInit = 1;
>>     pWal->hdr.iVersion = WALINDEX_MAX_VERSION;
>>     walChecksumBytes(1, (u8*)&pWal->hdr, nCksum, 0, pWal->hdr.aCksum);
>> -  memcpy((void *)&aHdr[1], (void *)&pWal->hdr, sizeof(WalIndexHdr));
>> +  memcpy((void *)&aHdr[1], (const void *)&pWal->hdr, sizeof(WalIndexHdr));
>>     walShmBarrier(pWal);
>> -  memcpy((void *)&aHdr[0], (void *)&pWal->hdr, sizeof(WalIndexHdr));
>> +  memcpy((void *)&aHdr[0], (const void *)&pWal->hdr, sizeof(WalIndexHdr));
>>   }
>>   
>>   /*
>>
> Setting aside any "unnecessary divergence with upstream" questions for
> the moment, wouldn't the correct fix be to just remove the casting
> completely?

The compiler should know, but it is not wrong to have the casts
match the (standard) implementation. I couldn't say which is
"more" correct.

Pedro.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55A830E4.6090408>