redefinition uid_t

[Oscar Pernas <os...@pernas.es>]

Hi all,

I'm using apr in a process that uses CORBA TAO, for communications. My
problem is that TAO and APR has the same redefinition of a variable.

In apr.h i can see:

typedef int uid_t ;
typedef int pid_t;
typedef int gid_t;

However in TAO I could see:

typedef long uid_t
typedef long pid_t


Im in Win32 and Win64 platform. I've commented it in apr source and library
compiles well, Could I have any problem? What would be the best solution?


thanks in advance!


-- 
Óscar Pernas Plaza.

Re: redefinition uid_t

[Oscar Pernas <os...@pernas.es>]

Hi Jeff,


Thanks for your response. Im also having one more error with this structure:

struct iovec
{
    void *iov_base;
    size_t iov_len;
};

Its weird because, the preprocessor definition APR_WANT_IOVEC is not defined
in the project, and in all the projects that I use and uses apr (log4cxx,
activemqcpp...). I'd added a personal preprocessor definition and now it
compiles, but, could cause any problem?


thanks!

2011/10/18 Jeff Trawick <tr...@gmail.com>

> On Tue, Oct 18, 2011 at 9:26 AM, Oscar Pernas <os...@pernas.es> wrote:
> > Hi all,
> > I'm using apr in a process that uses CORBA TAO, for communications. My
> > problem is that TAO and APR has the same redefinition of a variable.
> > In apr.h i can see:
> > typedef int uid_t ;
> > typedef int pid_t;
> > typedef int gid_t;
> > However in TAO I could see:
> > typedef long uid_t
> > typedef long pid_t
> >
> > Im in Win32 and Win64 platform. I've commented it in apr source and
> library
> > compiles well, Could I have any problem? What would be the best solution?
>
> I think that's the best solution for now.  APR doesn't actually need
> to define uid_t for its own purposes.
>
> That general issue -- defining Unix types -- should be be fixed in the
> next major (i.e., not binary compatible) release.  In cases other than
> uid_t there may be other fallout to handle.  For example, apr_proc_t
> uses (requires) pid_t.
>
> According to our API compatibility rules, something equivalent to
>
> #ifndef APR_PLEASE_DONT_DEFINE_UNIX_TYPES
> typedef whatever uid_t
> #endif
>
> could be provided with apr 1.5.x.  That would be worthwhile if the fix
> could be near-complete.  (I dunno the complete fallout.)
>



-- 
Óscar Pernas Plaza.

Re: redefinition uid_t

[Jeff Trawick <tr...@gmail.com>]

On Tue, Oct 18, 2011 at 9:26 AM, Oscar Pernas <os...@pernas.es> wrote:
> Hi all,
> I'm using apr in a process that uses CORBA TAO, for communications. My
> problem is that TAO and APR has the same redefinition of a variable.
> In apr.h i can see:
> typedef int uid_t ;
> typedef int pid_t;
> typedef int gid_t;
> However in TAO I could see:
> typedef long uid_t
> typedef long pid_t
>
> Im in Win32 and Win64 platform. I've commented it in apr source and library
> compiles well, Could I have any problem? What would be the best solution?

I think that's the best solution for now.  APR doesn't actually need
to define uid_t for its own purposes.

That general issue -- defining Unix types -- should be be fixed in the
next major (i.e., not binary compatible) release.  In cases other than
uid_t there may be other fallout to handle.  For example, apr_proc_t
uses (requires) pid_t.

According to our API compatibility rules, something equivalent to

#ifndef APR_PLEASE_DONT_DEFINE_UNIX_TYPES
typedef whatever uid_t
#endif

could be provided with apr 1.5.x.  That would be worthwhile if the fix
could be near-complete.  (I dunno the complete fallout.)