id	summary	reporter	owner	description	type	status	milestone	component	version	severity	resolution	keywords	cc
5108	shared memory object temporary name bug, Mac OSX 10.6.6	david.ibbitson@…	Ion Gaztañaga	"There is a problem with creating a shared memory object in a 64 bit application and trying to open it in a 32 bit application. The problem seems to stem from the following snippet of code, found in the function get_bootstamp defined on line 50 of the file tmp_dir_helpers.hpp.

{{{
   std::size_t char_counter = 0;
   long fields[2] = { result.tv_sec, result.tv_usec };
   for(std::size_t field = 0; field != 2; ++field){
      for(std::size_t i = 0; i != sizeof(long); ++i){
         const char *ptr = (const char *)&fields[field];
         bootstamp_str[char_counter++] = Characters[(ptr[i]&0xF0)>>4];
         bootstamp_str[char_counter++] = Characters[(ptr[i]&0x0F)];
      }
   }
}}}

On my system sizeof(long) = 4 under a 32 bit application, and sizeof(long) = 8 on a 64 bit application. Hence the generated temporary filename stored in bootstamp_str is of differing lengths under a 32 bit app and a 64 bit app respectively.  Hence, I was seeing the error ""file or directory does not exist"" when trying to open a named shared memory object.

The fix (cross platform?) seems to be to use the type ""long long"" because sizeof(long long) = 8 under 32 and 64 bit application.

{{{
   std::size_t char_counter = 0;
   long long fields[2] = { result.tv_sec, result.tv_usec };
   for(std::size_t field = 0; field != 2; ++field){
      for(std::size_t i = 0; i != sizeof(long long); ++i){
         const char *ptr = (const char *)&fields[field];
         bootstamp_str[char_counter++] = Characters[(ptr[i]&0xF0)>>4];
         bootstamp_str[char_counter++] = Characters[(ptr[i]&0x0F)];
      }
   }
}}}

Making this change fixed this problem for me. 
Hope this helps!

David
"	Bugs	closed	To Be Determined	interprocess	Boost 1.45.0	Showstopper	fixed	shared memory object