Question about src/timezone/zic.c

From: John Cochran <j69cochran(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Question about src/timezone/zic.c
Date: 2014-07-16 21:36:34
Message-ID: CAGQU3n5wFrvto97pb-RegJk3JPOEM=EKQFZtsRwO0QCCochsbA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I've recently found some time on my hands and have decided to see about
contributing to the PostgreSQL project, so I've started browsing the code
to get somewhat familiar with it.

The file src/timezone/zic.c caused me to raise my eyebrows a bit and I have
a question to ask because of this.

I first noticed some loops dealing with the time that I suspect could be
replaced with straight line code calling the julian date conversions. But
in attempting to understand exactly what the loops were doing, I saw some
calls to eitol() which is the function that I'm really questioning. The
code for eitol() is as follows:

static long
eitol(int i)
{
long l;

l = i;
if ((i < 0 && l >= 0) || (i == 0 && l != 0) || (i > 0 && l <= 0))
{
(void) fprintf(stderr,
_("%s: %d did not sign extend correctly\n"),
progname, i);
exit(EXIT_FAILURE);
}
return l;
}

As you can see, all that function does is perform a length extension of a
signed int to a signed long. Additionally, it has a fair amount of code to
verify that the sign extension was properly done. Since the sign extension
is actually performed via the simple "l=i;" statement towards the beginning
of the function, it's rather obvious that we're relying upon the compiler
to perform the sign extension. Additionally, since this function doesn't
have any recovery if an invalid extension is performed, it means that if a
faulty compiler is encountered, PostgreSQL will always fail to operate the
instant any timezone computation is performed.

This raises the question of "Does anyone on this mailing list know of any C
compiler that fails to properly sign extend an assignment of an int to a
long?" Or to put it another way, "Are there any C compilers that fail to
properly perform integer promotion from int to long?"

As things stand, it looks to me like that function eitol() can be simply
deleted and the 22 calls to that function also removed. Shorter,
simpler,faster code is always a good thing after all.

Thank you for reading,
John Cochran

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-07-16 22:26:29 Re: [GSoC2014] Patch ALTER TABLE ... SET LOGGED
Previous Message Fabrízio de Royes Mello 2014-07-16 20:36:40 Re: [GSoC2014] Patch ALTER TABLE ... SET LOGGED