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