Horton

Re: Preventing abort() and exit() calls in libpq

Peter Eisentraut <peter.eisentraut@enterprisedb.com>

View thread View on postgr.es
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jacob Champion <pchampion@vmware.com>, "daniel@yesql.se" <daniel@yesql.se>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, "michael@paquier.xyz" <michael@paquier.xyz>
Date: 2021-07-01T19:03:58Z
Lists: pgsql-hackers 
On 01.07.21 20:14, Tom Lane wrote:
> The variant of this I'd been thinking of was
> 
>   $(shlib): $(OBJS) | $(SHLIB_PREREQS)
>   	$(LINK.shared) -o $@ $(OBJS) $(LDFLAGS) $(LDFLAGS_SL) $(SHLIB_LINK)
> +ifneq (,$(SHLIB_EXTRA_ACTION))
> +	$(SHLIB_EXTRA_ACTION)
> +endif
> 
> (and similarly in several other places); then libpq's Makefile
> could set SHLIB_EXTRA_ACTION to the desired thing.

Right, that looks sensible.  (Maybe the ifneq isn't actually necessary, 
since if the variable is not set, nothing would happen.)

> The problem then is, what happens when the extra action fails?
> Without .DELETE_ON_ERROR, the shlib is still there and the next
> make run will think everything's good.

Right.  .DELETE_ON_ERROR is already set in Makefile.global, so it's not 
necessary to set it again.

Commits

  1. Further restrict the scope of no-exit()-in-libpq test.

  2. Improve build-time check that libpq doesn't call exit().

  3. Fix portability fallout from commit dc227eb82.

  4. Add a build-time check that libpq doesn't call exit() or abort().