Hi,

At Mon, 25 Apr 2005 18:38:51 +0900,
Erik Huelsmann wrote in [ruby-core:04783]:
> > > I was also thinking that maybe both sides should use (in the unix
> > > version of their systems) ruby_pid_t and apr_pid_t. Then, those can be
> > > defined to pid_t on Unix systems and to int on Win32. Also, it would
> > > prevent namespace conflicts...
> > 
> > Ruby is just using AC_TYPE_UID_T.  So, using typedef for them,
> > like as apr.h, means conflicts to all of autoconfiscated
> > softwares.  I think apr.h should #undef before typedef.
> 
> Ah, but it only does that on Windows, not on POSIX platforms. On POSIX

Not only on Windows, any platforms which don't have [ugp]id_t.

> platforms, it uses what's there. Just like Ruby. I don't think it's a
> solution for ruby to require that APR uses #undef before the typedef:
> that would require a change to *all* software with which Ruby is meant
> to be compiled on windows. Not a pretty solution.

And APR requires a change to all autoconfiscated softwares.

> I think neither APR nor Ruby should be 'messing' with types defined by
> POSIX. I'm preparing a patch for APR to stop doing this.

Agreed.  typedef which can'te be redefined nor detected at
compile time shouldn't, at least.

> I intend to provide a patch for Ruby which defines a rb_pid_t (and
> friends) for all platforms. (If you want it to be differently named:
> that's fine ofcourse.) On windows it will be defined to int, on other
> platforms, it will be defined to AC_TYPE_PID_T.

rb_pid_t sounds good enough, and ruby itself would be too, but
what about extension libraries using those types?

-- 
Nobu Nakada