From: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Subject: Re: Windows warnings from VS 2017
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
References: <f6488a36-4702-6d50-9fb4-fee10bb49497@2ndQuadrant.com>
 <8649.1505951694@sss.pgh.pa.us>
 <acf6b500-0f91-cb38-d76b-17b6de29a606@2ndQuadrant.com>
Message-ID: <c8fc2cd2-584f-1bf7-8d4a-ae05db709ad2@2ndQuadrant.com>
Date: Wed, 20 Sep 2017 22:26:42 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <acf6b500-0f91-cb38-d76b-17b6de29a606@2ndQuadrant.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-MW
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


On 09/20/2017 08:18 PM, Andrew Dunstan wrote:
>
> On 09/20/2017 07:54 PM, Tom Lane wrote:
>> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>>> It's also warning that it will copy 16 bytes to a 13 byte structure at
>>> lines 518, 1293 and 1294 of src/backend/commands/dbcommands.c. I haven't
>>> seen any ill effects of this so far, but it seems to indicate that
>>> something is possibly amiss on this compiler with the MemSet macros.
>> That's weird.  Is it too stupid to figure out that the if() inside
>> MemSet evaluates to constant false in these calls?  It seems hard to
>> see how it would realize that the loop will write 16 bytes if it doesn't
>> propagate the constant value forward.
>>
>> However ... on some other compilers, I've noticed that the compiler seems
>> more likely to make "obvious" deductions of that sort if the variables in
>> question are marked const.  Does it help if you do
>>
>> -		void   *_vstart = (void *) (start); \
>> -		int		_val = (val); \
>> -		Size	_len = (len); \
>> +		void   * const _vstart = (void *) (start); \
>> +		const int	_val = (val); \
>> +		const Size	_len = (len); \
>>
>>
>> I don't think there's any strong reason not to just do s/MemSet/memset/
>> in these calls and nearby ones, but it would be good to understand just
>> what's wrong here.  And why it's only showing up in that file; seems
>> nearly certain that we have similar coding elsewhere.
>>
>> 			
>
> I'll test it.
>


Doesn't make a difference. I agree it would be good to understand what's
going on.


cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers