Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] UnixWare 7.x port updates.

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: Bill(dot)Allie(at)mug(dot)org
Cc: hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] UnixWare 7.x port updates.
Date: 1998-10-04 15:39:03
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> Recent additions to the PostgreSQL 6.4 tree broke the UnixWare 7.x port.  Here 
> are the patches to fix them:
> 1.  In 'src/backend/utils/adt/ip.c', the functions 'ipaddr_eq()' and
>     'ipaddr_ge()' were used before being defined.  I reordered the functions so
>     that they were defined before being used.
> 2.  In 'src/include/utils/mac.h', I included the file 'sys/bitypes.h' if the
>     code is being compiled by a USL compiler (i.e. UnixWare).  This is needed
>     to define the 'u_int32_t' type.


> 3.  In 'src/include/c.h', I add a check to see if 'bool' had been defined as a
>     macro before attempting to typeset it.  In some instances, 'bool' is
>     defined as a macro that expands to 'char'.  The UnixWare compiler complains
>     if you try to compile "typeset char char;".
> 4.  In 'src/pl/plpgsql/src/pl_exec.c', there is a construct that is incorrect.
>     This construct is '((int4)(var->value))--' and '((int4)(var->value))++'.
>     What this is saying is to take result of the expression '(var->value)',
>     cast it as an 'int4', and then increment it.  This can not work as the
>     result of the expression is not an 'LVALUE' and thus can not be the target
>     of the '--' or the '++' operator.  What is needed is '(int4)var->value--'
>     or '(int4)var->value++' [assuming the desired result is to decrement(in-
>     crement) 'var->value' as if it were an 'int4'].
> 5.  In 'src/test/regress/checkresults', the use of the '-u' option is assuming
>     the use of GNU diff.

The rest are applied.

> There were some additional portability problems with the make file for plpgsql 
> that I do not address with these patches.  I will supply a for 
> plpgsql that will address these problems shortly.
> The UnixWare 7.x port now passes the regression tests except for differences 
> in the some error messages and floating point precision.
> BTW:  The plpgsql language seems to working well, at least for the simple
>       things that I am currently using them for.
>       Thanks Jan for the good work on PL/pgsql!
Content-Description: uw7.patch

[Attachment, skipping...]

> ____       | Billy G. Allie    | Domain....: Bill(dot)Allie(at)mug(dot)org
> |  /|      | 7436 Hartwell     | Compuserve: 76337,2061
> |-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie(at)email(dot)msn(dot)com
> |/  |LLIE  | (313) 582-1540    | 

  Bruce Momjian                        |
  maillist(at)candle(dot)pha(dot)pa(dot)us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 1998-10-04 20:00:10
Subject: plpgsql is not ready for prime time
Previous:From: Bruce MomjianDate: 1998-10-04 15:35:52
Subject: Re: [HACKERS] UnixWare 7.x port updates.

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group