| delorie.com/archives/browse.cgi | search |
Robert Collins wrote: > key_t, as it's used for ipc, is likely to be *problematic* to transition > in a 'fat binary' style. > > You'd need a 32 bit set of key creation routines, and and translation > table to lookup 32bit keys in the list of 64 bit keys .... Which basically aliases the entire 64bit key space down to 32bit space -- which kinda short circuits whole reason that cygdaemon wanted 64bits in the first place. I don't think it's worthwhile to do a 'fat binary' style implementation for key_t. > Given that cygipc is *not* in cygwin today, and you'd be adding it, I'd > simply have it 64 bit from the first release uploaded to sources. Yes, I agree -- but (obviously) only if newlib/cygwin decide that the 64bit key_t definition is a good idea, and accept a patch to do so. > And I'd time that for oh, a day after cygwin 1.5 goes up as a testing > package. (And release cygipc as testing whilst cygwin 1.5 stays in > testing). Yeah, that sounds reasonable. I take it you're in favor of adding cygipc to the distro (or are you speaking academically)? --Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |