This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/17854] Accept statement expressions at top level
- From: "gdr at cs dot tamu dot edu" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 6 Oct 2004 00:47:21 -0000
- Subject: [Bug c++/17854] Accept statement expressions at top level
- References: <20041005225551.17854.rth@gcc.gnu.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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" <gcc-bugzilla@gcc.gnu.org> writes:
| The primary motivation for allowing this is to handle macros provided by
| system headers. For instance, the htonl macro from <netinet/in.h> 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