public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/17854] New: Accept statement expressions at top level
@ 2004-10-05 22:55 rth at gcc dot gnu dot org
2004-10-05 22:56 ` [Bug c++/17854] " rth at gcc dot gnu dot org
` (6 more replies)
0 siblings, 7 replies; 9+ messages in thread
From: rth at gcc dot gnu dot org @ 2004-10-05 22:55 UTC (permalink / raw)
To: gcc-bugs
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.
--
Summary: Accept statement expressions at top level
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rth at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17854
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/17854] Accept statement expressions at top level
2004-10-05 22:55 [Bug c++/17854] New: Accept statement expressions at top level rth at gcc dot gnu dot org
@ 2004-10-05 22:56 ` rth at gcc dot gnu dot org
2004-10-05 22:58 ` pinskia at gcc dot gnu dot org
` (5 subsequent siblings)
6 siblings, 0 replies; 9+ messages in thread
From: rth at gcc dot gnu dot org @ 2004-10-05 22:56 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From rth at gcc dot gnu dot org 2004-10-05 22:56 -------
Created an attachment (id=7289)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7289&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17854
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/17854] Accept statement expressions at top level
2004-10-05 22:55 [Bug c++/17854] New: Accept statement expressions at top level rth at gcc dot gnu dot org
2004-10-05 22:56 ` [Bug c++/17854] " rth at gcc dot gnu dot org
@ 2004-10-05 22:58 ` pinskia at gcc dot gnu dot org
2004-10-05 23:05 ` pinskia at gcc dot gnu dot org
` (4 subsequent siblings)
6 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-10-05 22:58 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-05 22:58 -------
Confirmed, I wonder why this was true, it does not makes sense since we build the trees anyways for
the toplevel.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed| |1
Keywords| |rejects-valid
Last reconfirmed|0000-00-00 00:00:00 |2004-10-05 22:58:38
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17854
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/17854] Accept statement expressions at top level
2004-10-05 22:55 [Bug c++/17854] New: Accept statement expressions at top level rth at gcc dot gnu dot org
2004-10-05 22:56 ` [Bug c++/17854] " rth at gcc dot gnu dot org
2004-10-05 22:58 ` pinskia at gcc dot gnu dot org
@ 2004-10-05 23:05 ` pinskia at gcc dot gnu dot org
2004-10-06 0:09 ` rth at gcc dot gnu dot org
` (3 subsequent siblings)
6 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-10-05 23:05 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-05 23:05 -------
I see that the C front-end rejects with a message about the problem too, maybe it was a carry over
from there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17854
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/17854] Accept statement expressions at top level
2004-10-05 22:55 [Bug c++/17854] New: Accept statement expressions at top level rth at gcc dot gnu dot org
` (2 preceding siblings ...)
2004-10-05 23:05 ` pinskia at gcc dot gnu dot org
@ 2004-10-06 0:09 ` rth at gcc dot gnu dot org
2004-10-06 0:47 ` gdr at cs dot tamu dot edu
` (2 subsequent siblings)
6 siblings, 0 replies; 9+ messages in thread
From: rth at gcc dot gnu dot org @ 2004-10-06 0:09 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From rth at gcc dot gnu dot org 2004-10-06 00:09 -------
Well, obviously, but C unlike C++ doesn't support non-constant global
initializers either.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17854
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/17854] Accept statement expressions at top level
2004-10-05 22:55 [Bug c++/17854] New: Accept statement expressions at top level rth at gcc dot gnu dot org
` (3 preceding siblings ...)
2004-10-06 0:09 ` rth at gcc dot gnu dot org
@ 2004-10-06 0:47 ` gdr at cs dot tamu dot edu
2004-10-06 0:56 ` rth at gcc dot gnu dot org
2004-10-06 1:03 ` gdr at cs dot tamu dot edu
6 siblings, 0 replies; 9+ messages in thread
From: gdr at cs dot tamu dot edu @ 2004-10-06 0:47 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/17854] Accept statement expressions at top level
2004-10-05 22:55 [Bug c++/17854] New: Accept statement expressions at top level rth at gcc dot gnu dot org
` (4 preceding siblings ...)
2004-10-06 0:47 ` gdr at cs dot tamu dot edu
@ 2004-10-06 0:56 ` rth at gcc dot gnu dot org
2004-10-06 1:03 ` Gabriel Dos Reis
2004-10-06 1:03 ` gdr at cs dot tamu dot edu
6 siblings, 1 reply; 9+ messages in thread
From: rth at gcc dot gnu dot org @ 2004-10-06 0:56 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From rth at gcc dot gnu dot org 2004-10-06 00:56 -------
I'm sure there's plenty of ways to approach this just for glibc.
But that's rather beside the point.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17854
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/17854] Accept statement expressions at top level
2004-10-05 22:55 [Bug c++/17854] New: Accept statement expressions at top level rth at gcc dot gnu dot org
` (5 preceding siblings ...)
2004-10-06 0:56 ` rth at gcc dot gnu dot org
@ 2004-10-06 1:03 ` gdr at cs dot tamu dot edu
6 siblings, 0 replies; 9+ messages in thread
From: gdr at cs dot tamu dot edu @ 2004-10-06 1:03 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From gdr at cs dot tamu dot edu 2004-10-06 01:03 -------
Subject: Re: Accept statement expressions at top level
"rth at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:
| I'm sure there's plenty of ways to approach this just for glibc.
| But that's rather beside the point.
I mean, the technique works whether it is glibc for user upsilon.
That is why I do not see the merit/need of this new extension.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17854
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bug c++/17854] Accept statement expressions at top level
2004-10-06 0:56 ` rth at gcc dot gnu dot org
@ 2004-10-06 1:03 ` Gabriel Dos Reis
0 siblings, 0 replies; 9+ messages in thread
From: Gabriel Dos Reis @ 2004-10-06 1:03 UTC (permalink / raw)
To: gcc-bugzilla; +Cc: gcc-bugs
"rth at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:
| I'm sure there's plenty of ways to approach this just for glibc.
| But that's rather beside the point.
I mean, the technique works whether it is glibc for user upsilon.
That is why I do not see the merit/need of this new extension.
-- Gaby
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2004-10-06 1:03 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-10-05 22:55 [Bug c++/17854] New: Accept statement expressions at top level rth at gcc dot gnu dot org
2004-10-05 22:56 ` [Bug c++/17854] " rth at gcc dot gnu dot org
2004-10-05 22:58 ` pinskia at gcc dot gnu dot org
2004-10-05 23:05 ` pinskia at gcc dot gnu dot org
2004-10-06 0:09 ` rth at gcc dot gnu dot org
2004-10-06 0:47 ` gdr at cs dot tamu dot edu
2004-10-06 0:56 ` rth at gcc dot gnu dot org
2004-10-06 1:03 ` Gabriel Dos Reis
2004-10-06 1:03 ` gdr at cs dot tamu dot edu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).