BUG #18993: [BUG] Unreachable code in pg_next_dst_boundary()

Started by PG Bug reporting form9 months ago3 messagesbugs
Jump to latest
#1PG Bug reporting form
noreply@postgresql.org

The following bug has been logged on the website:

Bug reference: 18993
Logged by: Eugeny Goryachev
Email address: gorcom2012@gmail.com
PostgreSQL version: 17.4
Operating system: Ubuntu
Description:

Hello,
In pg_next_dst_boundary() (src/timezone/localtime.c), the following
condition can never be true:
```
if (tcycles - icycles >= 1 || icycles - tcycles >= 1)
return -1;
```
This is unreachable because icycles is assigned directly from tcycles.

Suggested fix:
Remove this condition entirely

The change is safe as it only removes dead code. All timezone transition
cases are already properly handled by other paths.

Best regards, Eugeny Goryachev

#2Nathan Bossart
nathandbossart@gmail.com
In reply to: PG Bug reporting form (#1)
Re: BUG #18993: [BUG] Unreachable code in pg_next_dst_boundary()

On Mon, Jul 21, 2025 at 12:29:16PM +0000, PG Bug reporting form wrote:

In pg_next_dst_boundary() (src/timezone/localtime.c), the following
condition can never be true:
```
if (tcycles - icycles >= 1 || icycles - tcycles >= 1)
return -1;
```
This is unreachable because icycles is assigned directly from tcycles.

I see the following upstream commit and discussion related to this:

https://github.com/eggert/tz/commit/b0bf6d8
https://mm.icann.org/pipermail/tz/2013-August/019493.html

--
nathan

#3Tom Lane
tgl@sss.pgh.pa.us
In reply to: Nathan Bossart (#2)
Re: BUG #18993: [BUG] Unreachable code in pg_next_dst_boundary()

Nathan Bossart <nathandbossart@gmail.com> writes:

On Mon, Jul 21, 2025 at 12:29:16PM +0000, PG Bug reporting form wrote:

This is unreachable because icycles is assigned directly from tcycles.

I see the following upstream commit and discussion related to this:

Yeah. The short answer here is that this code is meant to deal with
cases where time_t is wider than int[64]. Perhaps we're uninterested
in dealing with that case ... but we also don't want to deviate too
far from the upstream tzdb code. So I'm inclined to leave it alone.
As the function's comment mentions,

* A function result of -1 indicates failure (this case does not actually
* occur in our current implementation).

so presumably both "return -1" lines are unreachable.

regards, tom lane