extern + static issue in datetime.c
Current sources don't compile on AIX with xlc compiler because of the
combined (and inconsistent ? or compiler bug) use of extern and static
for the datetktbl in datetime.c.
header unconditionally has:
extern datetkn datetktbl[];
source has:
static datetkn datetktbl[] = {
The usual approach would be to avoid that line in the header if included
from datetime.c, but I think it would be better to use a const in this
case.
I think this is a general compatibility problem, and thus needs to be
solved.
Andreas
I wrote:
Current sources don't compile on AIX with xlc compiler because of the
combined (and inconsistent ? or compiler bug) use of extern
and static
for the datetktbl in datetime.c.header unconditionally has:
extern datetkn datetktbl[];source has:
static datetkn datetktbl[] = {The usual approach would be to avoid that line in the header
if includedfrom datetime.c, but I think it would be better to use a const in this
case.I think this is a general compatibility problem, and thus needs to be
solved.
Attached is a patch that might be considered (remove static for these
globals).
Thanks
Andreas
Attachments:
datetime.patchapplication/octet-stream; name=datetime.patchDownload
*** ./src/backend/utils/adt/datetime.c.orig Fri Jul 13 10:00:33 2001
--- ./src/backend/utils/adt/datetime.c Mon Aug 27 17:02:20 2001
***************
*** 70,76 ****
* entries by 10 and truncate the text field at MAXTOKLEN characters.
* the text field is not guaranteed to be NULL-terminated.
*/
! static datetkn datetktbl[] = {
/* text token lexval */
{EARLY, RESERV, DTK_EARLY}, /* "-infinity" reserved for "early time" */
{"acsst", DTZ, 63}, /* Cent. Australia */
--- 70,76 ----
* entries by 10 and truncate the text field at MAXTOKLEN characters.
* the text field is not guaranteed to be NULL-terminated.
*/
! datetkn datetktbl[] = {
/* text token lexval */
{EARLY, RESERV, DTK_EARLY}, /* "-infinity" reserved for "early time" */
{"acsst", DTZ, 63}, /* Cent. Australia */
***************
*** 218,236 ****
{ZULU, RESERV, DTK_ZULU}, /* 00:00:00 */
};
! static unsigned int szdatetktbl = sizeof datetktbl / sizeof datetktbl[0];
/* Used for SET australian_timezones to override North American ones */
! static datetkn australian_datetktbl[] = {
{"cst", TZ, 63}, /* Australia Eastern Std Time */
{"est", TZ, 60}, /* Australia Eastern Std Time */
{"sat", TZ, 57},
};
! static unsigned int australian_szdatetktbl = sizeof australian_datetktbl /
sizeof australian_datetktbl[0];
! static datetkn deltatktbl[] = {
/* text token lexval */
{"@", IGNORE, 0}, /* postgres relative time prefix */
{DAGO, AGO, 0}, /* "ago" indicates negative time offset */
--- 218,236 ----
{ZULU, RESERV, DTK_ZULU}, /* 00:00:00 */
};
! unsigned int szdatetktbl = sizeof datetktbl / sizeof datetktbl[0];
/* Used for SET australian_timezones to override North American ones */
! datetkn australian_datetktbl[] = {
{"cst", TZ, 63}, /* Australia Eastern Std Time */
{"est", TZ, 60}, /* Australia Eastern Std Time */
{"sat", TZ, 57},
};
! unsigned int australian_szdatetktbl = sizeof australian_datetktbl /
sizeof australian_datetktbl[0];
! datetkn deltatktbl[] = {
/* text token lexval */
{"@", IGNORE, 0}, /* postgres relative time prefix */
{DAGO, AGO, 0}, /* "ago" indicates negative time offset */
***************
*** 308,314 ****
{"yrs", UNITS, DTK_YEAR}, /* "years" relative time units */
};
! static unsigned int szdeltatktbl = sizeof deltatktbl / sizeof deltatktbl[0];
datetkn *datecache[MAXDATEFIELDS] = {NULL};
--- 308,314 ----
{"yrs", UNITS, DTK_YEAR}, /* "years" relative time units */
};
! unsigned int szdeltatktbl = sizeof deltatktbl / sizeof deltatktbl[0];
datetkn *datecache[MAXDATEFIELDS] = {NULL};
Import Notes
Resolved by subject fallback
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
Current sources don't compile on AIX with xlc compiler because of the
combined (and inconsistent ? or compiler bug) use of extern and static
for the datetktbl in datetime.c.
Fixed. A pass with HP's compiler also showed up a static-vs-not-static
conflict in network.c.
regards, tom lane