Cliff Woolley <[EMAIL PROTECTED]> writes:
> On 6 Dec 2001 [EMAIL PROTECTED] wrote:
>
> > {
> > - apr_os_proc_t var;
> > - memset(&var, 0, sizeof var);
> > + apr_os_proc_t var = 0;
> > sprintf(buf, "%" APR_OS_PROC_T_FMT, var);
>
> Can you actually assign 0 to an apr_os_proc_t on all platforms (or at
> least all platforms where the test works)?
>
> # grep apr_os_proc_t *.h
> apr_portable.h:typedef PROCESS_INFORMATION apr_os_proc_t;
>From cygwin's header files:
typedef struct _PROCESS_INFORMATION {
HANDLE hProcess;
HANDLE hThread;
DWORD dwProcessId;
DWORD dwThreadId;
} PROCESS_INFORMATION,*LPPROCESS_INFORMATION;
Well of course you're right... When I first wrote the code I didn't
know of a current case where it would fail but thought that I'd be
extra careful. Then I screwed up (missing prototype) and kicked
myself for trying to be so clever.
But note also that I don't see how APR_OS_PROC_T_FMT holds up on a
system where you can't assign a scalar to apr_os_proc_t. You won't be
able to use APR_OS_PROC_T_FMT. (Somebody stand up and call me a fool
at this point?) So I don't think the real fix is going back to
memset() but rather ensuring that APR_OS_PROC_T_FMT isn't defined on
such a system?
Another possibility: some macro to grab an appropriate scalar value
from apr_os_proc_t... on Windows grab the hProcess field; other
current APR ports would just use the raw apr_os_proc_t... conceivably
some weird APR port would need a function to work some magic
(I'm assuming in all this that there is a good reason for
apr_os_proc_t to be PROCESS_INFORMATION on Win32 rather than just
hProcess or dwProcessId.)
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
