* C++ extension "cast-as-lvalues": time to deprecate? @ 2003-05-08 23:54 Giovanni Bajo 2003-05-09 4:06 ` Fergus Henderson 2003-05-09 6:55 ` Gabriel Dos Reis 0 siblings, 2 replies; 23+ messages in thread From: Giovanni Bajo @ 2003-05-08 23:54 UTC (permalink / raw) To: gcc; +Cc: Giovanni Bajo Hello, GCC implements an extension which lets cast result be a lvalue instead of a rvalue, as would be prescribed by the standard. There are several open PRs about problems with this extension, some of which are very tricky and involves also wrong-code problems (together with inliner, for instance). Just for reference, you may want to check: http://gcc.gnu.org/PR?1833 http://gcc.gnu.org/PR?1920 http://gcc.gnu.org/PR?7503 http://gcc.gnu.org/PR?7884 Other PRs have been closed already as duplicates. I think there are no doubts that this extension causes confusion among users, because the behaviour is not expected. Plus, bugs in its implementation causes very bad side effects. If this was not enough, the extension is active even in -ansi -pedantic mode, which is counter intuive and confusing. Since GCC already deprecated and removed less evil extensions like implicit typename, I wonder if maybe it's time to deprecate this "cast-as-lvalue" and remove it as soon as possible. Giovanni Bajo ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: C++ extension "cast-as-lvalues": time to deprecate? 2003-05-08 23:54 C++ extension "cast-as-lvalues": time to deprecate? Giovanni Bajo @ 2003-05-09 4:06 ` Fergus Henderson 2003-05-09 8:34 ` Joseph S. Myers 2003-05-09 12:49 ` Giovanni Bajo 2003-05-09 6:55 ` Gabriel Dos Reis 1 sibling, 2 replies; 23+ messages in thread From: Fergus Henderson @ 2003-05-09 4:06 UTC (permalink / raw) To: Giovanni Bajo; +Cc: gcc On 09-May-2003, Giovanni Bajo <giovannibajo@libero.it> wrote: > GCC implements an extension which lets cast result be a lvalue instead of a > rvalue, as would be prescribed by the standard. There are several open PRs > about problems with this extension, some of which are very tricky and > involves also wrong-code problems (together with inliner, for instance). > Just for reference, you may want to check: > > http://gcc.gnu.org/PR?1833 > http://gcc.gnu.org/PR?1920 > http://gcc.gnu.org/PR?7503 > http://gcc.gnu.org/PR?7884 > > Other PRs have been closed already as duplicates. > > I think there are no doubts that this extension causes confusion among > users, because the behaviour is not expected. Plus, bugs in its > implementation causes very bad side effects. If this was not enough, the > extension is active even in -ansi -pedantic mode, which is counter intuive > and confusing. Since GCC already deprecated and removed less evil extensions > like implicit typename, I wonder if maybe it's time to deprecate this > "cast-as-lvalue" and remove it as soon as possible. Are you suggesting just deprecating it just in C++, or also in C? I would prefer that it not be deprecated. The reason is that this is a useful extension in C (especially in conjunction with global register variables), and I would prefer that GNU C++ support anything that GNU C supports, since GNU C constructs may get used in C header files which are included in C++ programs. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit The University of Melbourne | of excellence is a lethal habit" WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: C++ extension "cast-as-lvalues": time to deprecate? 2003-05-09 4:06 ` Fergus Henderson @ 2003-05-09 8:34 ` Joseph S. Myers 2003-05-09 12:38 ` Fergus Henderson 2003-05-09 22:12 ` Neil Booth 2003-05-09 12:49 ` Giovanni Bajo 1 sibling, 2 replies; 23+ messages in thread From: Joseph S. Myers @ 2003-05-09 8:34 UTC (permalink / raw) To: Fergus Henderson; +Cc: Giovanni Bajo, gcc On Fri, 9 May 2003, Fergus Henderson wrote: > Are you suggesting just deprecating it just in C++, or also in C? > > I would prefer that it not be deprecated. > The reason is that this is a useful extension in C I would like it deprecated in C. There is an excessive amount of complicated code in the C front end to implement this extension, it creates lvalues whose address cannot be taken, and the description in the manual indicates that everything that can be done with lvalue casts can be done just by writing out the syntax the manual gives as an expansion of lvalue casts (which you could even define as an lvalue_cast_assign macro if you want to convert lots of code using them). Removing lvalue casts would improve the compiler's maintainability. -- Joseph S. Myers jsm28@cam.ac.uk ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: C++ extension "cast-as-lvalues": time to deprecate? 2003-05-09 8:34 ` Joseph S. Myers @ 2003-05-09 12:38 ` Fergus Henderson 2003-05-09 12:41 ` Gabriel Dos Reis 2003-05-09 22:12 ` Neil Booth 1 sibling, 1 reply; 23+ messages in thread From: Fergus Henderson @ 2003-05-09 12:38 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Giovanni Bajo, gcc On 09-May-2003, Joseph S. Myers <jsm28@cam.ac.uk> wrote: > On Fri, 9 May 2003, Fergus Henderson wrote: > > > Are you suggesting just deprecating it just in C++, or also in C? > > > > I would prefer that it not be deprecated. > > The reason is that this is a useful extension in C > > I would like it deprecated in C. There is an excessive amount of > complicated code in the C front end to implement this extension, it > creates lvalues whose address cannot be taken, C already has lvalues whose address cannot be taken: registers. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit The University of Melbourne | of excellence is a lethal habit" WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: C++ extension "cast-as-lvalues": time to deprecate? 2003-05-09 12:38 ` Fergus Henderson @ 2003-05-09 12:41 ` Gabriel Dos Reis 0 siblings, 0 replies; 23+ messages in thread From: Gabriel Dos Reis @ 2003-05-09 12:41 UTC (permalink / raw) To: Fergus Henderson; +Cc: Joseph S. Myers, Giovanni Bajo, gcc Fergus Henderson <fjh@cs.mu.OZ.AU> writes: | On 09-May-2003, Joseph S. Myers <jsm28@cam.ac.uk> wrote: | > On Fri, 9 May 2003, Fergus Henderson wrote: | > | > > Are you suggesting just deprecating it just in C++, or also in C? | > > | > > I would prefer that it not be deprecated. | > > The reason is that this is a useful extension in C | > | > I would like it deprecated in C. There is an excessive amount of | > complicated code in the C front end to implement this extension, it | > creates lvalues whose address cannot be taken, | | C already has lvalues whose address cannot be taken: registers. That is not a sufficient reason to keep this extension which is causing many griefs. -- Gaby ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: C++ extension "cast-as-lvalues": time to deprecate? 2003-05-09 8:34 ` Joseph S. Myers 2003-05-09 12:38 ` Fergus Henderson @ 2003-05-09 22:12 ` Neil Booth 2003-05-09 22:39 ` Joseph S. Myers 1 sibling, 1 reply; 23+ messages in thread From: Neil Booth @ 2003-05-09 22:12 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Fergus Henderson, Giovanni Bajo, gcc Joseph S. Myers wrote:- > On Fri, 9 May 2003, Fergus Henderson wrote: > > > Are you suggesting just deprecating it just in C++, or also in C? > > > > I would prefer that it not be deprecated. > > The reason is that this is a useful extension in C > > I would like it deprecated in C. Cool, I agree. You're the C maintainer; can we look forward to a patch? Neil. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: C++ extension "cast-as-lvalues": time to deprecate? 2003-05-09 22:12 ` Neil Booth @ 2003-05-09 22:39 ` Joseph S. Myers 0 siblings, 0 replies; 23+ messages in thread From: Joseph S. Myers @ 2003-05-09 22:39 UTC (permalink / raw) To: Neil Booth; +Cc: Fergus Henderson, Giovanni Bajo, gcc On Fri, 9 May 2003, Neil Booth wrote: > > I would like it deprecated in C. > > Cool, I agree. You're the C maintainer; can we look forward to a > patch? I don't expect to be in a position to be actively maintaining again for some months. Half the deprecation should be easy - modify pedantic_non_lvalue. Getting a deprecation warning for the other half - casts of an lvalue to its own type (which -pedantic turns into a hard error, not a warning) may be more tricky. -- Joseph S. Myers jsm28@cam.ac.uk ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: C++ extension "cast-as-lvalues": time to deprecate? 2003-05-09 4:06 ` Fergus Henderson 2003-05-09 8:34 ` Joseph S. Myers @ 2003-05-09 12:49 ` Giovanni Bajo 2003-05-09 14:06 ` Fergus Henderson 1 sibling, 1 reply; 23+ messages in thread From: Giovanni Bajo @ 2003-05-09 12:49 UTC (permalink / raw) To: Fergus Henderson; +Cc: gcc Fergus Henderson <fjh@cs.mu.OZ.AU> wrote: > Are you suggesting just deprecating it just in C++, or also in C? I don't have any strong opinion. I think that it causes many more problems in C++ than in C (since many bug reports I saw are related to its interaction with refecences), but then there would be issues about shared code and such. Anyway, my main concern right now is "-ansi". Why is the extension active even in "-ansi" mode? I think this is a bug that should be fixed as soon as possible in all the active branches. Giovanni Bajo ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: C++ extension "cast-as-lvalues": time to deprecate? 2003-05-09 12:49 ` Giovanni Bajo @ 2003-05-09 14:06 ` Fergus Henderson 0 siblings, 0 replies; 23+ messages in thread From: Fergus Henderson @ 2003-05-09 14:06 UTC (permalink / raw) To: Giovanni Bajo; +Cc: gcc On 09-May-2003, Giovanni Bajo <giovannibajo@libero.it> wrote: > Fergus Henderson <fjh@cs.mu.OZ.AU> wrote: > > > Are you suggesting just deprecating it just in C++, or also in C? > > I don't have any strong opinion. According to the GCC manual, this extension is *already* deprecated in C++. "Standard C++ allows compound expressions and conditional expressions as lvalues, and permits casts to reference type, so use of this extension is deprecated for C++ code." (This is from <http://gcc.gnu.org/onlinedocs/gcc/Lvalues.html#Lvalues>.) -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit The University of Melbourne | of excellence is a lethal habit" WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: C++ extension "cast-as-lvalues": time to deprecate? 2003-05-08 23:54 C++ extension "cast-as-lvalues": time to deprecate? Giovanni Bajo 2003-05-09 4:06 ` Fergus Henderson @ 2003-05-09 6:55 ` Gabriel Dos Reis 2003-05-09 17:15 ` Joe Buck 1 sibling, 1 reply; 23+ messages in thread From: Gabriel Dos Reis @ 2003-05-09 6:55 UTC (permalink / raw) To: Giovanni Bajo; +Cc: gcc "Giovanni Bajo" <giovannibajo@libero.it> writes: | Hello, | | GCC implements an extension which lets cast result be a lvalue instead of a | rvalue, as would be prescribed by the standard. There are several open PRs | about problems with this extension, some of which are very tricky and | involves also wrong-code problems (together with inliner, for instance). | Just for reference, you may want to check: | | http://gcc.gnu.org/PR?1833 | http://gcc.gnu.org/PR?1920 | http://gcc.gnu.org/PR?7503 | http://gcc.gnu.org/PR?7884 | | Other PRs have been closed already as duplicates. | | I think there are no doubts that this extension causes confusion among | users, because the behaviour is not expected. Plus, bugs in its | implementation causes very bad side effects. If this was not enough, the | extension is active even in -ansi -pedantic mode, which is counter intuive | and confusing. Since GCC already deprecated and removed less evil extensions | like implicit typename, I wonder if maybe it's time to deprecate this | "cast-as-lvalue" and remove it as soon as possible. IIRC, this has been discussed in the past with no definitive conclusion but deprecation and removal were on good track. Some patches have been applied in the past to correct cases where it was causing us to reject valid codes. This extension is an examplar of extensions that were not given enough thought and are causing much more trouble than they do useful things. This extension in particular is not needed nor useful in C++ because they are far better alternatives. It is pointless. It should simply be removed. -- Gaby ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: C++ extension "cast-as-lvalues": time to deprecate? 2003-05-09 6:55 ` Gabriel Dos Reis @ 2003-05-09 17:15 ` Joe Buck 2003-05-09 17:45 ` Gabriel Dos Reis 2003-05-09 18:13 ` Matt Austern 0 siblings, 2 replies; 23+ messages in thread From: Joe Buck @ 2003-05-09 17:15 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: Giovanni Bajo, gcc On Fri, May 09, 2003 at 08:54:25AM +0200, Gabriel Dos Reis wrote: > This extension is an examplar of extensions that were not given enough > thought and are causing much more trouble than they do useful things. > This extension in particular is not needed nor useful in C++ because > they are far better alternatives. It is pointless. > It should simply be removed. As it has already been deprecated, I agree that it should be removed. Because of bad interactions with references, its presence can cause severe problems; in particular, it can cause the wrong overloaded function in a conforming C++ program to be chosen. Since it's likely that a non-const function will be chosen instead of a const function, severe things can happen, like code attempting to change a literal in a read-only section, giving a program crash. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: C++ extension "cast-as-lvalues": time to deprecate? 2003-05-09 17:15 ` Joe Buck @ 2003-05-09 17:45 ` Gabriel Dos Reis 2003-05-09 18:13 ` Matt Austern 1 sibling, 0 replies; 23+ messages in thread From: Gabriel Dos Reis @ 2003-05-09 17:45 UTC (permalink / raw) To: Joe Buck; +Cc: Giovanni Bajo, gcc Joe Buck <jbuck@synopsys.com> writes: | On Fri, May 09, 2003 at 08:54:25AM +0200, Gabriel Dos Reis wrote: | > This extension is an examplar of extensions that were not given enough | > thought and are causing much more trouble than they do useful things. | > This extension in particular is not needed nor useful in C++ because | > they are far better alternatives. It is pointless. | > It should simply be removed. | | As it has already been deprecated, I agree that it should be removed. | Because of bad interactions with references, its presence can cause severe | problems; in particular, it can cause the wrong overloaded function in a | conforming C++ program to be chosen. Since it's likely that a non-const | function will be chosen instead of a const function, severe things can | happen, like code attempting to change a literal in a read-only section, | giving a program crash. Yeah :-( I would like to add that that extension caused us to reject some well-formed codes, then Matt Austern submitted a patch (last year IIRC) that attempted to limit the damages, but then that patch turns out to reject other valid codes just because of the presence of that extension :-( -- Gaby ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: C++ extension "cast-as-lvalues": time to deprecate? 2003-05-09 17:15 ` Joe Buck 2003-05-09 17:45 ` Gabriel Dos Reis @ 2003-05-09 18:13 ` Matt Austern 2003-05-09 18:34 ` Nathan Sidwell 1 sibling, 1 reply; 23+ messages in thread From: Matt Austern @ 2003-05-09 18:13 UTC (permalink / raw) To: Joe Buck; +Cc: Gabriel Dos Reis, Giovanni Bajo, gcc On Friday, May 9, 2003, at 10:15 AM, Joe Buck wrote: > On Fri, May 09, 2003 at 08:54:25AM +0200, Gabriel Dos Reis wrote: >> This extension is an examplar of extensions that were not given enough >> thought and are causing much more trouble than they do useful things. >> This extension in particular is not needed nor useful in C++ because >> they are far better alternatives. It is pointless. >> It should simply be removed. > > As it has already been deprecated, I agree that it should be removed. > Because of bad interactions with references, its presence can cause > severe > problems; in particular, it can cause the wrong overloaded function in > a > conforming C++ program to be chosen. Since it's likely that a > non-const > function will be chosen instead of a const function, severe things can > happen, like code attempting to change a literal in a read-only > section, > giving a program crash. We said it was deprecated in the documentation, but we never enforced that with a warning. I think the schedule for removal will have to look something like this: - Next release: put in a warning for this extension, and allow users to turn it off with a switch. - The release after that: don't allow users to turn the warning off. - Finally, in the next release: remove it entirely. I could imagine doing this over the course of two releases instead of three, but two is the absolute minimum. I agree, for what it's worth, that this extension should go. It was poorly thought out, and we never specified how it was supposed to interact with other language features. (We've seen two different problems with it in the Apple code base.) Doing language extension correctly takes a lot of work. --Matt ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: C++ extension "cast-as-lvalues": time to deprecate? 2003-05-09 18:13 ` Matt Austern @ 2003-05-09 18:34 ` Nathan Sidwell 2003-05-09 18:48 ` Giovanni Bajo 2003-05-09 21:01 ` Joe Buck 0 siblings, 2 replies; 23+ messages in thread From: Nathan Sidwell @ 2003-05-09 18:34 UTC (permalink / raw) To: Matt Austern; +Cc: Joe Buck, Gabriel Dos Reis, Giovanni Bajo, gcc Matt Austern wrote: > We said it was deprecated in the documentation, but we never enforced > that with a warning. I think the schedule for removal will have to > look something like this: > - Next release: put in a warning for this extension, and allow users > to turn it off with a switch. > - The release after that: don't allow users to turn the warning off. > - Finally, in the next release: remove it entirely. > > I could imagine doing this over the course of two releases instead > of three, but two is the absolute minimum. Normal practice for g++ at least appears to be two, add a warning in release N, remove it in N+1 nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC The voices in my head said this was stupid too nathan@codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: C++ extension "cast-as-lvalues": time to deprecate? 2003-05-09 18:34 ` Nathan Sidwell @ 2003-05-09 18:48 ` Giovanni Bajo 2003-05-09 21:01 ` Joe Buck 1 sibling, 0 replies; 23+ messages in thread From: Giovanni Bajo @ 2003-05-09 18:48 UTC (permalink / raw) To: Nathan Sidwell, Matt Austern; +Cc: Joe Buck, Gabriel Dos Reis, gcc Nathan Sidwell <nathan@codesourcery.com> wrote: > Normal practice for g++ at least appears to be two, add a warning in > release N, remove it in N+1 Is it feasable for N to be 3.3[.1] and N+1 be 3.4, or we will have to wait 3.4 & 3.5? Given that it's a deprecated extension, I guess I can file a bugreport specifying that the compiler does not warn when using it. Giovanni Bajo ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: C++ extension "cast-as-lvalues": time to deprecate? 2003-05-09 18:34 ` Nathan Sidwell 2003-05-09 18:48 ` Giovanni Bajo @ 2003-05-09 21:01 ` Joe Buck 2003-05-09 23:21 ` Mark Mitchell 1 sibling, 1 reply; 23+ messages in thread From: Joe Buck @ 2003-05-09 21:01 UTC (permalink / raw) To: Nathan Sidwell; +Cc: Matt Austern, Gabriel Dos Reis, Giovanni Bajo, gcc On Fri, May 09, 2003 at 07:34:19PM +0100, Nathan Sidwell wrote: > Matt Austern wrote: > > > We said it was deprecated in the documentation, but we never enforced > > that with a warning. I think the schedule for removal will have to > > look something like this: > > - Next release: put in a warning for this extension, and allow users > > to turn it off with a switch. > > - The release after that: don't allow users to turn the warning off. > > - Finally, in the next release: remove it entirely. > > > > I could imagine doing this over the course of two releases instead > > of three, but two is the absolute minimum. > Normal practice for g++ at least appears to be two, add a warning in > release N, remove it in N+1 There's a somewhat different issue here, though: what about strictly conforming programs that malfunction because of the extension, in a way that is surprising to the user? Do we have to keep miscompiling them for two more releases? ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: C++ extension "cast-as-lvalues": time to deprecate? 2003-05-09 21:01 ` Joe Buck @ 2003-05-09 23:21 ` Mark Mitchell 2003-05-12 16:30 ` Joe Buck 2003-05-16 1:15 ` Giovanni Bajo 0 siblings, 2 replies; 23+ messages in thread From: Mark Mitchell @ 2003-05-09 23:21 UTC (permalink / raw) To: Joe Buck Cc: Nathan Sidwell, Matt Austern, Gabriel Dos Reis, Giovanni Bajo, gcc On Fri, 2003-05-09 at 14:00, Joe Buck wrote: > On Fri, May 09, 2003 at 07:34:19PM +0100, Nathan Sidwell wrote: > > Matt Austern wrote: > > > > > We said it was deprecated in the documentation, but we never enforced > > > that with a warning. I think the schedule for removal will have to > > > look something like this: > > > - Next release: put in a warning for this extension, and allow users > > > to turn it off with a switch. > > > - The release after that: don't allow users to turn the warning off. > > > - Finally, in the next release: remove it entirely. > > > > > > I could imagine doing this over the course of two releases instead > > > of three, but two is the absolute minimum. > > Normal practice for g++ at least appears to be two, add a warning in > > release N, remove it in N+1 > > There's a somewhat different issue here, though: what about strictly > conforming programs that malfunction because of the extension, in a way > that is surprising to the user? Do we have to keep miscompiling them > for two more releases? I think not. I think we can add a warning in 3.3.1, and remove the feature in 3.4. -- Mark Mitchell CodeSourcery, LLC mark@codesourcery.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: C++ extension "cast-as-lvalues": time to deprecate? 2003-05-09 23:21 ` Mark Mitchell @ 2003-05-12 16:30 ` Joe Buck 2003-05-12 16:42 ` Mark Mitchell 2003-05-16 1:15 ` Giovanni Bajo 1 sibling, 1 reply; 23+ messages in thread From: Joe Buck @ 2003-05-12 16:30 UTC (permalink / raw) To: Mark Mitchell Cc: Nathan Sidwell, Matt Austern, Gabriel Dos Reis, Giovanni Bajo, gcc On Fri, 2003-05-09 at 14:00, Joe Buck wrote: > > There's a somewhat different issue here, though: what about strictly > > conforming programs that malfunction because of the extension, in a way > > that is surprising to the user? Do we have to keep miscompiling them > > for two more releases? On Fri, May 09, 2003 at 04:21:12PM -0700, Mark Mitchell wrote: > I think not. I think we can add a warning in 3.3.1, and remove the > feature in 3.4. But what, exactly, are we warning about? Consider the following program: -------------------------------------- #include <iostream> void foo(int&) { std::cout << "foo(int&) called\n"; } void foo(const int&) { std::cout << "foo(const int&) called\n"; } int main(int, char**) { unsigned u = 0; foo((int)u); } -------------------------------------- Here, because GCC is making the cast an lvalue, the program incorrectly calls foo(int&) instead of foo(const int&). But there's nothing wrong with the program, there is only something wrong with gcc. We could warn that GCC has used the cast-as-lvalue extension, but how, then, does the user fix the warning if the user really needs to make the distinction between a const and a non-const reference? I thought a bit about the idea of trying to make the extension work only in programs that would otherwise have an error, but it's tricky. Uses of casts would have to be resolved twice, once according to the standard and then, if there's no match, again according to the extension. > -- > Mark Mitchell > CodeSourcery, LLC > mark@codesourcery.com -- Q. What's more of a headache than a bug in a compiler. A. Bugs in six compilers. -- Mark Johnson ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: C++ extension "cast-as-lvalues": time to deprecate? 2003-05-12 16:30 ` Joe Buck @ 2003-05-12 16:42 ` Mark Mitchell 2003-05-12 17:11 ` Joe Buck 2003-05-12 17:58 ` Fergus Henderson 0 siblings, 2 replies; 23+ messages in thread From: Mark Mitchell @ 2003-05-12 16:42 UTC (permalink / raw) To: Joe Buck Cc: Nathan Sidwell, Matt Austern, Gabriel Dos Reis, Giovanni Bajo, gcc > But what, exactly, are we warning about? Consider the following program: > > -------------------------------------- > #include <iostream> > > void foo(int&) { > std::cout << "foo(int&) called\n"; > } > > void foo(const int&) { > std::cout << "foo(const int&) called\n"; > } > > int main(int, char**) { > unsigned u = 0; > foo((int)u); > } Oh, ugh, I didn't know we mishandled that. That's just a bug; the only places we should be trying to support the cast-as-lvalue extension at this point are those places where GCC does: the left-hand side of an assignment statement. It was there that I wanted to introduce the warning. (Your example is a bug in G++ because we try to maintain the invariant that GNU extensions do not change the meaning of valid programs. There are numerous places where that ideal is not achieved, but it is the ideal.) -- Mark ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: C++ extension "cast-as-lvalues": time to deprecate? 2003-05-12 16:42 ` Mark Mitchell @ 2003-05-12 17:11 ` Joe Buck 2003-05-12 17:58 ` Fergus Henderson 1 sibling, 0 replies; 23+ messages in thread From: Joe Buck @ 2003-05-12 17:11 UTC (permalink / raw) To: Mark Mitchell Cc: Nathan Sidwell, Matt Austern, Gabriel Dos Reis, Giovanni Bajo, gcc > > But what, exactly, are we warning about? Consider the following program: > > [ example deleted, now is PR 10754] On Mon, May 12, 2003 at 09:41:50AM -0700, Mark Mitchell wrote: > Oh, ugh, I didn't know we mishandled that. That's just a bug; the only > places we should be trying to support the cast-as-lvalue extension at this > point are those places where GCC does: the left-hand side of an assignment > statement. It was there that I wanted to introduce the warning. > > (Your example is a bug in G++ because we try to maintain the invariant that > GNU extensions do not change the meaning of valid programs. There are > numerous places where that ideal is not achieved, but it is the ideal.) It's now PR 10754. Interestingly, although this is broken as far back as 2.95.2, 2.7.2.1 does the right thing so I guess we can call it a regression if we really want to. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: C++ extension "cast-as-lvalues": time to deprecate? 2003-05-12 16:42 ` Mark Mitchell 2003-05-12 17:11 ` Joe Buck @ 2003-05-12 17:58 ` Fergus Henderson 1 sibling, 0 replies; 23+ messages in thread From: Fergus Henderson @ 2003-05-12 17:58 UTC (permalink / raw) To: Mark Mitchell Cc: Joe Buck, Nathan Sidwell, Matt Austern, Gabriel Dos Reis, Giovanni Bajo, gcc On 12-May-2003, Mark Mitchell <mark@codesourcery.com> wrote: > > But what, exactly, are we warning about? Consider the following program: > > > > -------------------------------------- > > #include <iostream> > > > > void foo(int&) { > > std::cout << "foo(int&) called\n"; > > } > > > > void foo(const int&) { > > std::cout << "foo(const int&) called\n"; > > } > > > > int main(int, char**) { > > unsigned u = 0; > > foo((int)u); > > } > > Oh, ugh, I didn't know we mishandled that. That's just a bug; Definitely. It sort of half works in cases like the one above, when the cast is to a different type with the same size, but fails completely when casting from types with different sizes. E.g. if you change `unsigned' to `long long', and add an assignment to `r' in the non-const version of foo(), you'll see that the assignment only overwrites part of `u'. #include <iostream> void foo(int& r) { std::cout << "foo(int&) called\n"; r = 0x1234; } void foo(const int& r) { std::cout << "foo(const int&) called\n"; } int main(int, char**) { long long u = 0xaaaabbbbccccddddLL; foo((int)u); std::cout << "u = 0x" << std::hex << std::u << endl; } This program outputs "u = 0xaaaabbbb00001234". In contrast, if the assignment is done directly, int main(int, char**) { long long u = 0xaaaabbbbccccddddLL; (int)u = 0x1234; std::cout << "u = 0x" << std::hex << std::u << endl; } it outputs "u = 0x1234". -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit The University of Melbourne | of excellence is a lethal habit" WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: C++ extension "cast-as-lvalues": time to deprecate? 2003-05-09 23:21 ` Mark Mitchell 2003-05-12 16:30 ` Joe Buck @ 2003-05-16 1:15 ` Giovanni Bajo 2003-05-16 1:23 ` Joe Buck 1 sibling, 1 reply; 23+ messages in thread From: Giovanni Bajo @ 2003-05-16 1:15 UTC (permalink / raw) To: Mark Mitchell, Joe Buck Cc: Nathan Sidwell, Matt Austern, Gabriel Dos Reis, gcc Mark Mitchell <mark@codesourcery.com> wrote: > I think not. I think we can add a warning in 3.3.1, and remove the > feature in 3.4. Ok. Is there someone that I can officially bug with this until it gets done? Should I open a PR which states this and assign it to somebody? Giovanni Bajo ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: C++ extension "cast-as-lvalues": time to deprecate? 2003-05-16 1:15 ` Giovanni Bajo @ 2003-05-16 1:23 ` Joe Buck 0 siblings, 0 replies; 23+ messages in thread From: Joe Buck @ 2003-05-16 1:23 UTC (permalink / raw) To: Giovanni Bajo Cc: Mark Mitchell, Nathan Sidwell, Matt Austern, Gabriel Dos Reis, gcc On Fri, May 16, 2003 at 03:15:10AM +0200, Giovanni Bajo wrote: > Mark Mitchell <mark@codesourcery.com> wrote: > > > I think not. I think we can add a warning in 3.3.1, and remove the > > feature in 3.4. > > Ok. Is there someone that I can officially bug with this until it gets done? > Should I open a PR which states this and assign it to somebody? It's already filed (see PR 10754). ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2003-05-16 1:23 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-05-08 23:54 C++ extension "cast-as-lvalues": time to deprecate? Giovanni Bajo 2003-05-09 4:06 ` Fergus Henderson 2003-05-09 8:34 ` Joseph S. Myers 2003-05-09 12:38 ` Fergus Henderson 2003-05-09 12:41 ` Gabriel Dos Reis 2003-05-09 22:12 ` Neil Booth 2003-05-09 22:39 ` Joseph S. Myers 2003-05-09 12:49 ` Giovanni Bajo 2003-05-09 14:06 ` Fergus Henderson 2003-05-09 6:55 ` Gabriel Dos Reis 2003-05-09 17:15 ` Joe Buck 2003-05-09 17:45 ` Gabriel Dos Reis 2003-05-09 18:13 ` Matt Austern 2003-05-09 18:34 ` Nathan Sidwell 2003-05-09 18:48 ` Giovanni Bajo 2003-05-09 21:01 ` Joe Buck 2003-05-09 23:21 ` Mark Mitchell 2003-05-12 16:30 ` Joe Buck 2003-05-12 16:42 ` Mark Mitchell 2003-05-12 17:11 ` Joe Buck 2003-05-12 17:58 ` Fergus Henderson 2003-05-16 1:15 ` Giovanni Bajo 2003-05-16 1:23 ` Joe Buck
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).