Обсуждение: pgsql: Silence some Coverity warnings and improve code consistency.

Silence some Coverity warnings and improve code consistency.

Coverity complained about possible overflow in expressions like
        intresult = tm->tm_sec * 1000000 + fsec;
on the grounds that the multiplication would happen in 32-bit
arithmetic before widening to the int64 result.  I think these
are all false positives because of the limited possible range of
tm_sec; but nonetheless it seems silly to spell it like that when
nearby lines have the identical computation written with a 64-bit
constant.

... or more accurately, with an LL constant, which is not project
style.  Make all of these use INT64CONST(), as we do elsewhere.

This is all new code from a2da77cdb, so no need for back-patch.

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/6277435a8a89c59f716c111200c072d1454b8ff2

Modified Files
--------------
src/backend/utils/adt/date.c      | 14 +++++++-------
src/backend/utils/adt/timestamp.c | 26 +++++++++++++-------------
2 files changed, 20 insertions(+), 20 deletions(-)

On 11.04.21 23:02, Tom Lane wrote:
> ... or more accurately, with an LL constant, which is not project
> style.  Make all of these use INT64CONST(), as we do elsewhere.

I think this style could be considered obsolete because C99 requires LL 
constants, and configure checks for it.

Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> On 11.04.21 23:02, Tom Lane wrote:
>> ... or more accurately, with an LL constant, which is not project
>> style.  Make all of these use INT64CONST(), as we do elsewhere.

> I think this style could be considered obsolete because C99 requires LL 
> constants, and configure checks for it.

I'm not worried about whether compilers will take LL --- after all, we
also make free use of "long long" these days.  I am worried that
it does not necessarily equate to int64 exactly.

In any case, I'm not a fan of TIMTOWTDI.  If we want to remove
[U]INT64CONST in favor of [U]LL, we should do so across the board,
so as to maintain a consistent project style.

            regards, tom lane