Re: [HACKERS] Windows warnings from VS 2017
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Windows warnings from VS 2017 |
Дата | |
Msg-id | 8649.1505951694@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | [HACKERS] Windows warnings from VS 2017 (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] Windows warnings from VS 2017
|
Список | pgsql-hackers |
Andrew Dunstan <andrew.dunstan@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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: