[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cfe-commits
Subject:    Re: [cfe-commits] r140777 - in /cfe/trunk:
From:       Ahmed Charles <ahmedcharles () gmail ! com>
Date:       2011-09-30 18:07:33
Message-ID: -6361007367548789612 () unknownmsgid
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Without knowing the context perfectly, is it possible to annotate the
function in a way that expresses which set of format strings it accepts? Of
there are two sets of behaviors from format strings, then having a way to
identify each makes sense.
------------------------------
From: Ted Kremenek
Sent: 9/30/2011 12:45 AM
To: Joerg Sonnenberger
Cc: llvm cfe
Subject: Re: [cfe-commits] r140777 - in /cfe/trunk:
lib/Sema/SemaChecking.cpp test/Sema/format-strings.c

On Sep 30, 2011, at 12:38 AM, Ted Kremenek wrote:

On Sep 29, 2011, at 11:51 PM, Joerg Sonnenberger wrote:

On Thu, Sep 29, 2011 at 04:01:39PM -0700, Ted Kremenek wrote:

This isn't just about printf and scanf, but any function with the format
attribute.  There are functions with that attribute where this isn't a no-op
even when the format string is empty.  I saw such a case, which was the
motivation for this change.


That said, the warning definitely is useful for printf and friends when
there are no data arguments.  I'd like the warning to be the strictest when
it can be.


Why not support -W(no-)format-zero-length like GCC then?


Clang does support that, and I don't think it is so simple.

Passing -Wno-format-zero-length means the warning never fires at all, even
in legit cases (like the ones you pointed out).

Using pragmas to silence the warning within smaller blocks of code is also
not user friendly, as it requires using it on every callsite that the
warning triggers.


Along the pragmas line, the only solution that I know of that would work
without silencing the warning outright would be to wrap the original
function in a macro that surrounded the function call with _Pragmas that
silenced the warning.  That's obviously not a great experience.

[Attachment #5 (text/html)]

<html><head><meta content="text/html; charset=utf-8" \
http-equiv="Content-Type"></head><body><div><div style="font-family: \
Calibri,sans-serif; font-size: 11pt;">Without knowing the context perfectly, is it \
possible to annotate the function in a way that expresses which set of format strings \
it accepts? Of there are two sets of behaviors from format strings, then having a way \
to identify each makes sense.<br> </div></div><hr><span style="font-family: \
Tahoma,sans-serif; font-size: 10pt; font-weight: bold;">From: </span><span \
style="font-family: Tahoma,sans-serif; font-size: 10pt;">Ted Kremenek</span><br><span \
style="font-family: Tahoma,sans-serif; font-size: 10pt; font-weight: bold;">Sent: \
</span><span style="font-family: Tahoma,sans-serif; font-size: 10pt;">9/30/2011 12:45 \
AM</span><br> <span style="font-family: Tahoma,sans-serif; font-size: 10pt; \
font-weight: bold;">To: </span><span style="font-family: Tahoma,sans-serif; \
font-size: 10pt;">Joerg Sonnenberger</span><br><span style="font-family: \
Tahoma,sans-serif; font-size: 10pt; font-weight: bold;">Cc: </span><span \
style="font-family: Tahoma,sans-serif; font-size: 10pt;">llvm cfe</span><br> <span \
style="font-family: Tahoma,sans-serif; font-size: 10pt; font-weight: bold;">Subject: \
</span><span style="font-family: Tahoma,sans-serif; font-size: 10pt;">Re: \
[cfe-commits] r140777 - in /cfe/trunk: lib/Sema/SemaChecking.cpp \
test/Sema/format-strings.c</span><br> <br></body></html><html><head></head><body \
style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: \
after-white-space; "><div><div>On Sep 30, 2011, at 12:38 AM, Ted Kremenek \
wrote:</div><br class="Apple-interchange-newline"> <blockquote type="cite"><div \
style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: \
after-white-space; "><div><div>On Sep 29, 2011, at 11:51 PM, Joerg Sonnenberger \
wrote:</div><br class="Apple-interchange-newline"> <blockquote type="cite"><span \
class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; \
font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: \
normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; \
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; \
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; \
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; \
-webkit-text-stroke-width: 0px; font-size: medium; ">On Thu, Sep 29, 2011 at \
04:01:39PM -0700, Ted Kremenek wrote:<br> <blockquote type="cite">This isn&#39;t just \
about printf and scanf, but any function with the format attribute.   There are \
functions with that attribute where this isn&#39;t a no-op even when the format \
string is empty.   I saw such a case, which was the motivation for this change.<br> \
</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">That \
said, the warning definitely is useful for printf and friends when there are no data \
arguments.   I&#39;d like the warning to be the strictest when it can be.<br> \
</blockquote><br>Why not support -W(no-)format-zero-length like GCC \
then?<br></span></blockquote></div><br><div>Clang does support that, and I don&#39;t \
think it is so simple.</div><div><br></div><div>Passing -Wno-format-zero-length means \
the warning never fires at all, even in legit cases (like the ones you pointed \
out).</div> <div><br></div><div>Using pragmas to silence the warning within smaller \
blocks of code is also not user friendly, as it requires using it on every callsite \
that the warning triggers.</div></div></blockquote></div><br><div> Along the pragmas \
line, the only solution that I know of that would work without silencing the warning \
outright would be to wrap the original function in a macro that surrounded the \
function call with _Pragmas that silenced the warning.   That&#39;s obviously not a \
great experience.</div> </body></html>



_______________________________________________
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic