[Bug c++/67981] New: new expression with zero size not diagnosed

[Bug c++/67981] New: new expression with zero size not diagnosed

[msebor at gcc dot gnu.org]

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

            Bug ID: 67981
           Summary: new expression with zero size not diagnosed
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Continuing with new expression conformance issues (bug 67913 and bug 67917):

In 5.3.4, p6, C++ 11 says that "Every constant-expression in a
noptr-new-declarator shall be an integral constant expression (5.19) and
evaluate to a strictly positive value."  C++ 14 has an equivalent requirement.

The following test case shows that gcc doesn't implement this constraint and
accepts a constant expression with a zero value:

$ echo "void* f () { return new char [0]; }" | g++ -Wall -Werror -Wextra
-Wpedantic -c -std=c++11 -xc++ -

[Bug c++/67981] new expression with zero size not diagnosed

[msebor at gcc dot gnu.org]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2015-10-16
           Assignee|unassigned at gcc dot gnu.org      |msebor at gcc dot gnu.org
     Ever confirmed|0                           |1

[Bug c++/67981] new expression with zero size not diagnosed

[Casey at Carter dot net]

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

Casey Carter <Casey at Carter dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Casey at Carter dot net

--- Comment #1 from Casey Carter <Casey at Carter dot net> ---
I think this is a bug in the standard, and not a bug in GCC.
noptr-new-declarator has two grammar productions:

noptr-new-declarator:
  [ expression ] attribute-specifier-seq_opt
  noptr-new-declarator [ constant-expression ] attribute-specifier-seq_opt

with the intent being that all but the first dimension in a multi-dimensional
array new expression must be constant expressions, while the first dimension
can be a non-constant expression. It would be peculiar if "new int[0]" were to
be ill-formed whereas "int n = 0; new int[n];" were to be well-formed, which it
very clearly is by 5.3.4/7: "... When the value of the expression is zero, the
allocation function is called to allocate an array with no elements."

The confusion arises here because the wording uses "constant-expression" to
describe occurrences of the second grammar production of noptr-new-declarator,
and "expression" to describe occurrences of the first production, which is
ambiguous when the expression also happens to be a constant-expression.

[Bug c++/67981] new expression with zero size not diagnosed

[msebor at gcc dot gnu.org]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |INVALID

--- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> ---
(In reply to Casey Carter from comment #1)
> I think this is a bug in the standard, and not a bug in GCC.

Thanks.  I've been thinking about this and I suspect you're right that it's my
misreading of the standard and not a bug in GCC.  A slightly more involved test
case shows that GCC does diagnose zero-size arrays in new expressions when the
zero is the constant-expression and that it only accepts such arrays when the
first expression is zero (as does Clang).

$ echo "void* f () { return new char [1][0]; }" | ~/bin/gcc-5.1.0/bin/g++ -Wall
-Wextra -Wpedantic -c -std=c++11 -xc++ -
<stdin>: In function ‘void* f()’:
<stdin>:1:35: warning: ISO C++ forbids zero-size array [-Wpedantic]

Let me resolve this as invalid.
>From gcc-bugs-return-499799-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 16 23:58:08 2015
Return-Path: <gcc-bugs-return-499799-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 109631 invoked by alias); 16 Oct 2015 23:58:08 -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 109571 invoked by uid 48); 16 Oct 2015 23:58:04 -0000
From: "vz-gcc at zeitlins dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/20345] Warning on forward declaration of class with __dllexport__
Date: Fri, 16 Oct 2015 23:58: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: 3.4.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vz-gcc at zeitlins dot org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: dannysmith at users dot sourceforge.net
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-20345-4-AIWp70ss2i@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-20345-4@http.gcc.gnu.org/bugzilla/>
References: <bug-20345-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-10/txt/msg01354.txt.bz2
Content-length: 1955

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

Vadim Zeitlin <vz-gcc at zeitlins dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vz-gcc at zeitlins dot org

--- Comment #3 from Vadim Zeitlin <vz-gcc at zeitlins dot org> ---
Surprisingly, after all these years I've realized just now that this bug has
never been actually fixed. The patch that was applied fixes the warnings in the
following code:

    struct __attribute__((visibility("default"))) S;
    struct __attribute__((visibility("default"))) S { };

but it did nothing for this case:

    struct __attribute__((visibility("default"))) S { };
    struct __attribute__((visibility("default"))) S;

All versions of g++ I have (4.[6789] and 5.2) still give a warning in this
case, e.g. with 5.2.1 and the code above in the file visibility.cpp:

    % g++ -Wall -fvisibility=hidden -c visibility.cpp
    visibility.cpp:2:47: warning: type attributes ignored after type is already
defined [-Wattributes]
     struct __attribute__((visibility("default"))) S;
                                               ^

And, of course, while nobody is going to write code like above manually
intentionally, it's pretty common to encounter it in more complicated cases
when various headers forward declare various classes and can be included in
more or less any order. So in practice using visibility attributes in forward
declarations still remains impossible (without getting flooded with warnings,
that is), although it would be very nice for projects adding visibility support
(yes, in 2015, better late than never...) to the existing code which happily
compiles without any warnings using MSVC.

IMO gcc should verify that the class is either not fully declared with a
different visibility instead of just checking that it's not fully declared at
all.