Bug 7614 - Warning when function returning reference to volatile called in void context
Summary: Warning when function returning reference to volatile called in void context
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 3.2
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
Depends on:
Blocks:
 
Reported: 2002-08-16 10:16 UTC by Tim Bagot
Modified: 2010-04-12 15:00 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2003-11-27 07:19:59


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Bagot 2002-08-16 10:16:01 UTC
Was rather surprised to be deluged with warnings of the form "object of type `volatile X&' will not be accessed in statement" for practically every use of a volatile assignment operator. After much head-scratching, I found that it seems to be generated whenever a function returning a reference to volatile is called in a void context. It doesn't seem to be possible to disable this warning.

From the long comment above convert_to_void() in gcc/cp/cvt.c, it appears that this behaviour is intentional. However, if the intention is indeed to reduce confusion, then IMHO it actually has the reverse effect. It also seems inconsistent to generate the warning for a reference but not a pointer.

Release:
3.2

Environment:
Debian GNU/Linux x86 unstable

How-To-Repeat:
Here's a simple snippet that demonstrates the problem:-

volatile int& wibble(volatile int& x)
{
    x = 0;
    return x;
}

volatile int v;

void foo()
{
    wibble(v);
}
Comment 1 Nathan Sidwell 2002-09-13 15:54:31 UTC
State-Changed-From-To: open->closed
State-Changed-Why: not a bug. references to volatile objects are evil. For instance, your wibble function contains
    'return x', which looks like a read of x - but it isn't.
    
    pointers are different, you have to put a * infront
    to dereference them
Comment 2 Tim Bagot 2003-08-26 11:02:01 UTC
Can I ask you to reconsider? The usual assignment operator idiom requires
returning a reference. Of course, it's perfectly possible to write volatile
assignment operators to return void, but that's not the expected semantics.

The return statement in the function definition doesn't generate any warning
(and even if it did, explicitly casting to reference wouldn't be too onerous),
but every call of the function does, and it can begin to drown out the rest of
the output. Even if you decide to keep the warning, an option to disable it
would be nice.
Comment 3 Andrew Pinski 2004-04-26 19:54:12 UTC
I actually agree with Nathan here, volatile causes you to think you are going to access it 
every time you write it out.
Comment 4 Andrew Pinski 2004-04-26 19:54:21 UTC
I actually agree with Nathan here, volatile causes you to think you are going to access it 
every time you write it out.
Comment 5 Joseph Garvin 2010-04-09 21:06:54 UTC
As a separate affected user, might I ask you guys to reconsider again? If you're writing a smart pointer class in C++, users expect that you will support all the same operators with all the same semantics. AFAICT, there is no way to do that without generating this warning. You must implement an operator= that returns a volatile reference to support assignment of your volatile smart pointer because the default generated assignment operator doesn't work for volatile objects.
Comment 6 Jonathan Wakely 2010-04-12 11:19:38 UTC
(In reply to comment #5)
> you're writing a smart pointer class in C++, users expect that you will support
> all the same operators with all the same semantics.

do you mean that users expect this?

volatile SmartPtr& SmartPtr::operator=(const SmartPtr&) volatile;

I'm not sure I agree

Comment 7 Joseph Garvin 2010-04-12 12:19:44 UTC
Right, I think that's what users expect, assuming you are in a situation where volatile smart pointers make sense in the first place (in my case they are smart pointers to addresses within a shared memory region -- a case in which I think they make sense but I've been wrong before ;). In general I can see how volatile references could make code more difficult to read, and this is the one place I use them, so maybe the warning could just be changed to make operator= return type an exception to the matching rule?
Comment 8 Jonathan Wakely 2010-04-12 12:30:41 UTC
(In reply to comment #7)
> smart pointers to addresses within a shared memory region

then shouldn't that be "SmartPtr<volatile T>" rather than "volatile SmartPtr<T>" ?

the former points to an object which might change due to effects outside the program, the latter implies that the smart pointer itself might change, which only makes sense if the smart pointer object exists in shared memory (as opposed to pointing to shared memory)
Comment 9 Joseph Garvin 2010-04-12 15:00:10 UTC
(In reply to comment #8)
> (In reply to comment #7)
> the former points to an object which might change due to effects outside the
> program, the latter implies that the smart pointer itself might change, which
> only makes sense if the smart pointer object exists in shared memory (as
> opposed to pointing to shared memory)

In this case both are true; I'm building linked lists in shared memory. So it's a volatile pointer to a volatile object.