• "Johnny Willemsen" <jwillemsen remedy.nl> Oct 06 2004
• Scott Michel <scottm aero.org> Oct 06 2004
• "Johnny Willemsen" <jwillemsen remedy.nl> Oct 06 2004
• Scott Michel <scottm aero.org> Oct 06 2004
• "Johnny Willemsen" <jwillemsen remedy.nl> Oct 06 2004
• Scott Michel <scottm aero.org> Oct 07 2004

Hi,

During the port of ACE/TAO to DMC, another issue. We have ACE_OS::umask, the 
problem is now that in io.h umask is a macro defined as _umask. Any plans to 
zap this macro, this is giving problems when someone has a method called 
u_mask.

Johnny

Btw, daily build results with the progess on 
http://www.dre.vanderbilt.edu/~remedynl/dm/ 

Johnny Willemsen wrote:
 Hi,
 
 During the port of ACE/TAO to DMC, another issue. We have ACE_OS::umask, the 
 problem is now that in io.h umask is a macro defined as _umask. Any plans to 
 zap this macro, this is giving problems when someone has a method called 
 u_mask.
 
 Johnny


Given that "tell" is also a macro, my SWAG is "probably not". The reason 
why these various and sundry functions are defined as macros is for 
portability across different Windows/DOS OSes (i.e. "historical reasons".)

Hi,

 During the port of ACE/TAO to DMC, another issue. We have ACE_OS::umask, 
 the problem is now that in io.h umask is a macro defined as _umask. Any 
 plans to zap this macro, this is giving problems when someone has a 
 method called u_mask.


 Given that "tell" is also a macro, my SWAG is "probably not". The reason 
 why these various and sundry functions are defined as macros is for 
 portability across different Windows/DOS OSes (i.e. "historical reasons".)


Yes, but this now gives now portability problems because we have already 
code that uses umask as method name, and then we call _umask as normal 
method. This makes the port to DMC only harder, because I can't change the 
ACE code.

Johnny 

Johnny Willemsen wrote:
 Hi,
 
 
During the port of ACE/TAO to DMC, another issue. We have ACE_OS::umask, 
the problem is now that in io.h umask is a macro defined as _umask. Any 
plans to zap this macro, this is giving problems when someone has a 
method called u_mask.


Given that "tell" is also a macro, my SWAG is "probably not". The reason 
why these various and sundry functions are defined as macros is for 
portability across different Windows/DOS OSes (i.e. "historical reasons".)


 
 Yes, but this now gives now portability problems because we have already 
 code that uses umask as method name, and then we call _umask as normal 
 method. This makes the port to DMC only harder, because I can't change the 
 ACE code.


Maybe it's the fact that English is not your native language, but I'm 
having difficulty understanding your problem. What I do understand is 
that there is a method named ACE_OS::umask, which becomes ACE_OS::_umask 
due to macro expansion (right?) and this macro expansion breaks the ACE 
build. If this is the case, then you might consider the following:

#if defined(__DMC__)
#define real_umask _umask
#undef umask
#endif

Then call real_umask from within ACE_OS::umask. Presumably you have to 
add or tailor the code inside ACE_OS::umask, no?

Hi,

During the port of ACE/TAO to DMC, another issue. We have ACE_OS::umask, 
the problem is now that in io.h umask is a macro defined as _umask. Any 
plans to zap this macro, this is giving problems when someone has a 
method called u_mask.


Given that "tell" is also a macro, my SWAG is "probably not". The reason 
why these various and sundry functions are defined as macros is for 
portability across different Windows/DOS OSes (i.e. "historical 
reasons".)



 Yes, but this now gives now portability problems because we have already 
 code that uses umask as method name, and then we call _umask as normal 
 method. This makes the port to DMC only harder, because I can't change 
 the ACE code.


 Maybe it's the fact that English is not your native language, but I'm 
 having difficulty understanding your problem. What I do understand is that 
 there is a method named ACE_OS::umask, which becomes ACE_OS::_umask due to 
 macro expansion (right?) and this macro expansion breaks the ACE build. If 
 this is the case, then you might consider the following:

 #if defined(__DMC__)
 #define real_umask _umask
 #undef umask
 #endif

 Then call real_umask from within ACE_OS::umask. Presumably you have to add 
 or tailor the code inside ACE_OS::umask, no?


The problem was more that I was too busy with several things.

Yes, you are right, I could use the defines you give, but this makes 
maintenance a lot harder. All other platforms just have _umask and umask as 
function. This makes it much easier. I have not investigated how many umask 
functions ACE has, but it can be a few. When DMC makes umask() a function 
nobody in the world has a problem when he/she also has a umask() method and 
wants to use DMC.

Johnny 

Johnny Willemsen wrote:
  > Yes, you are right, I could use the defines you give, but this makes
 maintenance a lot harder. All other platforms just have _umask and umask as 
 function. This makes it much easier. I have not investigated how many umask 
 functions ACE has, but it can be a few. When DMC makes umask() a function 
 nobody in the world has a problem when he/she also has a umask() method and 
 wants to use DMC.


You seem to fail to grasp that on the Windows platform, there are 
several and sundry different umask functions from which to choose. 
There's going to be an emulated one for Win16 and DOS, and a semi-real 
one for Win32 (but emulated in Win32s). To keep development FUproof, 
umask is a macro -- defined to match the function that should be called 
in the appropriate environment. It's either that or tracking down really 
strange bugs when some unwitting coder mixes different libraries.

It's inconvenient because you're porting to a new compiler, but these 
are challenges that many, if not most, of us have faced over the lengths 
of our professional careers. Take the STLport "steaming heap of code" 
that I just ported to DMC. It's got fewer OS-dependent issues, but a lot 
of my time was spent tracking down various issues that may or may not 
make their way back into the main STLport code. A couple of the issues 
turned out to be real compiler bugs, which had to be trimmed down to the 
smallest code possible so that Walter can actually deal with fixing the 
problem.


-scooter