From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22503 invoked by alias); 20 Apr 2010 07:07:07 -0000 Received: (qmail 22426 invoked by uid 48); 20 Apr 2010 07:06:52 -0000 Date: Tue, 20 Apr 2010 07:07:00 -0000 Subject: [Bug libstdc++/43813] New: vector(3, NULL) fails to compile X-Bugzilla-Reason: CC Message-ID: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "jyasskin at gmail dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-04/txt/msg01960.txt.bz2 ------- #include std::vector v(7, 0); ------- lands on the template vector(InputIterator first, InputIterator last, const Allocator& = Allocator()); constructor instead of explicit vector(size_type n, const T& value = T(), const Allocator& = Allocator()); which the user intended. The InputIterator constructor tries to forward to _M_fill_initialize because both arguments are integral, but the "0" has now been permanently bound to the int type, stopping it from converting to a null double*. http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1234 indicates that the current behavior is conformant, but that the committee seems to want to require the call to do what the user intended in a future standard. Passing "NULL" instead of "0" makes the error depend on the build target. For example, NULL appears to be an int on x86-32 but a long on x86-64, meaning the error appears on x86-32 but not on x86-64. -- Summary: vector(3, NULL) fails to compile Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jyasskin at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43813