Hi, In message <[EMAIL PROTECTED]> on Sat, Jan 03, 2004 at 11:28:15AM +0100, Ard Biesheuvel wrote: > > Here is the code in exec.c, > > ----------------------------------------------------------- > > line# 586: pid_t child, wait_pid; > > line# 587: > > line# 588: child = (pid_t)rsrc->ptr; > > [EMAIL PROTECTED] wrote: > >rsrc->ptr is a generic use "bucket". Generally it's meant to hold a > >pointer to some data. In this case, pid_t is trusted to never have a > >larger storage size than void* (to do so would require 16-bit pointers > >and 32-bit PIDs or 32-bit pointers and 64-bit PIDs, etc...) so rather > >than malloc()ing a container for child, we just drop child itself into > >the pointer bucket.
I plead with you not to continue using habits that make PHP non-portable (or at least that you acknowledge the need for proper, non-bodged, ./configure tests)! Non-portable shortcuts and weird hard-coded values continue to appear in PHP from year-to-year and it's frustrating for administrators of machines running PHP. Although some developers love using "won't fix" or "don't care for anyone to fix it" for bugs, you must generally *not* store arithmetic values in pointer storage, unless you are assigning zero. My understanding is that the consequences violating the constraints on C assignments must be considered "implementation-defined" (e.g. some environments could map all non-pointer values to zero) and may cause errors if they are unrepresentable as pointers. Pointers types are not strictly arithmetic integer types. I'm sure you get away with abusing them on most systems, but it is bad form to consider this a portable technique. Perhaps there is even the possibility that some environments, as part of runtime checks and balances, will signal a process merely upon assignment of out-of-range pointer values. But aside from that, past experience seems to have shown that poking integers into pointers leads to an accumulation of back-to-front assignments and conversion errors. > How about doing this > child = (long)rsrc->ptr; ?? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
