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.
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
"new T[0]" looks like defined behavior to me. [expr.new] 5.3.4 -7- When the value of the expression in a direct-new-declarator is zero, the allocation function is called to allocate an array with no elements. The pointer returend by the new-expression is non-null. [Note: if the library allocation function is called, the pointer returned is distinct from the the pointer to any other object.] === cp/init.c even quotes that section in a comment before giving the warning. cp/init.c goes on to say "However, that is not generally useful, so we issue a warning". new T[0] is valid C++ and here is a useful case.
Subject: Re: C++ frontend should not warn about new a[0] in template context "mec at google dot com" <gcc-bugzilla@gcc.gnu.org> writes: | "new T[0]" looks like defined behavior to me. | | [expr.new] 5.3.4 -7- | When the value of the expression in a direct-new-declarator is zero, the | allocation function is called to allocate an array with no elements. The | pointer returend by the new-expression is non-null. [Note: if the library | allocation function is called, the pointer returned is distinct from the the | pointer to any other object.] | | === | | cp/init.c even quotes that section in a comment before giving the warning. | cp/init.c goes on to say "However, that is not generally useful, so we issue a | warning". new T[0] is valid C++ and here is a useful case. Thanks for reminding me that the construct is NOT undefined beahviour. That, I think, also supports the case that we should NOT disable the warning for template instantiations. -- Gaby
The problem I see is that this unconditional warning warns about code which is completely safe and correct. That break -Werror builds. There is no natural way to avoid the warning in a template. Given that, if we want to have this warning enabled even when the argument derives from a template parameter, then I think that we should disable the warning by default. And given that, maybe we should just remove the warning.
Subject: Re: C++ frontend should not warn about new a[0] in template context "ian at airs dot com" <gcc-bugzilla@gcc.gnu.org> writes: | The problem I see is that this unconditional warning warns about code which is | completely safe and correct. That break -Werror builds. I believe we agree with that. | There is no natural way to avoid the warning in a template. The user has no natural way to avoid that -- I agree. However, the cure of not warning at all is too drastic. | Given that, if we want to have this | warning enabled even when the argument derives from a template parameter, then | I think that we should disable the warning by default. And given that, maybe | we should just remove the warning. I'm OK with that idea if that is OK with you. -- Gaby
Hi. So, what shall we do here? I can remove the warning completely or conditionalize it to -Wextra, for example. Just let me know...
Subject: Re: C++ frontend should not warn about new a[0] in template context "pcarlini at suse dot de" <gcc-bugzilla@gcc.gnu.org> writes: | Hi. So, what shall we do here? I can remove the warning completely or | conditionalize it to -Wextra, for example. Just let me know... I'm inclined to remove the warning. -- Gaby
Subject: Bug 33124 Author: paolo Date: Sun Sep 16 22:54:12 2007 New Revision: 128531 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128531 Log: /cp 2007-09-16 Paolo Carlini <pcarlini@suse.de> PR c++/33124 * init.c (build_new): Remove warning for zero-element allocations. /testsuite 2007-09-16 Paolo Carlini <pcarlini@suse.de> PR c++/33124 * g++.dg/warn/new1.C: Adjust. * g++.dg/torture/str_empty.C: Likewise. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/torture/str_empty.C trunk/gcc/testsuite/g++.dg/warn/new1.C
Fixed.
*** Bug 33914 has been marked as a duplicate of this bug. ***