Modify

Ticket #4100 (closed Bugs: invalid)

Opened 5 years ago

Last modified 2 years ago

some boost classes have sizeof that depends on NDEBUG

Reported by: fjoe@… Owned by: jano_gaspar
Milestone: Boost 1.43.0 Component: circular_buffer
Version: Boost 1.42.0 Severity: Problem
Keywords: Cc:

Description

In boost 1.42:

1) boost::range_iterator: range/iterator_range.hpp:

#ifndef NDEBUG bool singular; #endif

Seems already fixed in trunk

2) boost::circular_buffer: circular_buffer/base.hpp:

template <class T, class Alloc> class circular_buffer /*! \cond */ #if BOOST_CB_ENABLE_DEBUG : public cb_details::debug_iterator_registry #endif

3) statechart::detail::id_provider: statechart/detail/rtti_policy.hpp

struct id_provider {

const void * pCustomId_;

#if defined( BOOST_ENABLE_ASSERT_HANDLER )
!defined( NDEBUG )

const std::type_info * pCustomIdType_; #endif

};

The problem is rather serious if two binaries that are loaded into the same address space (e.g. a library and a program, or two libraries) are built with different defines (one with NDEBUG, the other without it).

Attachments

Change History

comment:1 Changed 5 years ago by marshall

  • Owner set to jano_gaspar
  • Component changed from None to circular_buffer

comment:2 Changed 5 years ago by jano_gaspar

How I am supposed to fix this?

comment:3 Changed 5 years ago by anonymous

Just do not use NDEBUG in headers.

comment:4 Changed 5 years ago by jano_gaspar

It doesn't make any sense. You would run into the same trouble if one library is compiled with BOOST_CB_DISABLE_DEBUG defined and another without. It is rather a language deficiency than a library bug.

comment:5 Changed 5 years ago by anonymous

I was not 100% correct. In this particular case BOOST_CB_ENABLE_DEBUG (that depends on NDEBUG or BOOST_CB_DISABLE_DEBUG) should not affect sizeof. You can use it to do some additional checks, but sizeof() should always be the same.

NDEBUG is quite common macro. It should never affect sizeof.

comment:6 Changed 5 years ago by marshall

NDEBUG is quite common macro. It should never affect sizeof.

That's quite a assertion. Could you back that up, please?

Just do not use NDEBUG in headers.

Checking on my system, I find that the C++ standard library shipped with gcc 4.2 uses NDEBUG in headers, as does php and wx-windows.

The problem is rather serious if two binaries that are loaded into the same address space (e.g. a library and a program, or two libraries) are built with different defines (one with NDEBUG, the other without it).

This is absolutely true - in that case, you would have an  ODR violation. However, I don't think that this is a problem with the boost library, but rather with your build configuration.

comment:7 Changed 5 years ago by jano_gaspar

The problem is that I want to have circular buffer's debug support automatically enabled in debug mode and disabled in release mode.

Let me ask you a question: Suppose the NDEBUG macro does not affect the size but it affects the implementation of the methods only. Now considering your example of two binaries in the same address space - do you think such a program will now work OK? If so then why?

Last edited 5 years ago by jano_gaspar (previous) (diff)

comment:8 Changed 5 years ago by anonymous

Seems that my last comment is lost: the use-case is that there is a library that uses boost and that I do not have control of. It's not the problem with my build configuration. I do not want to sync my CPPFLAGS with build-time flags for that library.

Such depends on quite common macros as NDEBUG is just not good for a general purpose library as boost or STL.

Also, I do not see NDEBUG in gcc 4.2 STL headers (as shipped with FreeBSD 8.1) and gcc 4.5 STL headers (as shipped with Debian Squeeze). php and wxWidgets are not general purpose libraries and I would not care about them at all.

As for identical in-memory layout but different behavior -- I would not care as long as ABI is not broken. This means that if you have additional members you should implement copy constructors and = operators properly (and other assignments to them) regardless of NDEBUG, but you can do additional checks that use these members in !NDEBUG case. I do not see anything wrong with it.

comment:9 Changed 5 years ago by jano_gaspar

OK, will fix it then. The debug support won't be turned on by default in the debug mode.

comment:10 Changed 4 years ago by Sylvain Joyeux

Not fixed in trunk. Any plans so far ?

comment:11 Changed 4 years ago by Olaf van der Spek <olafvdspek@…>

AFAIK VC container sizeof depends on NDEBUG too. I don't think it's reasonable to expect to be able to mix DEBUG and NDEBUG stuff.

comment:12 Changed 2 years ago by viboes

There is nothing that say that people can mix debug and not debug modes, so for me this is an invalid ticket.

comment:13 Changed 2 years ago by viboes

  • Status changed from new to closed
  • Resolution set to invalid
View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.