From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id CA5AF3858C54; Fri, 27 Jan 2023 10:05:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CA5AF3858C54 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1674813924; bh=QssGHTmJPqklaHIAsk4v0QZ0Rcb13MIf/mLfWYrDVYo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=bswEePXG7563fi/Oz6GAKxTpJG2DpjGulu+5dUvBvSJxnNJaTMwV6sPVnNBAKbv/+ oaveEfcORORsPVLySxNnC7qAuE7xEM1gq/ob4gSbjlCdenLfss07Nc8TwKSdpzjW/U iQUSEH//iazLLNPw1DvAL8eeVngO51NqLzbd60yw= From: "gprocida at google dot com" To: libabigail@sourceware.org Subject: [Bug default/30048] incorrect qualifiers within compound types Date: Fri, 27 Jan 2023 10:05:23 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: libabigail X-Bugzilla-Component: default X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: gprocida at google dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: dodji at redhat dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30048 --- Comment #3 from gprocida at google dot com --- Function prototypes that only differ in restrict are compatible according to the standard. This means that foo.c containing a declaration of f with restrict and foo.h containing one without restrict is legal. The type exposed to users may or may not contain restrict ("not", in the ca= se above). Tooling such as abidw could warn about this. However, the C language itself makes it clear that qualifiers on function parameter types only have an effect on the implementation, not the interfac= e. I'm in the camp that we should just discard them all. I don't think patches= for Linux that try to drop or add const in various places where this discrepancy already exists would be well received by kernel maintainers. Dropping them means dropping restrict almost everywhere. I suppose restrict could appear in standalone function types... but that is even less useful. For the STG tool, I'm in fact proposing dropping qualifiers on function parameter types and return types and dropping restrict unconditionally. --=20 You are receiving this mail because: You are on the CC list for the bug.=