Andrew Gierth and...@tao11.riddles.org.uk wrote:
I didn't replace the 0x ones because most or all of them looked
like basically bit-masking operations rather than actually dealing with
the bounds of an unsigned int or uint32. I was specifically looking for
places where literals were
Kevin == Kevin Grittner kgri...@ymail.com writes:
I didn't replace the 0x ones because most or all of them
looked like basically bit-masking operations rather than actually
dealing with the bounds of an unsigned int or uint32. I was
specifically looking for places where literals
Hello,
Grep showed me some unfixed usages of bare constant or INT64CONST
as (u)int64 max/min values.
At Tue, 24 Mar 2015 21:57:42 +, Andrew Gierth and...@tao11.riddles.org.uk
wrote in 87619q6ouh@news-spur.riddles.org.uk
Kevin == Kevin Grittner kgri...@ymail.com writes:
Kevin Well,
Kyotaro == Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp writes:
Kyotaro Hello,
Kyotaro Grep showed me some unfixed usages of bare constant or
Kyotaro INT64CONST as (u)int64 max/min values.
Kyotaro ./src/interfaces/ecpg/pgtypeslib/dt.h:
I didn't touch the ecpg stuff since it wasn't too
Hi,
On 2015-03-22 17:20:22 +, Andrew Gierth wrote:
This replaces the one I posted before; it does both INT64_MIN/MAX and
INT32_MIN/MAX, and also int16/int8/uint*. Uses of 0x7fff in code
have been replaced unless there was a reason not to, with either INT_MAX
or INT32_MAX according to
Andres == Andres Freund and...@anarazel.de writes:
This replaces the one I posted before; it does both INT64_MIN/MAX and
INT32_MIN/MAX, and also int16/int8/uint*. Uses of 0x7fff in code
have been replaced unless there was a reason not to, with either INT_MAX
or INT32_MAX according to
On Sun, Mar 22, 2015 at 2:26 AM, Andres Freund and...@anarazel.de wrote:
I have been annoyed by this multiple times. I think we should make sure the
C99 defines are there (providing values if they aren't) and always use those.
We've used them in parts of the tree long enough that it's
On March 22, 2015 6:19:52 AM GMT+01:00, Andrew Gierth
and...@tao11.riddles.org.uk wrote:
Andrew == Andrew Gierth and...@tao11.riddles.org.uk writes:
Petr == Petr Jelinek p...@2ndquadrant.com writes:
So wouldn't it make more sense to move these definitions into c.h
and
standardize their
Andres == Andres Freund and...@anarazel.de writes:
Hm, it looks like the same could be said for INT32_MIN and _MAX;
some places use INT_MIN etc., others say we shouldn't assume int =
int32 and use (-0x7fff - 1) or whatever instead.
Andres I have been annoyed by this multiple times. I
On 21/03/15 23:45, Andrew Gierth wrote:
A couple of places (adt/timestamp.c and pgbench.c) have this:
#ifndef INT64_MAX
#define INT64_MAX INT64CONST(0x7FFF)
#endif
#ifndef INT64_MIN
#define INT64_MIN (-INT64CONST(0x7FFF) - 1)
#endif
On the other hand,
Petr == Petr Jelinek p...@2ndquadrant.com writes:
So wouldn't it make more sense to move these definitions into c.h and
standardize their usage?
Petr I was thinking the same when I've seen Peter's version of Numeric
Petr abbreviations patch. So +1 for that.
Suggested patch attached.
--
A couple of places (adt/timestamp.c and pgbench.c) have this:
#ifndef INT64_MAX
#define INT64_MAX INT64CONST(0x7FFF)
#endif
#ifndef INT64_MIN
#define INT64_MIN (-INT64CONST(0x7FFF) - 1)
#endif
On the other hand, int8.c uses the INT64_MIN expression directly
Andrew == Andrew Gierth and...@tao11.riddles.org.uk writes:
Petr == Petr Jelinek p...@2ndquadrant.com writes:
So wouldn't it make more sense to move these definitions into c.h and
standardize their usage?
Petr I was thinking the same when I've seen Peter's version of Numeric
Petr
13 matches
Mail list logo
