- Boost - lists.boost.org

Re: [boost] [encrypted strings]
by Kasra 27 Apr '09

27 Apr '09

Hi, I am working on a Crypto library for that could do compile time encryption/decryption, however, requires 'constexpr' support from the compiler: template<class T> constexpr void encrypt(T& cipher_text, const T& plain_text) const throw(bad_state); template<class T> constexpr void decrypt(T& cipher_text, const T& plain_text) const throw(bad_state); -- Kasra

2 1

Re: [boost] [encrypted strings]
by raindog＠macrohmasheen.com 27 Apr '09

27 Apr '09

Boost does not have one. If I were you however I would look into a commercial protector such as themida (www.oreans.com) or armadillo or asprotect. ------Original Message------ From: Sid Sacek Sender: boost-bounces(a)lists.boost.org To: boost(a)lists.boost.org ReplyTo: boost(a)lists.boost.org Sent: Apr 27, 2009 8:21 AM Subject: [boost] [encrypted strings] Does boost have any compile-time classes for string encryption? Is it even possible? When a hacker dumps an executable, they can see all of the strings the program might use, and some of those strings may contain sensitive information. Does boost have any classes that can encode the strings at compile-time? Ideally, the third string in the code below would never compile the "secret" string into the final binary. Regards, -Sid void foo( void ) { char const * s1 = "abc"; string s2 = "xyz"; encrypted_string s3( "secret" ); } _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Sent from my Verizon Wireless BlackBerry

2 1

[tokenizer] Deprecated class used by default
by Boris Schaeling 27 Apr '09

27 Apr '09

I just noticed that although the class char_delimiters_separator is deprecated it is used by default by Boost.Tokenizer. I don't know when char_delimiters_separator was deprecated in favor of char_separator but it goes back to 1.33.1 (see http://www.boost.org/doc/libs/1_33_1/libs/tokenizer/index.html) Any plan to change the default class soon (doesn't need to be in 1.39.0 of course as it's pretty late for such a change)? Boris

1 0

beta docs on the website
by Michael Marcin 27 Apr '09

27 Apr '09

Shouldn't http://beta.boost.org/doc/ have 1.39 docs at this point? -- Michael Marcin

2 1

[asio] send blocks with MSG_DONTWAIT (linux)
by Stefan Pledl 27 Apr '09

27 Apr '09

If i pass the flag MSG_DONTWAIT to basic_stream_socket::send(buffers, flags) the call blocks in the following situation. -> Connection is established (boost::asio::socket_base::send_buffer_size option(2048) is set) -> sending data form local endpoint to remote endpoint -> remote endpoint does not read the data due to software bug/crash etc. -> sendqueue (see netstat) on local endpoint runs full -> send on local endpoint blocks at this point I think the flag MSG_DONTWAIT should avoid this blocking call. If i do the same using C-function send(fd, buf*, len, flag) the call does not block. I have analyzed the code and i think the problem is in send function in asio/detail/reactive_socket_service.hpp socket_ops::send returns but socket_ops::poll_write blocks. I have added the following changes (see comments __SP__) and all works ok for me. Is the blocking desired or where is my mistake? modified code form asio/detail/reactive_socket_service.hpp ---------------------------------------------------------- // Send the given data to the peer. template <typename ConstBufferSequence> size_t send(implementation_type& impl, const ConstBufferSequence& buffers, socket_base::message_flags flags, boost::system::error_code& ec) { if (!is_open(impl)) { ec = boost::asio::error::bad_descriptor; return 0; } // Copy buffers into array. socket_ops::buf bufs[max_buffers]; typename ConstBufferSequence::const_iterator iter = buffers.begin(); typename ConstBufferSequence::const_iterator end = buffers.end(); size_t i = 0; size_t total_buffer_size = 0; for (; iter != end && i < max_buffers; ++iter, ++i) { boost::asio::const_buffer buffer(*iter); socket_ops::init_buf(bufs[i], boost::asio::buffer_cast<const void*>(buffer), boost::asio::buffer_size(buffer)); total_buffer_size += boost::asio::buffer_size(buffer); } // A request to receive 0 bytes on a stream socket is a no-op. if (impl.protocol_.type() == SOCK_STREAM && total_buffer_size == 0) { ec = boost::system::error_code(); return 0; } // Send the data. for (;;) { // Try to complete the operation without blocking. int bytes_sent = socket_ops::send(impl.socket_, bufs, i, flags, ec); // Check if operation succeeded. if (bytes_sent >= 0) return bytes_sent; // Operation failed. if ((impl.flags_ & implementation_type::user_set_non_blocking) || (ec != boost::asio::error::would_block && ec != boost::asio::error::try_again)) return 0; // __SP__ // do not poll if flag MSG_DONTWAIT is set if (flags & MSG_DONTWAIT) return 0; // __SP__ // Wait for socket to become ready. if (socket_ops::poll_write(impl.socket_, ec) < 0) return 0; } }

2 1

Re: [boost] discussion of garbage collection in C++
by Kasra 27 Apr '09

27 Apr '09

Edward Diener wrote: >Also, for people looking for a runtime envrironment for C++, they can look >at Ch. Or CERN.ROOT.CINT project. Either way we are looking at GC in C++ from the wrong direction. I like to know and be able to determine where the memory allocation deallocation occurs. When the constructor and destructor is called using RAII, however, this doesn't mean I shouldn't use GC. GC is supposed to release unused memory, not to call the destructors of objects; although it does on most implementations. [example bool g(int); for(int i=0; i<10000; i++) { // allocate a memory of size = sizeof(Foo) // then construct an instance of Foo on that memory gc_ptr<Foo> f(new (gc) Foo()); // if g(i) == true, delete the memory if( g(i) ) operator delete(f, gc); } // delete all of the objects. GC::collect(); example] The distinction is between construction/destruction of objects and allocation/deallocation of memory. We let GC to perform allocation/deallocation of memory, while we allow ourselves optionaly to take control of construction/destruction of the objects allocated on that memory. This distinction is so important while everyone ignores :D -- Kasra

3 2

[ASIO] Host not found (authoritative)
by Alexander Dong Back Kim 27 Apr '09

27 Apr '09

Dear members, This is a very beginner's question on ASIO. I followed the tutorial example "daytime" in the ASIO document. Server one seems running well because nestat shows the port has been opened and listening. However, when I run the client one, the application prints out "Host not found (authoritative)" message only. I'm using port 21165. $ ./client localhost:21165 Is my command wrong? cheers, Alex Kim

1 0

[1.39] Merge to release
by Daniel James 27 Apr '09

27 Apr '09

Is it okay to merge this? https://svn.boost.org/trac/boost/changeset/52598 It's just a trivial CSS bug fix. thanks, Daniel

4 3

[gc] new implementation in boost vault that solves the issue of finalization order
by Achilleas Margaritis 26 Apr '09

26 Apr '09

Hi. I have posted a new gc implementation in the boost vault here: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=gc1.zi… The code included in the file is a garbage collector with the following differences from the previous one: 1) finalization order that respects destructor semantics, except when there are cycles. In the previous collector, the order of finalization was random. In the new collector, an unreachable object A that is pointed to by another unreachable object B will be finalized after B is finalized. This allows the use of gc ptrs within destructors. 2) O(1) detection of member ptrs: pointers registers themselves to the appropriate ptr list as they are created. In the previous collector, pointers where discovered in the collection phase by look-up on the sorted blocks. The code is not completed or polished, but it is published for discussing possible implementation ideas. The main bottleneck right now is how to locate blocks from pointers. The current solution is to sort the blocks by address at collection time, then use std::upper_bound to locate the blocks. This has O(log2(N)) complexity, where N is the number of blocks.

1 0

[ANN] Spirit V2.1 (beta) committed to the Boost SVN
by Hartmut Kaiser 26 Apr '09

26 Apr '09

Hi all, The Spirit team proudly announces that we committed Spirit V2.1 (beta) to the Boost SVN (trunk). We will continue the development there, so please don't use the Spirit SVN anymore as it will quickly go out of sync. Spirit V2.1 is a complete rewrite of V2.0, while maintaining most of the V2 interface. We will add a comprehensive document explaining what's changed soon. Here are some of the highlights: - More homogeneous interface (multi-attribute API similar to printf/scanf, but using Qi/Karma format descriptions) - More balanced set of primitives and directives (Qi and Karma now better complement each other) - Reduced compile times! Compilation is up to 50% faster if compared to equivalent code from V2. - Optimized execution times. Spirit is now faster than ever before. - Simplified usage of grammars and token definitions - Fixed a whole bunch of bugs and inconsistencies - etc. Please report any experience you might gain (good and bad)! As a side note: Joel and I will give a talk about Spirit V2.1 at BoostCon in Aspen slightly more than a week from now. You still can register (www.boostcon.com) if you haven't done yet. On behalf of the Spirit team Regards Hartmut PS: We would like to thank all who participated and contributed to this. It really was a major team work!

1 0