Re: [HACKERS] Windows warnings from VS 2017

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: [HACKERS] Windows warnings from VS 2017
Дата
Msg-id bfa18917-9cfa-57ce-1806-043d478c9519@2ndQuadrant.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Windows warnings from VS 2017  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Ответы Re: [HACKERS] Windows warnings from VS 2017  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers

On 09/21/2017 02:53 AM, Haribabu Kommi wrote:
>
>
> On Thu, Sep 21, 2017 at 12:26 PM, Andrew Dunstan
> <andrew.dunstan@2ndquadrant.com
> <mailto:andrew.dunstan@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.dunstan@2ndquadrant.com
>     <mailto: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.
>     >>
>     >>
>     >
>     > 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.
>


Yeah, it seems like it, particularly when identical code in another
function in the same file doesn't generate a complaint.

The speed of memset is hardly going to be the dominating factor in a
'CREATE DATABASE' command, so we could certainly afford to change to
plain memset calls here.

I'll see if I can find someone to report this to :-)

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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Rajkumar Raghuwanshi
Дата:
Сообщение: Re: [HACKERS] Partition-wise aggregation/grouping
Следующее
От: Ashutosh Bapat
Дата:
Сообщение: Re: [HACKERS] Partition-wise join for join between (declaratively)partitioned tables