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