On Thu, Sep 21, 2017 at 12:26 PM, Andrew Dunstan < andrew.duns...@2ndquadrant.com> wrote:
> > > On 09/20/2017 08:18 PM, Andrew Dunstan wrote: > > > > On 09/20/2017 07:54 PM, Tom Lane wrote: > >> Andrew Dunstan <andrew.duns...@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. These warnings are not produced when the build is run in DEBUG mode. Because of this I didn't see these warning when I was working with VS 2017. This may be an issue with VS 2017 compiler. Regards, Hari Babu Fujitsu Australia
