Re: cleanup in code
| От | David Rowley |
|---|---|
| Тема | Re: cleanup in code |
| Дата | |
| Msg-id | CAApHDvpOm4agg=69Tw--k7kU9RLeHs0P8Ede0ahm00qJ-zDH3w@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: cleanup in code (Andres Freund <andres@2ndquadrant.com>) |
| Список | pgsql-hackers |
On Tue, Jan 7, 2014 at 12:06 AM, Andres Freund <andres@2ndquadrant.com> wrote:
But afair the declaration for elog() works in several other places, soOn 2014-01-06 23:51:52 +1300, David Rowley wrote:
> I looked at this a while back here:
> http://www.postgresql.org/message-id/CAApHDvqOsb4nc3OG0xoBoJ2fmA-6AkihuWsAd43RLekqk6SmCQ@mail.gmail.com
>
> And found that because elevel was being assigned to a variable that the
> compiler could not determine that the if (elevel_ >= ERROR) was constant
> therefore couldn't assume that __assume(0) would be reached with the
> microsoft compiler
that doesn't sufficiently explain this. I'd very much expect that that
variable is complitely elided by any halfway competent compiler - it's
just there to prevent multiple evaluation should elevel not be a
constant.
Just to add more proof to my theory;
If I do this:
//#define pg_unreachable() __assume(0)
#define pg_unreachable() (void)0
I get no extra warnings.
If change the elog macro to get rid of the variable so that the if condition uses the constant then the postgres.exe goes from 4,545,024 bytes to 4,526,592 bytes.
So I guess the __assume(0) does not do much due to elevel being assigned to the variable in the elog macro.
Regards
David Rowley
Do you see the warning both with asserts enabled and non-assert builds?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: