filesystem::is_directory return true when exception is disabled and this directory does't exist

// the snip of code in filesystem::is_directory begin--- DWORD attributes = ::GetFileAttributesA( ph.native_directory_string().c_str() ); if ( attributes == 0xFFFFFFFF ) boost::throw_exception( filesystem_error( "boost::filesystem::is_directory", ph, fs::detail::system_error_code() ) ); return (attributes & FILE_ATTRIBUTE_DIRECTORY) != 0; //-------------------------------------------------------end-- When GetFileAttributesA failed but the exception is disabled, the (attributes & FILE_ATTRIBUTE_DIRECTORY) will always be true. Is it a bug?

At 10:01 AM 10/11/2004, Liao Weijie wrote:
// the snip of code in filesystem::is_directory begin---
DWORD attributes = ::GetFileAttributesA( ph.native_directory_string().c_str() ); if ( attributes == 0xFFFFFFFF ) boost::throw_exception( filesystem_error( "boost::filesystem::is_directory", ph, fs::detail::system_error_code() ) ); return (attributes & FILE_ATTRIBUTE_DIRECTORY) != 0;
//-------------------------------------------------------end--
When GetFileAttributesA failed but the exception is disabled, the (attributes & FILE_ATTRIBUTE_DIRECTORY) will always be true.
Is it a bug?
No. It is undefined behavior for boost::throw_exception() to return. To quote the throw_exception() docs: Callers of throw_exception are allowed to assume that the function never returns; therefore, if the user-defined throw_exception returns, the behavior is undefined. --Beman

Beman Dawes wrote:
At 10:01 AM 10/11/2004, Liao Weijie wrote:
// the snip of code in filesystem::is_directory begin---
DWORD attributes = ::GetFileAttributesA( ph.native_directory_string().c_str() ); if ( attributes == 0xFFFFFFFF ) boost::throw_exception( filesystem_error( "boost::filesystem::is_directory", ph, fs::detail::system_error_code() ) ); return (attributes & FILE_ATTRIBUTE_DIRECTORY) != 0;
//-------------------------------------------------------end--
When GetFileAttributesA failed but the exception is disabled, the (attributes & FILE_ATTRIBUTE_DIRECTORY) will always be true.
Is it a bug?
No. It is undefined behavior for boost::throw_exception() to return.
To quote the throw_exception() docs:
Callers of throw_exception are allowed to assume that the function never returns; therefore, if the user-defined throw_exception returns, the behavior is undefined.
It is definitely not a bug. However you might want to consider - purely as a QoI issue, of course - to return 'false' instead of 'true' when throw_exception returns. ;-)

No. It is undefined behavior for boost::throw_exception() to return.
To quote the throw_exception() docs:
Callers of throw_exception are allowed to assume that the function never returns; therefore, if the user-defined throw_exception returns, the behavior is undefined.
It is definitely not a bug. However you might want to consider - purely as a QoI issue, of course - to return 'false' instead of 'true' when throw_exception returns. ;-)
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
It's very strange. So, does it mean the exception must be enabled if the throw_exception is used ?

At 06:35 PM 10/11/2004, you wrote:
No. It is undefined behavior for boost::throw_exception() to return.
To quote the throw_exception() docs:
Callers of throw_exception are allowed to assume that the function never returns; therefore, if the user-defined throw_exception returns, the behavior is undefined.
It is definitely not a bug. However you might want to consider - purely as a QoI issue, of course - to return 'false' instead of 'true' when throw_exception returns. ;-)
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
It's very strange. So, does it mean the exception must be enabled if the throw_exception is used ?
Either enable exceptions or define BOOST_NO_EXCEPTIONS and provide a user supplied throw_exception(). The user supplied throw_exception() presumably terminates the program via std::abort() or similar function. --Beman
participants (4)
-
Beman Dawes
-
I Wei
-
Liao Weijie
-
Peter Dimov