[Bug c/39438] Can't compile a wrapper around strftime with -Werror=format-nonliteral

[Bug c/39438] Can't compile a wrapper around strftime with -Werror=format-nonliteral

[tss at iki dot fi]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39438

Timo Sirainen <tss at iki dot fi> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tss at iki dot fi

--- Comment #3 from Timo Sirainen <tss at iki dot fi> 2012-01-10 20:38:44 UTC ---
I ran into this as well. I tried two ways, neither of which works with strftime
(both work with printf):

static void __attribute__((format (strftime, 1, 0)))
test1(const char *fmt, const struct tm *tm)
{
    char buf[100];

    strftime(buf, sizeof(buf), fmt, tm);
}

static const char *__attribute__((format_arg (1)))
helper(const char *fmt)
{
    return fmt;
}

static void
test2(const char *fmt, const struct tm *tm)
{
    char buf[100];

    strftime(buf, sizeof(buf), helper(fmt), tm);
}

[Bug c/39438] Can't compile a wrapper around strftime with -Werror=format-nonliteral

[hugh at mimosa dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39438

D. Hugh Redelmeier <hugh at mimosa dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hugh at mimosa dot com

--- Comment #4 from D. Hugh Redelmeier <hugh at mimosa dot com> ---
I have this problem too.  I'm writing a wrapper for strftime.  I get a warning
on the actual strftime call.  

warning: format not a string literal, format string not checked
[-Wformat-nonliteral]
  strftime(buf, buflen, fmt, t);

Surely GCC should not that for "fmt" argument has been checked to be a valid
strftime format at the points where prettynow gets called.  So there is no need
to whine that it is unchecked.


static void prettynow(char *buf, size_t buflen, const char *fmt) __attribute__
((format (__strftime__, 3, 0)));

static void prettynow(char *buf, size_t buflen, const char *fmt)
{
     time_t n = time(0);
    struct tm tm1;
    struct tm *t = localtime_r(&n, &tm1);

    strftime(buf, buflen, fmt, t);
}

I'm using gcc-4.8.2-7.fc20.x86_64 on Fedora 20.

I managed to suppress the warning with a very ugly cast:

        ((size_t (*)(char *, size_t, const char *, const struct tm
*))strftime)(buf, buflen, fmt, t);

[Bug c/39438] Can't compile a wrapper around strftime with -Werror=format-nonliteral

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39438

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #5 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Could you produce a complete testcase that (In reply to D. Hugh Redelmeier from
comment #4)
> I have this problem too.  I'm writing a wrapper for strftime.  I get a
> warning on the actual strftime call.  
> 
> warning: format not a string literal, format string not checked
> [-Wformat-nonliteral]
>   strftime(buf, buflen, fmt, t);
> 
> Surely GCC should not that for "fmt" argument has been checked to be a valid
> strftime format at the points where prettynow gets called.  So there is no
> need to whine that it is unchecked.
> 

You should be able to produce a minimal self-contained testcase (the one you
posted doesn't compile). See http://gcc.gnu.org/bugs/minimize.html
The best would be to include only the definitions of the types that you need
and declare as 'extern' library functions that you use to avoid including
headers.

If you can produce another similar example that works with printf, that would
also help.

The second step would be to find out why it works with printf and not with
strftime, but that would require debugging GCC while compiling your (new)
testcases, so saving the first step will make it more likely that someone will
do the second.
>From gcc-bugs-return-451316-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon May 12 12:29:46 2014
Return-Path: <gcc-bugs-return-451316-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 5468 invoked by alias); 12 May 2014 12:29:46 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 5419 invoked by uid 48); 12 May 2014 12:29:43 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug other/61146] wide-int error when building GCC with clang
Date: Mon, 12 May 2014 12:29:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: other
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-61146-4-zUoEyirwTX@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61146-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61146-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-05/txt/msg01008.txt.bz2
Content-length: 800

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61146

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #0)
> The *FLAGS_FOR_TARGET are required or else they will be set to *FLAGS, which
> will pass -fheinous-gnu-extensions to the SH xgcc when building libgcc etc.
> (PR 25672)

It is funny that Clang has a flag called "heinous-gnu-extensions". I wonder
what other things are enabled by that (what they think are heinous GNU
extensions and why).
>From gcc-bugs-return-451317-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon May 12 12:36:56 2014
Return-Path: <gcc-bugs-return-451317-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8892 invoked by alias); 12 May 2014 12:36:56 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 8856 invoked by uid 48); 12 May 2014 12:36:52 -0000
From: "bugdal at aerifal dot cx" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/61144] Invalid optimizations for extern vars with local weak definitions
Date: Mon, 12 May 2014 12:36:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bugdal at aerifal dot cx
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61144-4-0GUOdNCgqO@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61144-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61144-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-05/txt/msg01009.txt.bz2
Content-length: 367

http://gcc.gnu.org/bugzilla/show_bug.cgi?ida144

--- Comment #8 from Rich Felker <bugdal at aerifal dot cx> ---
Further investigation suggests that the real gcc 4.8.2 is not affected; I was
mislead by the fact that Debian is shipping as "gcc-4.8_4.8.2-21" an svn
snapshot that's actually post-4.8.2. So 4.9.0 seems to be the only official
release that's affected.

[Bug c/39438] Can't compile a wrapper around strftime with -Werror=format-nonliteral

[hugh at mimosa dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39438

--- Comment #6 from D. Hugh Redelmeier <hugh at mimosa dot com> ---
Responding to Comment 5 by Manuel López-Ibáñez:

Thanks for looking at this.

> Could you produce a complete testcase
===
/* compile with -c -Wformat -Werror=format-nonliteral */
#include <time.h>

extern void prettynow(char *buf, size_t buflen, const char *fmt, struct tm *t)
__attribute__ ((format (__strftime__, 3, 0)));

void prettynow(char *buf, size_t buflen, const char *fmt, struct tm *t)
{
        strftime(buf, buflen, fmt, t);
}
===

> The best would be to include only the definitions of the types that you need > and declare as 'extern' library functions that you use to avoid including headers.

I didn't do this part.  My excuses: the type declarations are not portable but
the example should be; the solution might be in fixing headers; this way is
shorter too.

> If you can produce another similar example that works with printf, that would also help.

I don't think that printf is similar enough.  A strftime format doesn't
interact with varargs in a complex and problematic way.  A string, on its own,
is or is not a valid strftime format; a string is only a valid printf format
when considered with the argument list.

If an arg is marked as a const char * (i.e. unchanging) and has the strftime
format attribute, it should be accepted as if it were a literal strftime
argument.  After all, the necessary checking would have been done at this
routine's points of call.
>From gcc-bugs-return-451346-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon May 12 15:16:33 2014
Return-Path: <gcc-bugs-return-451346-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 6668 invoked by alias); 12 May 2014 15:16:32 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 6624 invoked by uid 48); 12 May 2014 15:16:28 -0000
From: "bugdal at aerifal dot cx" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/61144] Invalid optimizations for extern vars with local weak definitions
Date: Mon, 12 May 2014 15:16:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bugdal at aerifal dot cx
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61144-4-PTSTSPdJbs@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61144-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61144-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-05/txt/msg01038.txt.bz2
Content-length: 242

http://gcc.gnu.org/bugzilla/show_bug.cgi?ida144

--- Comment #11 from Rich Felker <bugdal at aerifal dot cx> ---
Adding __attribute__((__used__)) to the static object suppresses the symptom in
case that helps to isolate what's causing it.

[Bug c/39438] Can't compile a wrapper around strftime with -Werror=format-nonliteral

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39438

--- Comment #7 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to D. Hugh Redelmeier from comment #6)
> > The best would be to include only the definitions of the types that you need > and declare as 'extern' library functions that you use to avoid including headers.
> 
> I didn't do this part.  My excuses: the type declarations are not portable
> but the example should be; the solution might be in fixing headers; this way
> is shorter too.

If you compile with --save-temps (as the instruction say), you will see what
GCC parses. All that code makes debugging more complex. So if someone had to
debug this, he would have to cut down that code to a few lines. This is one
reason why examples should be minimal.
>From gcc-bugs-return-451349-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon May 12 15:44:19 2014
Return-Path: <gcc-bugs-return-451349-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 1464 invoked by alias); 12 May 2014 15:44:19 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 1434 invoked by uid 48); 12 May 2014 15:44:15 -0000
From: "matthijs at stdin dot nl" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/60300] [avr] Suboptimal stack pointer manipulation for frame setup
Date: Mon, 12 May 2014 15:44:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: matthijs at stdin dot nl
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60300-4-iR6d6RoMrA@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60300-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60300-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-05/txt/msg01041.txt.bz2
Content-length: 727

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`300

--- Comment #5 from Matthijs Kooijman <matthijs at stdin dot nl> ---
Ah, then the comments are a bit misleading, yes. Wouldn't it make sense to put
this decision outside of avr_sp_immediate_operand, in the same area where the
decision between the two options is made? Might lead to a bit of duplication,
though, it seems the function is callled twice.

In any case, from a user perspective, it surprises me that this exception is
made, even when compiling with -Os. Wouldn't it make sense to ignore the range
check with -Os? Or is -Os really only used to determine the list of
optimizations to (not) run and not supposed to influence the behaviour of the
compiler otherwise?

[Bug c/39438] Can't compile a wrapper around strftime with -Werror=format-nonliteral

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39438

--- Comment #8 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to D. Hugh Redelmeier from comment #6)
> > If you can produce another similar example that works with printf, that would also help.
> 
> I don't think that printf is similar enough.  A strftime format doesn't
> interact with varargs in a complex and problematic way.  A string, on its
> own, is or is not a valid strftime format; a string is only a valid printf
> format when considered with the argument list.
> 
> If an arg is marked as a const char * (i.e. unchanging) and has the strftime
> format attribute, it should be accepted as if it were a literal strftime
> argument.  After all, the necessary checking would have been done at this
> routine's points of call.

Assuming that the wrapper is marked with the correct attribute, GCC would need
to know that this const char* comes from the correct wrapper's argument. I am
not sure this is trivial to know at the point of warning without additional
work/info in the front-end. Some comments above have suggested that this
work/info is done for printf, so the first thing someone looking at this should
do is to understand how printf detects this case, and why the same is not done
for strftime, and then try to share as much code between the two cases as
possible. Perhaps it is a bug, perhaps it was never implemented for strftime.
In any case, one would need to debug GCC using two similar and minimal
testcases to understand what is going on.

See http://gcc.gnu.org/wiki/DebuggingGCC if you want to see how this works. As
an exercise, try to find the point of warning while debugging using your
testcase.

Bugs/features are more likely to be fixed if:

1. There is a minimal testcase that reproduces the problem
2. Someone has debugged GCC and identified the problem
3. Someone has done all the legal prerequisites and posted a patch that fixes
the problem
4. Someone has tested and submitted the patch for review
5. Someone has taken care of the review comments and committed the patch

We are not even in 1 and the real work is 2 and 3.
>From gcc-bugs-return-451351-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon May 12 15:58:28 2014
Return-Path: <gcc-bugs-return-451351-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 14705 invoked by alias); 12 May 2014 15:58:27 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 14664 invoked by uid 55); 12 May 2014 15:58:24 -0000
From: "denisc at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/60991] [avr] Stack corruption when using 24-bit integers __int24 or __memx pointers in large stack frame
Date: Mon, 12 May 2014 15:58:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: critical
X-Bugzilla-Who: denisc at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60991-4-KcSgQqySyT@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60991-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60991-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-05/txt/msg01043.txt.bz2
Content-length: 842

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`991

--- Comment #5 from denisc at gcc dot gnu.org ---
Author: denisc
Date: Mon May 12 15:57:52 2014
New Revision: 210327

URL: http://gcc.gnu.org/viewcvs?rev!0327&root=gcc&view=rev
Log:
    Backport from mainline
    2014-05-12  Senthil Kumar Selvaraj  <senthil_kumar.selvaraj@atmel.com>

    PR target/60991
    * config/avr/avr.c (avr_out_store_psi): Use correct constant
    to restore Y.

    Backport from mainline
    2014-05-12  Senthil Kumar Selvaraj  <senthil_kumar.selvaraj@atmel.com>

    PR target/60991
    * gcc.target/avr/pr60991.c: New testcase.



Added:
    branches/gcc-4_9-branch/gcc/testsuite/gcc.target/avr/pr60991.c
Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/config/avr/avr.c
    branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug c/39438] Can't compile a wrapper around strftime with -Werror=format-nonliteral

[hugh at mimosa dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39438

--- Comment #9 from D. Hugh Redelmeier <hugh at mimosa dot com> ---
Created attachment 32784
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32784&action=edit
minimal C source code that demonstrates the problem

minimal C source code that demonstrates the problem.
Notice that the (system-provided) declaration annotates the format argument
dirrectly with __format.  I haven't found documentation for that.

[Bug c/39438] Can't compile a wrapper around strftime with -Werror=format-nonliteral

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39438

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-02-27
     Ever confirmed|0                           |1

--- Comment #10 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to D. Hugh Redelmeier from comment #6)
> If an arg is marked as a const char * (i.e. unchanging) and has the strftime
> format attribute, it should be accepted as if it were a literal strftime
> argument.  After all, the necessary checking would have been done at this
> routine's points of call.

The code that warns is this: gcc/c-family/c-format.c

    if (res.number_non_literal > 0)
      {
        /* Functions taking a va_list normally pass a non-literal format
           string.  These functions typically are declared with
           first_arg_num == 0, so avoid warning in those cases.  */
        if (!(format_types[info->format_type].flags & (int)
FMT_FLAG_ARG_CONVERT))
          {
            /* For strftime-like formats, warn for not checking the format
               string; but there are no arguments to check.  */
            warning_at (loc, OPT_Wformat_nonliteral,
                        "format not a string literal, format string not
checked");
          }

Thus, there is nothing checking the attributes of the caller. In the same file
there is this code:

                tree c;
                for (c = TYPE_ATTRIBUTES (TREE_TYPE (current_function_decl));
                     c;
                     c = TREE_CHAIN (c))
                  if (is_attribute_p ("format", TREE_PURPOSE (c))
                      && (decode_format_type (IDENTIFIER_POINTER
                                              (TREE_VALUE (TREE_VALUE (c))))
                          == info.format_type))
                    break;
                if (c == NULL_TREE)
                  {
                    /* Check if the current function has a parameter to which
                       the format attribute could be attached; if not, it
                       can't be a candidate for a format attribute, despite
                       the vprintf-like or vscanf-like call.  */
                    tree args;
                    for (args = DECL_ARGUMENTS (current_function_decl);
                         args != 0;
                         args = DECL_CHAIN (args))
                      {
                        if (TREE_CODE (TREE_TYPE (args)) == POINTER_TYPE
                            && (TYPE_MAIN_VARIANT (TREE_TYPE (TREE_TYPE
(args)))
                                == char_type_node))
                          break;
                      }
                    if (args != 0)
                      warning (OPT_Wsuggest_attribute_format, "function might "
                               "be possible candidate for %qs format
attribute",
                               format_types[info.format_type].name);
                  }

I'm confident that the above code can be adjusted and moved to the point of the
warning in order to check that the caller of strftime has an attribute format
of type 'strftime' that refers to the same declaration as the nonliteral format
argument in the call to strftime, then avoid warning. I'm not planning to work
on this though.
>From gcc-bugs-return-478761-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Feb 27 15:43:01 2015
Return-Path: <gcc-bugs-return-478761-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 127994 invoked by alias); 27 Feb 2015 15:43:01 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 127044 invoked by uid 48); 27 Feb 2015 15:42:57 -0000
From: "aldyh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/65235] [4.8/4.9/5 Regression] Simplifying vec_select of vec_concat miscompiles when first element of vec_concat is const_int
Date: Fri, 27 Feb 2015 16:44:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: aldyh at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ktkachov at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.5
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65235-4-Ejkc6oxKFm@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65235-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65235-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-02/txt/msg03093.txt.bz2
Content-length: 230

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide235

--- Comment #4 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
--target ??

Could you post a preprocessed source code?

Hmmm... fine line, but maybe this isn't a regression?

[Bug c/39438] Can't compile a wrapper around strftime with -Werror=format-nonliteral

[peter0x44 at disroot dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39438

Peter Damianov <peter0x44 at disroot dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |peter0x44 at disroot dot org

--- Comment #13 from Peter Damianov <peter0x44 at disroot dot org> ---
This still applies to GCC 14.1.

[Bug c/39438] Can't compile a wrapper around strftime with -Werror=format-nonliteral

[4tmuelle at informatik dot uni-hamburg dot de]

------- Comment #2 from 4tmuelle at informatik dot uni-hamburg dot de  2009-03-12 09:58 -------
Hey Richard. Thanks for the timely feedback.

As far as I know, it works more or less good for printf-wrappers. So I expected
this to be working for strftime as well.

I don't think that your proposed solutions are clean and desirable ones, do
you?

Is there anything wrong in expecting the posted code snipped to compile fine?
Especially if the "fmt" argument is indeed a checked, constant, fixed size
(literal) string.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39438

[Bug c/39438] Can't compile a wrapper around strftime with -Werror=format-nonliteral

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2009-03-12 09:40 -------
It won't work.  You can either put the wrapper in a system header (add
#pragma GCC system_header) or build this TU with -fno-builtin-strftime.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39438