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