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 Tue, 26 Apr 2005 14:51:57 GMT
On 4/26/05, William A. Rowe, Jr. <wrowe@rowe-clan.net> 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.

Well, although I understand your reasons, my reasoning is that it was
never and still isn't part of the API: it's not part of the apr_* and
APR_* name spaces.
> Actually deprecating this before 2.0 is problematic as well,
> although using apr_os_pid_t in 0.9 here forward is goodness.

I actually disagree: the long term solution would be to use
apr_os_proc_t where I currently introduced apr_os_pid_t: that's the
type for the purpose. I wanted to maintain binary compatibility, so I
solved it this way. Also, using apr_os_proc_t causes a circular
reference in the header files: it's required by apr_thread_proc.h and
defined in apr_portable.h (which includes apr_thread_proc)....

Just my opinion, but if you don't kill {p,u,g}id_t from the interface,
then I don't see any reason to use the patch either. But if you don't
kill them, you're not even helping my problem in the long run. (Given
the compat rules, I didn't even hope for short-term help...)



View raw message