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
