Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lznTj-00072g-KH for pgsql-hackers@arkaria.postgresql.org; Sat, 03 Jul 2021 21:47:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lznTg-0008HT-Tr for pgsql-hackers@arkaria.postgresql.org; Sat, 03 Jul 2021 21:47:08 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lznTg-0008HK-Eu for pgsql-hackers@lists.postgresql.org; Sat, 03 Jul 2021 21:47:08 +0000 Received: from mail-pl1-x635.google.com ([2607:f8b0:4864:20::635]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lznTd-0001s4-B5 for pgsql-hackers@postgresql.org; Sat, 03 Jul 2021 21:47:07 +0000 Received: by mail-pl1-x635.google.com with SMTP id b5so8019122plg.2 for ; Sat, 03 Jul 2021 14:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=h38KI29LHWXSrJ7oOdyi1PoupjFbgNRa5RSiQbG4HO8=; b=OPaBD+Eo+wbpDdbYH79rawZupxBbOmUxI3Y/ijpxN0fqeNknjbGkPeIYNXutiCJaWI kRVm5CnZKJl0W6ObW6lq3RG9E0Hh7S6YX+nQkywxCN/JBKKkbhQAmi+jea6rP6b0JHyG 5HUlwIpKOl9DWezDjp6+mvs4CE4qspyXjMSvM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=h38KI29LHWXSrJ7oOdyi1PoupjFbgNRa5RSiQbG4HO8=; b=LUw6VtnXnS/D2HqMVWl4413qs3EhKJ9HchHm0f3OhuhwKJBpc75shV8dJgNAIAiX2s aRlx0fXflb68WjEav+U6EuLzSio+fjA/5+ZcnmPogtRtDfAYLMhcZU2twaUNALEujUKI FRV8PYaPkLgt0G00ayVAIJ7qGcJYNqRqbuvNaxiG2ZVHky0JINQoIj5c+DPu35LH0eFE gIlg5vufWP3sNnyv9dWBN19GxsE4cMFUknKLs/U8TpwC1pG3aNNm0EPHsNvVXV+N0qLC whI5J4zwXRdzmDBNypKHshfxjn0lmQN28HMciww4ZbzrEcXBh4MU6wsNw6H++qNjsQSU rKUA== X-Gm-Message-State: AOAM533ZseV/1CqCBNZKkpV2Hj7Z6xeFHKRY79J5w9DgGUhhnDbGdVOX edQqp+zdVICvi1TcRh0ZLvfkLg== X-Google-Smtp-Source: ABdhPJwqsRbTPrBHazwSFMJM3/819N2onbGAkMjy/TTkR5Y99vhEpPlCmALKFTxCmlCMX0Wy/Xk8ww== X-Received: by 2002:a17:902:d487:b029:129:70aa:99a with SMTP id c7-20020a170902d487b029012970aa099amr2336914plg.3.1625348822169; Sat, 03 Jul 2021 14:47:02 -0700 (PDT) Received: from rfd.leadboat.com ([2600:1702:a20:5750::46]) by smtp.gmail.com with ESMTPSA id g11sm9329535pgj.3.2021.07.03.14.47.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 03 Jul 2021 14:47:01 -0700 (PDT) Date: Sat, 3 Jul 2021 14:46:58 -0700 From: Noah Misch To: Tom Lane Cc: Alvaro Herrera , Michael Paquier , Jacob Champion , "pgsql-hackers@postgresql.org" , Daniel Gustafsson , info@cspug.cz Subject: Re: Preventing abort() and exit() calls in libpq Message-ID: <20210703214658.GA2421985@rfd.leadboat.com> References: <202107021459.7c2dkzyg5lua@alvherre.pgsql> <819502.1625239217@sss.pgh.pa.us> <20210703001639.GB2374652@rfd.leadboat.com> <1231771.1625321413@sss.pgh.pa.us> <1233492.1625323559@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1233492.1625323559@sss.pgh.pa.us> User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sat, Jul 03, 2021 at 10:45:59AM -0400, Tom Lane wrote: > I'd imagined leaving, e.g., psprintf.c out of libpgcommon_shlib.a. > But if someone mistakenly introduced a psprintf call into libpq, > it'd still compile just fine; the symbol would be resolved against > psprintf in the calling application's code. I think that would fail to compile on Windows, where such references need exported symbols. We don't make an exports file for applications other than postgres.exe. So the strategy that inspired this may work. > What I'm now thinking about is restricting the test to only be run on > platforms where use of foo.a libraries is deprecated, so that we can > be pretty sure that we won't hit this situation. Even if we only > run the test on Linux, that'd be plenty to catch any mistakes. Hmm. Static libraries are the rarer case on both AIX and Linux, but I'm not aware of a relevant deprecation on either platform. If it comes this to, I'd be more inclined to control the Makefile rule with an environment variable (e.g. ENFORCE_LIBC_CALL_RESTRICTIONS) instead of reacting to the platform.