> "Kyotaro" == Kyotaro HORIGUCHI 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 clear that it was sa
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
wrote in <87619q6ouh@news-spur.riddles.org.uk>
> > "Kevin" == Kevin Grittner writes:
> Kevin> Well, InvalidSerCommitSeqNo was initiall
> "Kevin" == Kevin Grittner 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 wer
Andrew Gierth 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 being used to represent m
> "Andres" == Andres Freund 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 the
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
On Sun, Mar 22, 2015 at 2:26 AM, Andres Freund 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 unlikely to cause
> pr
> "Andres" == Andres Freund 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 th
On March 22, 2015 6:19:52 AM GMT+01:00, Andrew Gierth
wrote:
>> "Andrew" == Andrew Gierth writes:
>
>> "Petr" == Petr Jelinek 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 s
> "Andrew" == Andrew Gierth writes:
> "Petr" == Petr Jelinek 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 t
> "Petr" == Petr Jelinek 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.
--
Andrew
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, int8.c
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 in
13 matches
Mail list logo
