[Bug tree-optimization/98281] New: - -Wformat-truncation false positive due to excessive integer range

ishikawa at yk dot rim.or.jp gcc-bugzilla@gcc.gnu.org
Mon Dec 14 19:05:57 GMT 2020


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

            Bug ID: 98281
           Summary: - -Wformat-truncation false positive due to excessive
                    integer range
           Product: gcc
           Version: 10.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ishikawa at yk dot rim.or.jp
  Target Milestone: ---

Created attachment 49763
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49763&action=edit
Code that triggered the error.

Actually there was bug 94021 but that was for 9.2.1, and this is with 10.2.0,
and the error is subtly different. So I am submitting this bug entry.

Compared with the example in bug 94021 comment 4, the bug is slightly
different.

gcc --version
gcc (Debian 10.2.0-19) 10.2.0

The source code is from mozilla's thunderbird.

The error I observed is:

In file included from Unified_c_libical_src_libical1.c:20:
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/calendar/libical/src/libical/icalvalue.c:
In function ‘icalvalue_utcoffset_as_ical_string_r’:
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/calendar/libical/src/libical/icalvalue.c:897:20:
error: ‘%02d’ directive output may be truncated writing between 2 and 6 bytes
into a region of size between 2 and 4 [-Werror=format-truncation=]
  897 |     snprintf(str,9,"%c%02d%02d%02d",sign,abs(h),abs(m),abs(s));
      |                    ^~~~~~~~~~~~~~~~
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/calendar/libical/src/libical/icalvalue.c:897:20:
note: directive argument in the range [1, 338339]
In file included from /usr/include/stdio.h:867,
                 from
/NEW-SSD/moz-obj-dir/objdir-tb3/dist/system_wrappers/stdio.h:3,
                 from
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/calendar/libical/src/libical/icaltimezone.c:34,
                 from Unified_c_libical_src_libical1.c:2:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:67:10: note:
‘__builtin___snprintf_chk’ output between 8 and 14 bytes into a destination of
size 9
   67 |   return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   68 |        __bos (__s), __fmt, __va_arg_pack ());
      |        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                           


This does not make sense, since the value(s) ought to be constrained
to fit into the final string.

Also, I am not sure what this [1, 338339] is valid for  WHICH variable.

The code snippet from the affected function: Sorry, I could no reproduce the
problem with a simplified source code. There must be an optimization issue
involved.

--- begin quote 
static char* icalvalue_utcoffset_as_ical_string_r(const icalvalue* value)
{
    int data,h,m,s;
    char sign;
    char* str;

    if(!((value!=0))) { icalerror_set_errno(ICAL_BADARG_ERROR); return 0;};

    str = (char*)icalmemory_new_buffer(9);
    data = icalvalue_get_utcoffset(value);

    if (abs(data) == data){
 sign = '+';
    } else {
 sign = '-';
    }



    if (data >= 3600 * 24 || data <= - 3600 * 24) {
        snprintf(str,9,"+0000");
        return str;
    }

    if(data < 0)
        data = - data;







    h = data/3600;
    m = (data - (h*3600))/ 60;
    s = (data - (h*3600) - (m*60));

    if (s > 0)
    snprintf(str,9,"%c%02d%02d%02d",sign,abs(h),abs(m),abs(s));
    else
    snprintf(str,9,"%c%02d%02d",sign,abs(h),abs(m));

    return str;
}

--- end quote

The intention is that the following conditions hold before snprintf is invoked.

h is in [0, 24)
m is in [0, 60)
s is in [0, 60)

I wonder where "[1, 338339]" comes from.

Yes, I know the original code does something funny like abs(data) == data,

The preprocessed source file is in the attachment.
The command script to compile the source file is in another comment.


More information about the Gcc-bugs mailing list