C++ extension "cast-as-lvalues": time to deprecate?

C++ extension "cast-as-lvalues": time to deprecate?

[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

Re: C++ extension "cast-as-lvalues": time to deprecate?

[Fergus Henderson]

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.

Re: C++ extension "cast-as-lvalues": time to deprecate?

[Gabriel Dos Reis]

"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

Re: C++ extension "cast-as-lvalues": time to deprecate?

[Joseph S. Myers]

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

Re: C++ extension "cast-as-lvalues": time to deprecate?

[Fergus Henderson]

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.

Re: C++ extension "cast-as-lvalues": time to deprecate?

[Gabriel Dos Reis]

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

Re: C++ extension "cast-as-lvalues": time to deprecate?

[Giovanni Bajo]

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

Re: C++ extension "cast-as-lvalues": time to deprecate?

[Fergus Henderson]

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.

Re: C++ extension "cast-as-lvalues": time to deprecate?

[Joe Buck]

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.

Re: C++ extension "cast-as-lvalues": time to deprecate?

[Gabriel Dos Reis]

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

Re: C++ extension "cast-as-lvalues": time to deprecate?

[Matt Austern]

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

Re: C++ extension "cast-as-lvalues": time to deprecate?

[Nathan Sidwell]

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

Re: C++ extension "cast-as-lvalues": time to deprecate?

[Giovanni Bajo]

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

Re: C++ extension "cast-as-lvalues": time to deprecate?

[Joe Buck]

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?

Re: C++ extension "cast-as-lvalues": time to deprecate?

[Neil Booth]

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.

Re: C++ extension "cast-as-lvalues": time to deprecate?

[Joseph S. Myers]

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

Re: C++ extension "cast-as-lvalues": time to deprecate?

[Mark Mitchell]

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

Re: C++ extension "cast-as-lvalues": time to deprecate?

[Joe Buck]

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

Re: C++ extension "cast-as-lvalues": time to deprecate?

[Mark Mitchell]

> 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

Re: C++ extension "cast-as-lvalues": time to deprecate?

[Joe Buck]

> > 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.

Re: C++ extension "cast-as-lvalues": time to deprecate?

[Fergus Henderson]

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.

Re: C++ extension "cast-as-lvalues": time to deprecate?

[Giovanni Bajo]

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

Re: C++ extension "cast-as-lvalues": time to deprecate?

[Joe Buck]

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).