Re: Porting reports (cont'd)

On Fri, 5 May 2000, Thomas Lockhart wrote:

About Unixware 7, I sent a few reports for witch I did'nt get answer.

I did see some traffic about this; not sure if it was with you or with
Billie Allie (sp?).

There are 2 problems:
backend/utils/adt/int8.c doesn't compile out of the box.
changing around line 416 (for loop) the test i > 0 by 0 < i as previously
reported help things.
Although I haven't tried, I'm quite sur changing anything else would help
the same way...

Ok!! May be this one won't hurt any sensibility!

Change the test from i > 0 to i

It means the same thing, i can't go negative because of the test below, it
works on all systems (including brain dead SCO compiler) and doesn't
change the source so much.

I'll try to publish a patch this week -end.

Compiler bugs are a PITA. But Postgres can't have inline code to
handle all cases, esp. cases like this. "if (var op const)" is imho
the usual style for comparisons, and obfuscating that for a single
buggy platform isn't a Good Thing.

The second is more tricky: On UW 71x, accept call has a bug (witch doesn't
exist in 7.01). in case of a unix domain sa_family is set to 0 instead of
1 (AF_UNIX)...
What I did was to add the following lines after accept in pqcomm.c:
if (port->raddr.sa.sa_family == 0)
port->raddr.sa.sa_family = AF_UNIX;

OK, more bugs in the same category as above (esp. since they don't
exist on other versions of UW even). Check the current SCO FAQ, and if
these aren't mentioned then please add some words. Also, if you want
to post a full patch for either or both problems, then other UW users
can have a workaround until SCO gets around to fixing their problems.

Sorry for not being able to do more, but platform bugs are really a
case-by-case thing, and these two both seem to put the burden on the
platform to get it right imho.

Regards.

- Thomas

You've been very helpfull; many thanks

Regards,
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)

About Unixware 7, I sent a few reports for witch I did'nt get answer.

I did see some traffic about this; not sure if it was with you or with
Billie Allie (sp?).

There are 2 problems:
backend/utils/adt/int8.c doesn't compile out of the box.
changing around line 416 (for loop) the test i > 0 by 0 < i as previously
reported help things.
Although I haven't tried, I'm quite sur changing anything else would help
the same way...

Compiler bugs are a PITA. But Postgres can't have inline code to
handle all cases, esp. cases like this. "if (var op const)" is imho
the usual style for comparisons, and obfuscating that for a single
buggy platform isn't a Good Thing.

The bigger problem is that just fixes the comparison done by the
regression tests. Who knows how many other comparisons are broken. I
say leave it broken and don't trust it. If we fix just the
regression-shown fault, we give users a false sense of security.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@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

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Compiler bugs are a PITA. But Postgres can't have inline code to
handle all cases, esp. cases like this. "if (var op const)" is imho
the usual style for comparisons, and obfuscating that for a single
buggy platform isn't a Good Thing.

The bigger problem is that just fixes the comparison done by the
regression tests. Who knows how many other comparisons are broken. I
say leave it broken and don't trust it. If we fix just the
regression-shown fault, we give users a false sense of security.

Excellent point...

What we've usually done in the past, when faced with compiler problems,
is to cut down the optimization setting selected by the platform's
template file. If that helps for Unixware then it'd make sense to do
it, IMHO.

regards, tom lane

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Compiler bugs are a PITA. But Postgres can't have inline code to
handle all cases, esp. cases like this. "if (var op const)" is imho
the usual style for comparisons, and obfuscating that for a single
buggy platform isn't a Good Thing.

The bigger problem is that just fixes the comparison done by the
regression tests. Who knows how many other comparisons are broken. I
say leave it broken and don't trust it. If we fix just the
regression-shown fault, we give users a false sense of security.

Excellent point...

What we've usually done in the past, when faced with compiler problems,
is to cut down the optimization setting selected by the platform's
template file. If that helps for Unixware then it'd make sense to do
it, IMHO.

Agreed.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@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