From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25208 invoked by alias); 26 Feb 2015 00:46:44 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 25195 invoked by uid 89); 26 Feb 2015 00:46:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_FROM_URIBL_PCCC,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-pd0-f172.google.com Received: from mail-pd0-f172.google.com (HELO mail-pd0-f172.google.com) (209.85.192.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 26 Feb 2015 00:46:42 +0000 Received: by pdjg10 with SMTP id g10so8832398pdj.1 for ; Wed, 25 Feb 2015 16:46:39 -0800 (PST) X-Received: by 10.68.129.97 with SMTP id nv1mr9836504pbb.87.1424911599792; Wed, 25 Feb 2015 16:46:39 -0800 (PST) Received: from [192.168.1.35] (76-253-1-90.lightspeed.sntcca.sbcglobal.net. [76.253.1.90]) by mx.google.com with ESMTPSA id uy8sm42465412pbc.31.2015.02.25.16.46.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Feb 2015 16:46:38 -0800 (PST) References: <0AB56024-875B-4724-8ED2-A9DDB237CBFF@dell.com> <23CC7871-C616-436C-920C-4A635DC87189@dell.com> <7A311B56-C424-4C4F-A0E4-B12B65131745@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <225BDA7A-3A1F-4F94-8086-E44249E273D5@gmail.com> Cc: Simon Marchi , "Paul_Koning@dell.com" , "gdb@sourceware.org" From: pinskia@gmail.com Subject: Re: format string is not a string literal Date: Thu, 26 Feb 2015 02:35:00 -0000 To: Jack Howarth X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg00059.txt.bz2 > On Feb 25, 2015, at 4:41 PM, Jack Howarth wrote: >=20 > Andrew, > See the additional comments from the llvm.org clang developers at... >=20 > http://llvm.org/bugs/show_bug.cgi?id=3D22701#c5 Then put this warning under a different flag. Anyways clang is broken and g= db should not change due to a broken compiler.=20 Thanks, Andrew >=20 > Jack >=20 >> On Wed, Feb 25, 2015 at 7:12 PM, wrote: >>=20 >>=20 >>=20 >>=20 >> On Feb 25, 2015, at 4:05 PM, Simon Marchi wrot= e: >>=20 >>>> I didn=E2=80=99t say it=E2=80=99s a bug, Andrew did. But I agree with= him. >>>>=20 >>>> My comment (=E2=80=9Cthe code is legit=E2=80=9D) simply meant that GDB= uses variable formats for obvious valid reasons (so the format can vary, b= eing user-supplied). Given that it=E2=80=99s intentional, the warning is n= ot wanted. >>>>=20 >>>> But that point is really applicable to printf, not vprintf. Andrew=E2= =80=99s point is that checking formats for vprintf is not possible because = you can=E2=80=99t know the argument list; only in printf do you see the arg= uments so you can match the types. So the bug is that format checking and = complaining for non-literal formats should not be enabled at all for vprint= f. That may be a header issue rather than a compiler issue, but either way= , it=E2=80=99s not the right thing to do. >>>>=20 >>>> paul >>>=20 >>> I think the warning is relevant. If you instruct the compiler that >>> inferior_debug takes a format string and format arguments (using a >>> format attribute, as mentioned by Richard in the bug report), then it >>> can check if the callers are doing something wrong. >>>=20 >>> In the case of inferior_debug, the attribute should be >>> __attribute__((format (printf, 2, 3))) >>>=20 >>> By adding the attribute, you get nice warnings of this kind: >>>=20 >>> test.c: In function =E2=80=98main=E2=80=99: >>> test.c:17:2: warning: too many arguments for format [-Wformat-extra-arg= s] >>> inferior_debug (1, "pouet %d", 2, "hello"); >>>=20 >>> If the function is vprintf-style, it's similar but the last argument >>> should be 0. It will push the argument check a level higher, where >>> eventually they are explicitely defined printf-style. The doc is >>> somewhere here [2] in the middle. >>=20 >> Then clang's warning should suggest putting the format attribute on that= function rather than giving out a warning that seems like it is a bogus on= e. >>=20 >> Gcc does that iirc why not clang. >>=20 >> Thanks, >> Andrew >>=20 >>=20 >>>=20 >>> The warning also has some value because it will tell you if the string >>> originally comes from a non-literal, which should be avoided [1]. >>>=20 >>> [1] http://en.wikipedia.org/wiki/Uncontrolled_format_string >>> [2] https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html >>>=20 >>> Simon