I realize it's a bit late to jump in here with the path already having been
committed. But I think there's a point that was missed in the discussion.
One reason to do the test as Tom recommended is that the warning probably
indicates that the test as written was just going to be optimized away as
On fre, 2011-08-12 at 11:46 -0700, David E. Wheeler wrote:
I figure there might be warnings you haven't seen if you haven't been
building with bonjour, perl, openssl, pam, libxml, or ossp-uuid, so
I've attached the output.
We have a build farm member (smew) that covers all of that except
On Aug 12, 2011, at 12:09 PM, Peter Eisentraut wrote:
I figure there might be warnings you haven't seen if you haven't been
building with bonjour, perl, openssl, pam, libxml, or ossp-uuid, so
I've attached the output.
We have a build farm member (smew) that covers all of that except
On 12 August 2011 20:10, David E. Wheeler da...@kineticode.com wrote:
Ah, great, thanks!
Unfortunately, you'll need to build your own Clang to be up to speed
on the work I've done here, because the Clang developers both fixed
the spurious warning from assigning past what appears to be the end of
On 5 August 2011 20:07, Tom Lane t...@sss.pgh.pa.us wrote:
This patch is a truly horrid idea, as it eliminates the error checking
the compiler is trying to provide, and does so globally not only in the
trouble spots.
I think that the mistake I may have made here was assuming that the
existing
Peter Geoghegan pe...@2ndquadrant.com writes:
On 5 August 2011 20:07, Tom Lane t...@sss.pgh.pa.us wrote:
If I were trying to get rid of this warning, I'd be wondering why
ReplNodeTag is a distinct enum in the first place.
Indeed, that doesn't seem to be justified anywhere, and seems to be a
On Thu, Aug 4, 2011 at 4:49 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
Can we please commit a fix for this problem?
Done.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On 5 August 2011 17:12, Robert Haas robertmh...@gmail.com wrote:
On Thu, Aug 4, 2011 at 4:49 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
Can we please commit a fix for this problem?
Done.
Thanks Robert.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
Now, apart from the Flex warning, there are just 3 warnings left. They
all look like this:
repl_gram.y:106:30: warning: implicit conversion from enumeration type
'enum ReplNodeTag' to different enumeration type 'NodeTag' (aka 'enum
NodeTag') [-Wconversion]
Peter Geoghegan pe...@2ndquadrant.com writes:
Now, apart from the Flex warning, there are just 3 warnings left. They
all look like this:
repl_gram.y:106:30: warning: implicit conversion from enumeration type
'enum ReplNodeTag' to different enumeration type 'NodeTag' (aka 'enum
NodeTag')
Peter Geoghegan pe...@2ndquadrant.com writes:
On 3 August 2011 21:03, Tom Lane t...@sss.pgh.pa.us wrote:
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
On 4 August 2011 07:08, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Geoghegan pe...@2ndquadrant.com writes:
On 3 August 2011 21:03, Tom Lane t...@sss.pgh.pa.us wrote:
I mean that it's unclear what you'll get if status has a bitpattern
equivalent to a negative integer. If the compiler implements
Can we please commit a fix for this problem?
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 3 August 2011 00:52, Peter Geoghegan pe...@2ndquadrant.com wrote:
Now, the only warning that remains is that same
Correction - there are actually 3 additional warnings like this in repl_gram.c:
/home/peter/build/Release/bin/clang -O2 -Wall -Wmissing-prototypes
-Wpointer-arith
Attached patch removes the tautologolical part of an evaluated
expression, fixing the problem flagged by this quite valid warning.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
diff --git a/src/interfaces/libpq/fe-exec.c
On 03.08.2011 12:25, Peter Geoghegan wrote:
Attached patch removes the tautologolical part of an evaluated
expression, fixing the problem flagged by this quite valid warning.
The check is only tautological if the compiler implements enums as
unsigned integers. Whether enums are signed or not
On 3 August 2011 10:34, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
The check is only tautological if the compiler implements enums as unsigned
integers. Whether enums are signed or not is implementation-dependent.
Perhaps cast status to unsigned or signed explicitly before
On 03.08.2011 13:05, Peter Geoghegan wrote:
I don't believe that the standard allows for an implementation of
enums as unsigned integers - after all, individual enum literals can
be given corresponding negative integer values.
C99 says:
Each enumerated type shall be compatible with char, a
On 3 August 2011 11:05, Peter Geoghegan pe...@2ndquadrant.com wrote:
I don't believe that the standard allows for an implementation of
enums as unsigned integers - after all, individual enum literals can
be given corresponding negative integer values.
It actually gives leeway to implement the
On 03.08.2011 14:13, Peter Geoghegan wrote:
On 3 August 2011 11:05, Peter Geogheganpe...@2ndquadrant.com wrote:
I don't believe that the standard allows for an implementation of
enums as unsigned integers - after all, individual enum literals can
be given corresponding negative integer values.
On 3 August 2011 12:19, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Right, but the purpose of that check is to defend from programmer error. If
the programmer screws up and calls PQresStatus(-1), we want to give an
error, not crash. If you assume that the programmer will only
It occurred to me that you may be a little surprised that the patch
actually prevents the warning from occurring. If you have any doubts,
I can assure you that it does. Clang differentiates between 0 as an
rvalue, 0 from an enum literal and 0 resulting from evaluating a macro
expression (including
Peter Geoghegan pe...@2ndquadrant.com writes:
On 3 August 2011 12:19, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Right, but the purpose of that check is to defend from programmer error. If
the programmer screws up and calls PQresStatus(-1), we want to give an
error, not
On 3 August 2011 15:29, Tom Lane t...@sss.pgh.pa.us wrote:
No, this is not an improvement at all. The point of the code is that we
are about to use the enum value as an integer array subscript, and we
want to make sure it is within the array bounds. Tying that logic to
some member of the
On Aug 3, 2011, at 1:47 AM, Peter Geoghegan wrote:
So, there are 4 remaining warnings.
I haven't been paying attention to warnings, but FWIW 9.1beta3 has been
building with LLVM by default with Xcode 4. Both on Snow Leopard and on Lion I
saw something like this:
try=# select version();
On ons, 2011-08-03 at 10:25 +0100, Peter Geoghegan wrote:
Attached patch removes the tautologolical part of an evaluated
expression, fixing the problem flagged by this quite valid warning.
I think these warnings are completely bogus and should not be worked
around. Even in the most trivial
On ons, 2011-08-03 at 10:33 -0700, David E. Wheeler wrote:
I haven't been paying attention to warnings, but FWIW 9.1beta3 has
been building with LLVM by default with Xcode 4. Both on Snow Leopard
and on Lion I saw something like this:
try=# select version();
version
On Aug 3, 2011, at 11:17 AM, Peter Eisentraut wrote:
Note that what you are using there is a GCC frontend with a LLVM
backend. (So I suppose you would get mostly GCC warnings.) Clang is a
new/different compiler frontend using the LLVM backend.
Yeah, not sure whether or not to tweak the
On 3 Aug 2011, at 19:20, David E. Wheeler wrote:
Yeah, not sure whether or not to tweak the Makefile to use Clang. I guess not?
export CC=clang
./configure
...
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Aug 3, 2011, at 11:28 AM, Grzegorz Jaskiewicz wrote:
export CC=clang
./configure
...
Thanks, I'll give that a try the next time I build (RC1 I guess).
David
Peter Geoghegan pe...@2ndquadrant.com writes:
On 3 August 2011 15:29, Tom Lane t...@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
On Wed, Aug 03, 2011 at 04:03:39PM -0400, Tom Lane wrote:
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
On 3 August 2011 21:03, Tom Lane t...@sss.pgh.pa.us wrote:
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.
On compilers on which the
On Wed, Aug 03, 2011 at 01:40:42PM +0300, Heikki Linnakangas wrote:
On 03.08.2011 13:05, Peter Geoghegan wrote:
I don't believe that the standard allows for an implementation of
enums as unsigned integers - after all, individual enum literals can
be given corresponding negative integer values.
On 04.08.2011 04:21, David Fetter wrote:
On Wed, Aug 03, 2011 at 01:40:42PM +0300, Heikki Linnakangas wrote:
On 03.08.2011 13:05, Peter Geoghegan wrote:
I don't believe that the standard allows for an implementation of
enums as unsigned integers - after all, individual enum literals can
be
35 matches
Mail list logo
