site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Oops clicked send while trying to move the window... Anyway consider an md5 digest in hex form or if you can handshake consider a UUID. man 3 md5 man 3 UUID -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Aug 21, 2008, at 10:04 AM, Brian Bergstrand wrote: On Aug 21, 2008, at 6:23 PM, Shawn Erickson wrote: On Thu, Aug 21, 2008 at 8:20 AM, Shawn Erickson <shawnce@gmail.com> wrote: On Thu, Aug 21, 2008 at 6:47 AM, <markregister@mac.com> wrote: I have been working on porting some POSIX C/C++ inhouse code to OS X and have run into a problem with shm_open. It looks like the size of SHM_NAME_MAX is 32 characters (noted on some older posts here). Because our code specifies a file using a path, name and PID, it usually exceeds this so I'm looking for any ideas to get around this problem. Any thoughts on how to do this (using good programming practices)? A 32 character long hash of the path, name and pid? Actually, shm names are limited to 31 chars as the last byte is for the NULL term. I've had a bug open since Mar 2006 to increase the name size to 64bytes: rdar://4481762 It hasn't been addressed, and it won't be until we can deal with it in a POSIX conformant way, without increasing wired memory, which just naievely increasing the size of the structure by increasing the string length would do. When someone asks if they should use POSIX shared memory, we generally tell them we prefer mmap'ed files, if you want a large path to things, and that has the bonus of not taking wired memory, providing the same string-based rendezvous, plus you can use FS permissions, including ACLs, to protect access to the shared memory itself. This email sent to site_archiver@lists.apple.com