Thread: Re: Porting reports (cont'd)
> 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 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
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
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, Pennsylvania19026
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, Pennsylvania19026