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