Sign in to follow this  
dcosborn

volatile auto_ptr

Recommended Posts

dcosborn    674
I'm using libpng, which uses longjmp, and I want to have my image data in an auto_ptr. The possibility of a longjmp means that I must make this auto_ptr volatile. I'm having some trouble dereferencing this volatile auto_ptr.
#include <memory>

struct T
{
	int a;
};

int main()
{
	volatile std::auto_ptr<T> ptr(new T);
	ptr->a; // fails
	const_cast<std::auto_ptr<T> &>(ptr)->a; // works
}
The simple pointer access gives "error: passing 'volatile std::auto_ptr<T>' as 'this' argument of '_Tp* std::auto_ptr<_Tp>::operator->() const [with _Tp = T]' discards qualifiers". Casting away the cv-qualifier seems to work, but will it still access the variable as if it were a volatile variable (ie: is it still guaranteed to be defined in a longjmp)?

Share this post


Link to post
Share on other sites
iMalc    2466
I spent a while trying this out, and all I can tell you is that nothing at all seems to work when you declare an auto_ptr as volatile (beyond the declaration that is).
How do you expect making it volatile will help anything, btw?

Share this post


Link to post
Share on other sites
siaspete    208
I'm fairly sure you can override libpng's default "oh crap!" function with your own, so that might help. In this case you may want to throw an exception or something.

But it's been a while since I worked with libpng so I can't say for sure.

Share this post


Link to post
Share on other sites
dcosborn    674
iMalc: Yeah I noticed that too. I'm thinking maybe its because the member functions would need to be qualified as volatile in order to be callable when the object is volatile. Similar to how const objects can only call const member functions. I need it to be volatile so that it will still be defined after a longjmp (since longjmp has semantics that cause regular automatic variables to become undefined). I'm catching the longjmp in the same scope as the auto_ptr, and then calling an exception which should cause normal processing to resume (ie: the auto_ptr gets destructed).

siaspete: That's a good idea. I already do provide my own error callback, but I thought that libpng might still call longjmp at some point. I should probably check out the documentation again; I think you may be right and it shouldn't need to call longjmp ever if I provide my own.

Thanks guys.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this