NEXTSTEP porting problems

What about using #if 0 or #if PG_FALSE or whatever instead of #if
FALSE?

I think the consensus was to use:

#ifdef NOT_USED

in these cases

Andreas

A NEXTSTEP3.3 user reported some porting problems.

1. #if FALSE problem

For example in src/include/utils/int8.h:

#if FALSE
extern int64 *int28 (int16 val);
extern int16 int82(int64 * val);

#endif

Unfortunately in NEXTSTEP FALSE has been already defined as:

#define FALSE ((boolean_t) 0)

What about using #if 0 or #if PG_FALSE or whatever instead of #if
FALSE?

Done, by you, I think.

2. Datum problem

NEXTSTEP has its own "Datum" type and of course it coflicts with
PostgreSQL's Datum. Possible solution might be put below into c.h:

#ifdef NeXT
#undef Datum
#define Datum PG_Datum
#define DatumPtr PG_DatumPtr
#endif

Comments?

Is Datum a #define on NextStep. Can we just #undef it?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

A NEXTSTEP3.3 user reported some porting problems.

1. #if FALSE problem

For example in src/include/utils/int8.h:

#if FALSE
extern int64 *int28 (int16 val);
extern int16 int82(int64 * val);

#endif

Unfortunately in NEXTSTEP FALSE has been already defined as:

#define FALSE ((boolean_t) 0)

What about using #if 0 or #if PG_FALSE or whatever instead of #if
FALSE?

Done, by you, I think.

Yes. Marc has applied my patch.

2. Datum problem

NEXTSTEP has its own "Datum" type and of course it coflicts with
PostgreSQL's Datum. Possible solution might be put below into c.h:

#ifdef NeXT
#undef Datum
#define Datum PG_Datum
#define DatumPtr PG_DatumPtr
#endif

Comments?

Is Datum a #define on NextStep. Can we just #undef it?

I will ask the NextStep user.
--
Tatsuo Ishii