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?


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?
--
Tatsuo Ishii

Wed, 10 Feb 1999 11:02:44 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
NEXTSTEP porting problems
> 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

Mon, 15 Mar 1999 10:01:22 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] NEXTSTEP porting problems
>> 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

Tue, 16 Mar 1999 10:29:01 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: [HACKERS] NEXTSTEP porting problems 