From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16992 invoked by alias); 19 Oct 2002 00:23:05 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 16930 invoked from network); 19 Oct 2002 00:23:05 -0000 Received: from unknown (HELO purple.csi.cam.ac.uk) (131.111.8.4) by sources.redhat.com with SMTP; 19 Oct 2002 00:23:05 -0000 Received: from student.cusu.cam.ac.uk ([131.111.179.82] helo=kern.srcf.societies.cam.ac.uk ident=mail) by purple.csi.cam.ac.uk with esmtp (Exim 4.10) id 182hOS-00015X-00; Sat, 19 Oct 2002 01:23:04 +0100 Received: from jsm28 (helo=localhost) by kern.srcf.societies.cam.ac.uk with local-esmtp (Exim 3.35 #1 (Debian)) id 182hOS-00082M-00; Sat, 19 Oct 2002 01:23:04 +0100 Date: Fri, 18 Oct 2002 21:55:00 -0000 From: "Joseph S. Myers" X-X-Sender: To: Joe Buck cc: Subject: Re: restrict keyword [was: expalin this syntax pls] In-Reply-To: <200210190012.g9J0CDh07290@piper.synopsys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-10/txt/msg01168.txt.bz2 On Fri, 18 Oct 2002, Joe Buck wrote: > This means that we can't issue a hard error for it, but a warning may well > still be appropriate. Errors are for code that is wrong, warnings are for > code that is likely to be wrong. If you insist on not issuing warnings for > such code, we have the problem that we can't use similar mechanisms to > warn about possible misuse of memcpy, whose specification implies > "restrict" even for C++, which doesn't have the keyword. You can't issue a hard error for it anyway, since the code might never be executed. The key questions for issuing a warning (under its own option, possibly included in -Wall) are: * Does anyone write real (broken) code the warning would detect? (The relevant question for having the warning at all.) * Does anyone write real (working) code the warning would wrongly trigger on? * How common are these? * Can working code wrongly triggering the warning be easily changed, even if automatically generated, so as not to trigger it? (The relevant question for -Wall inclusion.) In the case of memcpy, we have more information to tell whether a call *is* a problem (rather than might be). -- Joseph S. Myers jsm28@cam.ac.uk