apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: cvs commit: apr/test testfmt.c
Date Thu, 06 Dec 2001 12:30:11 GMT
Cliff Woolley <cliffwoolley@yahoo.com> writes:

> On 6 Dec 2001 trawick@apache.org 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;

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 | trawick@attglobal.net | PGP public key at web site:
             Born in Roswell... married an alien...

View raw message