[Bug c++/33124] C++ frontend should not warn about new a[0] in template context

gdr at cs dot tamu dot edu gcc-bugzilla@gcc.gnu.org
Mon Aug 20 18:57:00 GMT 2007



------- Comment #1 from gdr at cs dot tamu dot edu  2007-08-20 18:57 -------
Subject: Re:   New: C++ frontend should not warn about new a[0] in template
context

"ian at airs dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| For this simplified code:
| 
| template<int c>
| char* f1() { if (c == 0) return 0; else return new char[c]; }
| char* f2() { return f1<0>(); }
| 
| the C++ frontend issues an unconditional warning.  When compiling with no
| options, I get
| 
| foo.cc: In function ‘char* f1() [with int c = 0]’:
| foo.cc:3:   instantiated from here
| foo.cc:2: warning: allocating zero-element array
| 
| I have no objection to this warning in ordinary usage, but when the argument
to
| new[] depends on a template parameter, I think this warning does more harm
than
| good.  Even with properly parameterized code we get a useless and unavoidable
| warning.
| 
| I recommend both 1) don't warn when the argument depends on a template
| parameter; and 2) add an option to control this warning.

I think that, in general, for template instantiations it makes perfect
sense to warn -- because after all, the user may want to know off-hand
that the instantiation is invoking an undefined behaviour.

However, in this specific case, simple control can determine that the
branch is never executed, therefore the warning is unwarranted.

The fix to this PR should not stop warning for template instantiation;
it should take into account simple data-flow control-flow into
account.

The problem is not just with templates; it is directly related to our
coding convention of saying

   if (HAVE_FEATURE)
     {
        // ...
     }
   else
     {
        // ...
     }

where HAVE_FEATURE is a macro expanding to a constant.  We don't want
to unconditionally warn for both branches.

-- Gaby


-- 


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



More information about the Gcc-bugs mailing list