Re: Remove support for old names in runtime

Hans Leidekker wrote:

>On Saturday 27 March 2004 13:00, Earnie Boyd wrote:
>
>  
>
>>What is breaking compatibility with Win32 projects????  Give examples of
>>the breakage.  We've been at this a long time and the first I've heard
>>of such breakage.
>>    
>>
>
>Defining anything in a header beyond what MS defines potentially
>breaks a source written to MS headers. That should be enough of a
>reason to keep extras out IMO. 
>
Potentially breaking isn't fixable.  There are reasons for a long 
standing definition in our headers.  Primarily that reason is to ease 
the pain in porting UNIX and older programs to Win32.  Potentially 
breaking isn't a reason for change.

>If you really can't resist adding 
>things then at least protect the extras with an #ifdef so that 
>it's users have to explicitly ask for them to be included.
>
>  
>
We have filtered the code as you've already stated.  It is in our 
interest to provide the defaults we have.  Our interests have existed 
since the beginning of the project.  Changing our interests now would 
create a different project.

>The case at hand is cross compiling Wine dlls with MinGW. configure
>checks for the presence of fpclass() which accidentally gets detected. 
>configure is actually looking for this fpclass() (from the manpage 
>on SunOS):
>  
>
>     fpclass_t fpclass(double dsrc);
>
>     fpclass() returns the class the dsrc  belongs  to.   The  10
>     possible classes are as follows:
>
>          FP_SNAN             signaling NaN
>          FP_QNAN             quiet NaN
>          FP_NINF             negative infinity
>          FP_PINF             positive infinity
>          FP_NDENORM          negative denormalized non-zero
>          FP_PDENORM          positive denormalized non-zero
>          FP_NZERO            negative zero
>          FP_PZERO            positive zero
>          FP_NNORM            negative normalized non-zero
>          FP_PNORM            positive normalized non-zero
>
>MinGW's fpclass() doesn't have these return values, it only has 
>the _FPCLASS_* return values from _fpclass(). So one could also
>argue that MinGW has incomplete compatibility with fpclass() i.e.
>it lacks the corresponding defines. Anyway, see the problem?
>  
>
So we need to ``#define FP_* _FPCLASS_*'' in the header.  Possibly even 
``#define fpclass_t int''.  Would that resolve the issue?

Earnie

-- 
http://www.mingw.org
http://sourceforge.net/projects/mingw
https://sourceforge.net/donate/index.php?user_id=15438




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click