On 2026-07-04 14:29, Tom Lane wrote:
Fundamentally, what this statement wants to do is arithmetic on these constants, so how is it not treating them as integers at bottom?
Yes, the cast treats the enum (which is an integer) as an int (which is also an integer, though of a different integer type). And if the cast did only that it would be fine. But in C, casts can do more than change the type of a value: they can also change the the value itself (e.g., by yielding the low order bits of a pointer), which is definitely not wanted here. I'd rather not impose an extra burden on readers to verify that the cast is OK because the identifier is not a pointer and is not floating point and has a value in int range. Of course sometimes a cast is needed for other reasons, and then C code should use a cast despite casts' hazards and hassles; but here a cast is not needed.
I'm not really in a position to test whether MSVC would be happy with this.
Perhaps someone else can try the two patches I mentioned earlier. Another possibility is that builders using MSVC could add /wd4146 and /wd5287 to the compiler flags. That should pacify MSVC without needing to change tzcode. In the meantime there's no rush to apply those two patches, as zic's behavior is fine; this is merely about having compilers generate fewer bogus warnings. I do take the point, though, that the motivation for using unary "+" instead of a cast is not immediately obvious to all, so I installed the attached patch which I hope helps make this clearer.