Re: Windows warnings from VS 2017

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Windows warnings from VS 2017
Date: 2017-09-20 23:54:54
Message-ID: 8649.1505951694@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-09-21 00:08:00 Re: [Proposal] Allow users to specify multiple tables in VACUUM commands
Previous Message Peter Geoghegan 2017-09-20 23:40:45 Re: CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?