Re: Further news on Clang - spurious warnings
От | Tom Lane |
---|---|
Тема | Re: Further news on Clang - spurious warnings |
Дата | |
Msg-id | 22550.1312401819@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Further news on Clang - spurious warnings (Peter Geoghegan <peter@2ndquadrant.com>) |
Ответы |
Re: Further news on Clang - spurious warnings
Re: Further news on Clang - spurious warnings |
Список | pgsql-hackers |
Peter Geoghegan <peter@2ndquadrant.com> writes: > On 3 August 2011 15:29, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> There is another point here, though, which is that if we're not sure >> whether the compiler considers ExecStatusType to be signed or unsigned, >> then we have no idea what the test "status < PGRES_EMPTY_QUERY" even >> means. > I'm sorry, but I don't know what you mean by this. I mean that it's unclear what you'll get if status has a bitpattern equivalent to a negative integer. If the compiler implements the comparison as signed, the test will yield TRUE; if unsigned, it's FALSE. >> So I think the most reasonable fix is probably >> >> if ((unsigned int) status >= sizeof pgresStatus / sizeof pgresStatus[0]) >> >> which is sufficient to cover both directions, since if status is passed >> as -1 then it will convert to a large unsigned value. It's also a >> natural expression of what we really want, ie, that the integer >> equivalent of the enum value is in range. > I'm not convinced that that is an improvement to rely on the > conversion doing so, but it's not as if I feel very strongly about it. The C standard specifies that signed-to-unsigned conversions must work like that; and even if the standard didn't, it would surely work like that on any machine with two's-complement representation, which is to say every computer built in the last forty years or so. So I don't find it a questionable assumption. regards, tom lane
В списке pgsql-hackers по дате отправления: