From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cerberus.halldom.com (cerberus.halldom.com [79.135.97.241]) by server2.sourceware.org (Postfix) with ESMTPS id 41FF43948814 for ; Mon, 9 Mar 2020 12:14:26 +0000 (GMT) Received: from ceres.halldom.com ([79.135.97.244]:56175) by cerberus.halldom.com with esmtpsa (TLSv1.3:TLS_AES_128_GCM_SHA256:128) (Exim 4.92.3) (envelope-from ) id 1jBHIe-0003oU-Od for gcc-help@gcc.gnu.org; Mon, 09 Mar 2020 12:14:24 +0000 Subject: Fwd: Re: Should atomic_xxx() functions reject not-_Atomic() arguments ? References: To: gcc-help From: Chris Hall X-Forwarded-Message-Id: Message-ID: <36d51438-e172-a209-c9aa-0011421ebbab@gmch.uk> Date: Mon, 9 Mar 2020 12:14:10 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00, SPF_HELO_NONE, SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 12:14:27 -0000 On 08/03/2020 20:11, Martin Sebor wrote: > On 3/7/20 6:04 AM, Chris Hall wrote: ... >> I wonder if, by extension, the atomic_xxx() should (at least) warn >> when the _Atomic() parameters are passed not-_Atomic() arguments ? > I think it would be useful to expose a command-line option in GCC > to request a diagnostic for uses of the APIs with non-atomic types. > Making it an error would probably not be a great solution because > of the risk of breaking working code that has come to rely on it. I guess existing code could continue to be compiled without the "revised API" option (and continue to work as well as it did before). For new/updated code I think an error makes the point with suitable force. The programmer can always cast to _Atomic(), if they are confident that all their intended targets will work. The "revised API" could also fix the fetch-add for pointers. But... >> As I have said elsewhere, I think the real problem is that the >> Standard fails to define vital things as Implementation Defined, >> leaving the programmer guessing as to what their code is going to do >> when compiled for some machine/system they are not familiar with. ...in particular: if I feel brave and cast (say) uint64_t to _Atomic(uint64_t), I don't have any obvious way to trigger a warning/error when compiling for a machine/system for which the cast is a grave mistake (for whatever reason). Chris