Re: [Harbour] ieeefp.h - what's the significance?
On Wed, 23 Dec 2009, Tamas TEVESZ wrote: Hi, > ok, so there are two places where this is used, in src/rtl/math.c:334 > onwards and src/vm/itemapi.c:2250 onwards. Three. src/common/hbprintf.c also includes it. Here is the only one place when we try to use different C99 FL functions not only finite() and we can use as argument 'long double' values not only double ones. It means that if possible we should not force arguments conversion to double because on some hardware or (and) when some fast math optimization switches are enabled it may cause SIGFPE if argument is not valid FL number. Harbour itself does not use any NaN values so it's not a problem for valid code but in some wrong user code it may cause detecting the source of problem harder. > they are even used for the same purpose, to check whether or not to > signal a range error of sorts on a numeric argument. In itemapi.c we only try to detect finite double values. In math.c when HB_MATH_ERRNO is set we try to detect also NaN values and we should cleaned this code because now it's possible that it will not work with compilers not supporting C++ isnan()/isinf() macros. In hb_snprintf() we additionally try to detect type of infinity and sign bit. I agree that it will be nice to use common macros set in all three files defined in some separate header file, i.e. hbfloat.h which will make all platform dependent #includes and define some HB_*() macros which we can use in other code. > yet the one in itemapi.c is a macro with a screenful of tests for > platforms and compilers and whatnot, whereas the one in math.c is a > very simple conditional for os2-sunos-all-the-rest. notably, it > doesn't have a special case for os/2 -- nb i do not know if > "defined( __RSXNT__ ) || defined( __EMX__ )" covers _all_ of os2; if > it does, then scratch this last remark, but then the notation is > inconstent. > why is this difference? The code in math.c was enabled only in some GCC builds so this trivial condition was working but in fact it's wrong and should be updated to use more precise logic. In some spare time I'll check if I can easy create hbfloat.h file which can be easy used also with hbprintf.c and if yest then I'll commit it. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] ieeefp.h - what's the significance?
Tamas TEVESZ wrote: > doesn't have a special case for os/2 -- nb i do not know if > "defined( __RSXNT__ ) || defined( __EMX__ )" covers _all_ of os2; if > it does, then scratch this last remark, but then the notation is > inconstent. > Tamas, the answer to your question is: no. There is OpenWatcom on OS/2 which should define neither one. Best regards. Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] ieeefp.h - what's the significance?
On Wed, 23 Dec 2009, Przemysław Czerpak wrote: hi, sorry to be so blunt, but the more i read, the less i understand ;) > isinf() and isfinite() are C99 extensions so they are not available if > C99 features are not enabled. > There is problem with non GCC unix builds - they do not use HB_MATH_ERRNO > handler (I'll fix it in next commit) and it's the reason why current > src/rtl/math.c. do not need ieeefp.h. ok, so there are two places where this is used, in src/rtl/math.c:334 onwards and src/vm/itemapi.c:2250 onwards. they are even used for the same purpose, to check whether or not to signal a range error of sorts on a numeric argument. yet the one in itemapi.c is a macro with a screenful of tests for platforms and compilers and whatnot, whereas the one in math.c is a very simple conditional for os2-sunos-all-the-rest. notably, it doesn't have a special case for os/2 -- nb i do not know if "defined( __RSXNT__ ) || defined( __EMX__ )" covers _all_ of os2; if it does, then scratch this last remark, but then the notation is inconstent. why is this difference? (i probably should have picked something less hardcore...) -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] ieeefp.h - what's the significance?
On Wed, 23 Dec 2009, Tamas TEVESZ wrote: Hi, > > Probably nothing though sometimes is good to check the details in > > platform documentation. It's possible that in ieeefp.h some functionality > > is extended, i.e. some math functions from math.h can be replaced by > > C99 compatible macros which can operate on any floating point types. > so, if available, using these is desirable? It really depends what it exactly does on given platform. If it's not necessary at all then it's preferred to not include it at all to not confuse users and increase dependency list. > i'm asking because looking at current src/rtl/math.c, except for a few > specific cases, isinf() is used: > 334 # if defined( HB_OS_SUNOS ) > 335 else if( !finite( dResult ) ) > 336 # elif defined( HB_OS_OS2 ) > 337 else if( !isfinite( dResult ) ) > 338 # else > 339 else if( isinf( dResult ) ) > 340 # endif > > at the same time, looking at the solaris manuals for finite(), > isinf() and finite() here (won't have access to my sol box till next > year): > > http://docs.sun.com/app/docs/doc/819-2246/isinf-3m?l=Ja&a=view > http://docs.sun.com/app/docs/doc/819-2246/isfinite-3m?l=Ja&a=view > http://docs.sun.com/app/docs/doc/801-6680-03/6i11qck75?a=view > > it seems that the currently special-cased finite() for hb_os_sunos > specifically fits your above explanation less than as if it was to let > use isinf() as well. > i may very well be misunderstanding you, though.. isinf() and isfinite() are C99 extensions so they are not available if C99 features are not enabled. There is problem with non GCC unix builds - they do not use HB_MATH_ERRNO handler (I'll fix it in next commit) and it's the reason why current src/rtl/math.c. do not need ieeefp.h. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] ieeefp.h - what's the significance?
On Wed, 23 Dec 2009, Przemysław Czerpak wrote: hi, > > on platforms where available, what is the significance of including > > ieeefp.h, given that even without it, things seem to be doing OK? > > Probably nothing though sometimes is good to check the details in > platform documentation. It's possible that in ieeefp.h some functionality > is extended, i.e. some math functions from math.h can be replaced by > C99 compatible macros which can operate on any floating point types. so, if available, using these is desirable? i'm asking because looking at current src/rtl/math.c, except for a few specific cases, isinf() is used: 334 # if defined( HB_OS_SUNOS ) 335 else if( !finite( dResult ) ) 336 # elif defined( HB_OS_OS2 ) 337 else if( !isfinite( dResult ) ) 338 # else 339 else if( isinf( dResult ) ) 340 # endif at the same time, looking at the solaris manuals for finite(), isinf() and finite() here (won't have access to my sol box till next year): http://docs.sun.com/app/docs/doc/819-2246/isinf-3m?l=Ja&a=view http://docs.sun.com/app/docs/doc/819-2246/isfinite-3m?l=Ja&a=view http://docs.sun.com/app/docs/doc/801-6680-03/6i11qck75?a=view it seems that the currently special-cased finite() for hb_os_sunos specifically fits your above explanation less than as if it was to let use isinf() as well. i may very well be misunderstanding you, though.. -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] ieeefp.h - what's the significance?
On Wed, 23 Dec 2009, Tamas TEVESZ wrote: Hi, > on platforms where available, what is the significance of including > ieeefp.h, given that even without it, things seem to be doing OK? Probably nothing though sometimes is good to check the details in platform documentation. It's possible that in ieeefp.h some functionality is extended, i.e. some math functions from math.h can be replaced by C99 compatible macros which can operate on any floating point types. In Harbour we are using it only in SunOS builds for finite() function and as I can see this code should be cleaned because it works only for GCC builds. I'll commit the fix ASAP. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] ieeefp.h - what's the significance?
hi, on platforms where available, what is the significance of including ieeefp.h, given that even without it, things seem to be doing OK? thanks, -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
