Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tvDve-002OSf-PO for pgsql-committers@arkaria.postgresql.org; Thu, 20 Mar 2025 11:19:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tvDuf-002WoZ-Da for pgsql-committers@arkaria.postgresql.org; Thu, 20 Mar 2025 11:18:13 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tvDuf-002Wnd-3R for pgsql-committers@lists.postgresql.org; Thu, 20 Mar 2025 11:18:13 +0000 Received: from mail-lj1-x22b.google.com ([2a00:1450:4864:20::22b]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tvDuc-0007Rs-2Y for pgsql-committers@lists.postgresql.org; Thu, 20 Mar 2025 11:18:12 +0000 Received: by mail-lj1-x22b.google.com with SMTP id 38308e7fff4ca-30613802a59so7539531fa.0 for ; Thu, 20 Mar 2025 04:18:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742469489; x=1743074289; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=NQG6rn74dUvhpBo8MYPpcwEbalnZfiVZlQImhjFTGE4=; b=eXMkEW7VJPt5hV8Wt1hD6wCHtry930nu4TlGw/YShvrE2ih+l3YL+EzUhoZ7vGUDcL y/VWLoEVNV9ltSiSxutOIq4v96KdITkEPoQ3Hb6pkuOxhXZ5FNMDhm9t4H1XnckbOsON KaYyWi4P797feplRwivZRMaCrlnkSTx7xZOZQaB7JExTBCLzEClVAjVOsug5HZdFRMQ0 J50Fc1dYTCJo0uKWBrm4tfIpN90jX3lbnAKlr53ih3w1poUpdKysKjfOKCuRnBNiAQ6W RYp5uioOqiWwR9Oci5Q1ZlKRD6X7VLWJCIRAztozb9Ywg0Xgafggt3NOmoYx23JrYgwg qbMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742469489; x=1743074289; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=NQG6rn74dUvhpBo8MYPpcwEbalnZfiVZlQImhjFTGE4=; b=Ewo1u7gpkEf3QKvDprYYqsYnFI893f905r99+s0nzXDs+q0PwsC3/x8xQlleaZ9vBD CSeiWpp/MX5RZDDXcq9ZMdJaA3JJs/brtf0CDL1iQ+F/gnegsOF6k0i6uQd+12PwEiM+ IUAGNY+IYLYlG+8aTJ6VFJ9sD7vBdWdmWvmOnexD+jiF2rzfU3nZv1CFUji62EJhnFA2 9tROw67GvXwQPQ9QUL6h2wCt6N/G7QZSIZeVYGt1eiHeWiBeY0aJOPDONpXGRu/xNc/G n+L9e9HHCGB62kcn9i1Xwvve++0OlPnqrHmP9EXQ9FXpCmdeJkCoRrMvLHgmvhY3nrvK cgqQ== X-Forwarded-Encrypted: i=1; AJvYcCUtWrZJggSIS+GFCAbwE56FontXATmrptOd5ESJcJgBVuCbXZYCRWqlNMJUNZEy9VNP+Hqrxydv3Hjhq9GcCSu4@lists.postgresql.org X-Gm-Message-State: AOJu0YwRJYNSSHF4rmmiyVe2JDhFaZc777VAy/01aEnoZg3OKwypVco6 D58twgjSggNOx7knfauR8xAPuvn76mp2SdPKdd7kr6MELEevJNuZ78jMrjnDUR8GmPjn/S4dMt4 nxfLiPlWB1rkNzCPNsHrFHyH7I2wNpp85 X-Gm-Gg: ASbGncv+4LSJUXj13+JHA/wAbrjK/ZPOBLdQbQclX067c754c3q0Bwf90m7Bdq46H6x lqhHfct53GL0fnOAQtLdENuGfpSQwb9mqv1OXcGkQnC6T14VaWYZlXsvZVdSJSQAbgmcJXxF9rX hofNeuI8go843a909KFDc/UKylGexL0S08++ihcxFrdqfOczihaRBHXOH/N0De X-Google-Smtp-Source: AGHT+IHNRtHKURj9V7ujxl9VU4f9i3StyGOSpzNvV6I2a5ZQ8O0Zz7sEHPzQuu+9t+noU32Gjb3ue8VAvfJBLHjACUo= X-Received: by 2002:a05:6512:224e:b0:549:55df:8af6 with SMTP id 2adb3069b0e04-54ad06876a6mr726699e87.53.1742469488774; Thu, 20 Mar 2025 04:18:08 -0700 (PDT) MIME-Version: 1.0 References: <6c00a8b2-0c40-44f0-b603-f6ae28b7694a@eisentraut.org> In-Reply-To: From: David Rowley Date: Fri, 21 Mar 2025 00:17:56 +1300 X-Gm-Features: AQ5f1Jr7LFP9J7oMvMw33qZIWbbQnrJCPTOwjo4NHIj5eIKeHUm6fMUaVpn3WWk Message-ID: Subject: Re: pgsql: pg_logicalinspect: Fix possible crash when passing a directory p To: Peter Eisentraut Cc: Masahiko Sawada , pgsql-committers@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, 13 Mar 2025 at 21:33, Peter Eisentraut wrote: > Ok, this is weird, because we have pg_unreachable() support for MSVC: > > #if defined(HAVE__BUILTIN_UNREACHABLE) && !defined(USE_ASSERT_CHECKING) > #define pg_unreachable() __builtin_unreachable() > #elif defined(_MSC_VER) && !defined(USE_ASSERT_CHECKING) > #define pg_unreachable() __assume(0) > #else > #define pg_unreachable() abort() > #endif > > Is there a way to reshuffle those conditionals to make this actually do > something useful on MSVC? I've just been experimenting with this and it seems the problem isn't with pg_unreachable(), it's with the compiler not understanding that the particular pg_unreachable() is always reached. What's happening is down to the multi-eval protection code for elevel in ereport_domain(). Because elevel is assigned to the variable "elevel_" the compiler seems to lose its proof that the pg_unreachable() is always reached. Adjusting that condition to use the elevel parameter directly makes the warning disappear. I looked around to see if MSVC might have something to allow us to fix this, but didn't find anything. There does not seem to be any sort of __builtin_constant_p with MSVC, otherwise we could've done something similar to the HAVE__BUILTIN_CONSTANT_P version of ereport_domain just above. > Are you compiling with assertions on in this case? Does anything change > about this if you don't use assertions (or vice versa)? It happens with both. David