From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17963 invoked by alias); 6 Oct 2004 00:47:21 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 17948 invoked by alias); 6 Oct 2004 00:47:21 -0000 Date: Wed, 06 Oct 2004 00:47:00 -0000 Message-ID: <20041006004721.17946.qmail@sourceware.org> From: "gdr at cs dot tamu dot edu" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20041005225551.17854.rth@gcc.gnu.org> References: <20041005225551.17854.rth@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug c++/17854] Accept statement expressions at top level X-Bugzilla-Reason: CC X-SW-Source: 2004-10/txt/msg00633.txt.bz2 List-Id: ------- Additional Comments From gdr at cs dot tamu dot edu 2004-10-06 00:47 ------- Subject: Re: New: Accept statement expressions at top level "rth at gcc dot gnu dot org" writes: | The primary motivation for allowing this is to handle macros provided by | system headers. For instance, the htonl macro from in glibc | uses statement expressions, but from the user's point of view it looks like | a function call. Admittedly gcc 3.4 gives a much better error message than | did previous versions, but it can still be confusing. | | It does seem like it'd be perfectly straightforward to implement -- just | drop the expression into the global constructor function and be done, but | as the attached test case shows, it's not quite that simple due to | the parsing of "register" outside the syntactic scope of a function. Given that this is C++ and you're referring to the file-scope constructor, why can't glibc just use objects (of class-type) at global scope? I believe that provides a cleaner approach. Oh yes, glibc would have to test for __cplusplus. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17854