Clean up some stuff in new contrib/bloom module.

Coverity complained about implicit sign-extension in the
BloomPageGetFreeSpace macro, probably because sizeOfBloomTuple isn't wide
enough for size calculations.  No overflow is really possible as long as
maxoff and sizeOfBloomTuple are small enough to represent a realistic
situation, but it seems like a good idea to declare sizeOfBloomTuple as
Size not int32.

Add missing check on BloomPageAddItem() result, again from Coverity.

Avoid core dump due to not allocating so->sign array when
scan->numberOfKeys is zero.  Also thanks to Coverity.

Use FLEXIBLE_ARRAY_MEMBER rather than declaring an array as size 1
when it isn't necessarily.

Very minor beautification of related code.

Unfortunately, none of the Coverity-detected mistakes look like they
could account for the remaining buildfarm unhappiness with this
module.  It's barely possible that the FLEXIBLE_ARRAY_MEMBER mistake
does account for that, if it's enabling bogus compiler optimizations;
but I'm not terribly optimistic.  We probably still have bugs to
find here.

1 files changed, 2 insertions, 2 deletions

diff --git a/contrib/bloom/bloom.h b/contrib/bloom/bloom.h
index fb0bc07f284..8f3881d8446 100644
--- a/contrib/bloom/bloom.h
+++ b/contrib/bloom/bloom.h
@@ -118,7 +118,7 @@ typedef struct BloomState
 	 * sizeOfBloomTuple is index's specific, and it depends on reloptions, so
 	 * precompute it
 	 */
-	int32		sizeOfBloomTuple;
+	Size		sizeOfBloomTuple;
 }	BloomState;
 
 #define BloomPageGetFreeSpace(state, page) \
@@ -134,7 +134,7 @@ typedef uint16 SignType;
 typedef struct BloomTuple
 {
 	ItemPointerData heapPtr;
-	SignType	sign[1];
+	SignType	sign[FLEXIBLE_ARRAY_MEMBER];
 }	BloomTuple;
 
 #define BLOOMTUPLEHDRSZ offsetof(BloomTuple, sign)