[tz] 2020c zic code draws complaints from Coverity

[Paul Eggert]

On 10/18/20 7:31 AM, Tom Lane wrote:
> The Coverity static-analysis tool [1], which is moderately widely
> used by open-source projects, doesn't much like this:
> 
> 789     	if (bloat == 0)
>>>>      CID 1468262:  Incorrect expression  (CONSTANT_EXPRESSION_RESULT)
>>>>      "strcmp("slim", "slim")" is always 0 because ""slim"" is compared against itself.
> 790     		bloat = strcmp(ZIC_BLOAT_DEFAULT, "slim") == 0 ? -1 : 1;
> 
> This is just a bug-finding heuristic, of course, and it won't trouble
> me that much to ignore the warning.  Still, I wonder why it's coded
> this way

Thanks for reporting that. The idea was to give a way for distributions to 
specify zic's default -b behavior, via:

make CFLAGS='-DZIC_BLOAT_DEFAULT=\"fat\"'

as documented in the Makefile. I didn't want the values -1, 1 (which are 
internal details) to creep into the Makefile instructions, and I was thinking 
that future zic versions might support other -b variants like '-b lean'.

That being said, it'd be nicer to pacify Coverity, and to catch misspellings, so 
I installed the attached proposed patch to try to do that. I don't have access 
to Coverity so someone else will need to try the Coverity part of this patch.

If this doesn't pacify Coverity, perhaps we should just remove support for 
ZIC_BLOAT_DEFAULT as I don't think anybody's using it. Distributions that want 
fat TZif files seem to be using "make ZFLAGS='-b fat'" instead.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fail-on-ZIC_BLOAT_DEFAULT-typo.patch
Type: text/x-patch
Size: 1584 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/tz/attachments/20201018/ffe1b761/attachment.bin>