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

New s_lock.h fails on HPUX with gcc

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: New s_lock.h fails on HPUX with gcc
Date: 1998-07-06 20:02:25
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
... because the conditional structure assumes that pgsql will only be
built with non-gcc compilers on HPUX.

This is an entirely bogus assumption not only for HPUX, but for any
other architecture that has gcc available.

To be able to compile, I just duplicated the "#if defined(__hpux)"
block into the "#if defined(__GNUC__)" part of the file, but that's
a pretty grotty hack.  I think that the right way to structure the
file is just this:

#if defined(HAS_TEST_AND_SET)

#if defined(somearchitecture)

#if defined(__GNUC__)
// inline definition of tas here
// non-inline definition of tas here, if default isn't adequate

// machine-dependent-but-compiler-independent definitions here

#endif /* somearchitecture */

// ... repeat above structure for each architecture supported ...

#if !defined(S_LOCK)
// default definition of S_LOCK

// default definitions of other macros done in the same way

#endif /* HAS_TEST_AND_SET */

On architectures where we don't have any special inline code for GCC,
the inner "#if defined(__GNUC__)" can just be omitted in that
architecture's block.

The existing arrangement with an outer "#if defined(__GNUC__)" doesn't
have any obvious benefit, and it encourages missed cases like this one.

BTW, I'd suggest making the definition of clear_lock for HPUX be

static const slock_t clear_lock =
{{-1, -1, -1, -1}};

The extra braces are needed to suppress warnings from gcc, and declaring
it const just seems like good practice.

			regards, tom lane


pgsql-hackers by date

Next:From: David HartwigDate: 1998-07-06 20:30:19
Subject: Re: [HACKERS] Access & Postgres
Previous:From: Bruce MomjianDate: 1998-07-06 09:57:05
Subject: Re: [HACKERS] Information about user`s procces:username and his sql-request?

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