apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: [PATCH] Don't define POSIX types {p,g,u}id_t
Date Fri, 29 Apr 2005 05:43:37 GMT
>> Allowing the application to choose to suppress the typedefs with
>> something like:
>> ...
>> #endif
>> wouldn't really break the API guarantee for 0.9.x or 1.x, I suppose.
> Well, that would be even less ideal than the apr_os_pid_t solution,
> but I can't deny it will work for my case. The ruby folks suggested
> something similar, but that won't work in their case as I'm using SWIG
> which generates an '#include "ruby.h"' before I can insert anything
> myself.

However you would have the option of specifying 
-DAPR_DONT_DEFINE_PGUID_T on the command line that compiles your SWIG 
generated code.

I did a little research:

No stock Microsoft header appears to define pid_t, uid_t and gid_t.  I 
checked a recent Platform SDK, VC5, 6, and VS.NET 2003.

Borland C++ 5.6.4 <sys/types.h> defines uid_t and gid_t but not pid_t.

MinGW's <sys/types.h> defines pid_t (guarded by _PID_T_), but not uid_t 
or gid_t.

Unix <sys/types.h> define all three but there is no collision since 
apr.h.in doesn't attempt to provide alternative definitions.

uid_t and gid_t does not appear to be used in Windows builds since all 
uses  in sections that are #if !defined(WIN32).

pid_t appears to be misused in apr_thread_proc.h's apr_proc_t struct 
and in static methods in apr_random.c

My current thoughts:

Add a new typedef for the pid member in apr_ and other misuses of pid_t 
if any.

Add a typedef in apr.h.in and apr.hnw that equivalences the new type 
with pid_t.

Add a typedef in apr.hw that equivalences the new type with int

Do not define uid_t,  gid_t, pid_t for non-Microsoft compilers.  Since 
APR hasn't previously build with Borland or MinGW there aren't any 
existing successfully compiled programs to worry about.

Define uid_t, gid_t and pid_t when:

a) Using a Microsoft compiler
b) APR_DECLARE_EXPORT is not set (that is not building apr.lib which 
shouldn't need any of the deprecated definitions)

I can take a shot at working this up tomorrow.

Any suggestions about what to call the new type?  It can't be 
apr_os_proc_t since that would be a void* on Windows not the current 

Instead of APR_DONT_DEFINE_PGUID_T, how about something more generic 
that indicates that we are not trying for perfectly source 
compatibility.  In some ways, it would be like turning the deprecation 
flag on in javac.

View raw message