From patchwork Fri Apr 19 11:28:37 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 1925512 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=iiAdI+W4; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=8.43.85.97; helo=server2.sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=patchwork.ozlabs.org) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4VLXTq0qpXz1yZP for ; Fri, 19 Apr 2024 21:29:02 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8F32D3849AE8 for ; Fri, 19 Apr 2024 11:29:00 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 96671384AB7E for ; Fri, 19 Apr 2024 11:28:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 96671384AB7E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 96671384AB7E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713526123; cv=none; b=LXK68sJKSW0c4cDg85fp24JZ7H6WS5tEHwOFdAwBoUArLyh/WrMCPBl/1ZquwyQHgNMShdqdHOFH1/S4VuhFA2KVtRECEvFnYbH9yHz8zR1z54sEGJRPXyBfI3jvfWSFLSzGMPpLT5U4UmJn7Ggj4eyDFWMt8C6cctezY4Z3DrU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713526123; c=relaxed/simple; bh=mFLx9Kf9QiTrGA/CCODiqs5l83WcNgsCoxVgXyE94rY=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=ew+LrXoabXTixdlQMovKkb84t0mi+Eh75l62dOQSwgVkRhYNXCXJNGLmFEktsj9mNYwTruuve4y0wyGGh/nue0FCivbgpyOmZg4ypY/68HH7MfRQxjQcJpUhW31VpZ6L2rmeFujk45VQr5DDaps0/a0eW2a3yZI0VJDeMbMnY2k= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1713526121; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type; bh=p32wbiZHa//S0VBpKO1nvPkEx/QPlu0SAdH9RuzMAKQ=; b=iiAdI+W4HttGPJEnVwjeLJEYVJmOSdVFh83dcPIjKJ58ChhkD9s+9bWnGaJAQD5ymzP/Nz fgcoy9tagpzI7kFGEgqvhGXOw3jcn4dcr16otS8JPRvXLCCuruduDQmUWP7uHrBb6lRZ5F BKs+xaXHcpd8cSCke10veaCVoMV2WY8= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-124-Y-bkfya3NdKzJFFMbwUtMQ-1; Fri, 19 Apr 2024 07:28:39 -0400 X-MC-Unique: Y-bkfya3NdKzJFFMbwUtMQ-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 67A1D383CD69 for ; Fri, 19 Apr 2024 11:28:39 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.224.5]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2A46840357A7; Fri, 19 Apr 2024 11:28:39 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 43JBSbEX4106310 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 19 Apr 2024 13:28:37 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 43JBSbFo4106309; Fri, 19 Apr 2024 13:28:37 +0200 Date: Fri, 19 Apr 2024 13:28:37 +0200 From: Jakub Jelinek To: "Joseph S. Myers" Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] c-family: Allow arguments with NULLPTR_TYPE as sentinels [PR114780] Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Jakub Jelinek Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org Hi! While in C++ the ellipsis argument conversions include "An argument that has type cv std::nullptr_t is converted to type void*" in C23 a nullptr_t argument is not promoted in any way, but va_arg description says: "the type of the next argument is nullptr_t and type is a pointer type that has the same representation and alignment requirements as a pointer to a character type." So, while in C++ check_function_sentinel will never see NULLPTR_TYPE, for C23 it can see that and currently we incorrectly warn about those. The only question is whether we should warn on any argument with nullptr_t type or just about nullptr (nullptr_t argument with integer_zerop value). Through undefined behavior guess one could pass non-NULL pointer that way, say by union { void *p; nullptr_t q; } u; u.p = &whatever; and pass u.q to ..., but valid code should always pass something that will read as (char *) 0 when read using va_arg (ap, char *), so I think it is better not to warn rather than warn in those cases. Note, clang seems to pass (void *)0 rather than expression of nullptr_t type to ellipsis in C23 mode as if it did the C++ ellipsis argument conversions, in that case guess not warning about that would be even safer, but what GCC does I think follows the spec more closely, even when in a valid program one shouldn't be able to observe the difference. Ok for trunk and later 13.3 if it passes bootstrap/regtest (so far just checked on the sentinel related C/C++ tests)? 2024-04-19 Jakub Jelinek PR c/114780 * c-common.cc (check_function_sentinel): Allow as sentinel any argument of NULLPTR_TYPE. * gcc.dg/format/sentinel-2.c: New test. Jakub --- gcc/c-family/c-common.cc.jj 2024-03-27 19:39:17.968676626 +0100 +++ gcc/c-family/c-common.cc 2024-04-19 12:58:01.577985800 +0200 @@ -5783,6 +5783,7 @@ check_function_sentinel (const_tree fnty sentinel = fold_for_warn (argarray[nargs - 1 - pos]); if ((!POINTER_TYPE_P (TREE_TYPE (sentinel)) || !integer_zerop (sentinel)) + && TREE_CODE (TREE_TYPE (sentinel)) != NULLPTR_TYPE /* Although __null (in C++) is only an integer we allow it nevertheless, as we are guaranteed that it's exactly as wide as a pointer, and we don't want to force --- gcc/testsuite/gcc.dg/format/sentinel-2.c.jj 2024-04-19 12:57:57.431043948 +0200 +++ gcc/testsuite/gcc.dg/format/sentinel-2.c 2024-04-19 12:58:39.020460785 +0200 @@ -0,0 +1,21 @@ +/* PR c/114780 */ +/* { dg-do compile } */ +/* { dg-options "-std=c23 -Wformat" } */ + +#include + +[[gnu::sentinel]] void foo (int, ...); +[[gnu::sentinel]] void bar (...); + +void +baz (nullptr_t p) +{ + foo (1, 2, nullptr); + foo (3, 4, 5, p); + bar (nullptr); + bar (p); + foo (6, 7, 0); // { dg-warning "missing sentinel in function call" } + bar (0); // { dg-warning "missing sentinel in function call" } + foo (8, 9, NULL); + bar (NULL); +}