apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Huelsmann <ehu...@gmail.com>
Subject Re: [PATCH] Don't define POSIX types {p,g,u}id_t
Date Wed, 27 Apr 2005 07:51:11 GMT
On 4/27/05, Joe Orton <jorton@redhat.com> wrote:
> On Tue, Apr 26, 2005 at 08:47:25AM -0500, William Rowe wrote:
> > At 08:24 AM 4/26/2005, Erik Huelsmann wrote:
> > >On 4/26/05, Joe Orton <jorton@redhat.com> wrote:
> > >>
> > >> Will this not break programs on Windows which hitherto presumed that APR
> > >> defines these types?  i.e. it breaks the source-compatibility API
> > >> guarantee for APR 1.x?
> > >
> > >Yes, it does, if you consider that an APR api promise. I don't: I
> > >consider it an unfortunate side effect of header file structuring (a
> > >bug to be fixed): the APR type to use (in 1.1.x) always has been
> > >apr_os_proc_t which serves the purpose of pid_t in a platform
> > >independent way.
> >
> > As 0.9 API is considered released/stable, backporting isn't an
> > option.  We could replace with a #ifndef / #define construct,
> > but in 0.9, the symbol has to remain.
> 
> Allowing the application to choose to suppress the typedefs with
> something like:
> 
> #ifndef APR_DONT_DEFINE_PGUID_T
> ...
> #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.

bye,


Erik.

Mime
View raw message