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
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? |