[tz] Compiler warning in tzcode2016g about SIZE_MAX being wider than int

[Tom Lane]

I wrote:
> Paul Eggert <eggert at cs.ucla.edu> writes:
>> On 10/20/2016 04:05 PM, Paul Eggert wrote:
>>> I'll see if I can rewrite the code to remove the INT_MAX restriction, 
>>> which is arbitrary here.

>> Done, by installing the attached patch into the development repository. 
>> I don't know whether this will pacify Clang, but at least it fixes some 
>> (mostly theoretical) bugs in zic.

> Thanks, I can confirm that this silences the warning with macOS's
> version of clang.  I'm a little confused as to why, since on this
> machine ptrdiff_t is "long int" and size_t is "long unsigned int",
> so that SIZE_MAX still doesn't fit into amax if one is being pedantic.

I installed this update into Postgres, and now our weekly run of Coverity
is unhappy:

*** CID 1373152:  Control flow issues  (DEADCODE)
/srv/coverity/git/pgsql-git/92stable/src/timezone/zic.c: 452 in growalloc()
446     {
447     	if (nitems < *nitems_alloc)
448     		return ptr;
449     	else
450     	{
451     		ptrdiff_t	nitems_max = PTRDIFF_MAX - WORK_AROUND_QTBUG_53071;
>>>     CID 1373152:  Control flow issues  (DEADCODE)
>>>     Execution cannot reach the expression "18446744073709551615UL" inside this statement: "amax = ((nitems_max < 18446...".
452     		ptrdiff_t	amax = nitems_max < SIZE_MAX ? nitems_max : SIZE_MAX;
453     
454     		if ((amax - 1) / 3 * 2 < *nitems_alloc)
455     			memory_exhausted(_("integer overflow"));
456     		*nitems_alloc += (*nitems_alloc >> 1) + 1;
457     		return erealloc(ptr, size_product(*nitems_alloc, itemsize));

This is sort of the same thing as the original clang complaint, although
expressed differently: the test against SIZE_MAX is still useless because
it doesn't fit in ptrdiff_t any more than it did in int.

If I were you, I'd change growalloc() so that its nitems-related arguments
are defined as size_t not ptrdiff_t, and forget about this idea that
ptrdiff_t has anything to do with the limit of what can be requested from
malloc.  None of this hoop-jumping has anything to do with any data set
zic will ever see, anyway.

			regards, tom lane