Re: Re: #26769 [Opn->WFx]: 64 bit pointer

Two things I didn't mention in that bug close: (1) This is already "fixed" in PHP5 which uses "struct php_process_handle" to store the child PID and other values. It is malloced into a pointer and will not throw this type of error. (2) Saying "whoever did that was wrong" is unprofessional, particularly given #1 above. While I agree that storing integer data in a void* element is a bad idea, it is nonetheless a functional one. "James Devenish" <j-devenish@users.sourceforge.net> wrote in message news:20040103113550.GA28361@mail.guild.uwa.edu.au... > Hi, > > In message <20040103102820.46575.qmail@pb1.pair.com> > 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; > > > > pollita@php.net 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; > > ??