On Sat, 01 Mar 2008, Phil Barnett wrote:
> Przemek.
> The list traffic seems to have died down. I think this would be an
> appropriate
> time for a release.
> Your thoughts?
I agree though I recently ported some Clipper+CT3 application to Harbour
and I've found some incompatibilities and problems I fixed and I do not
know if I should commit it now. F.e. I've found some strange behavior of
transform() function.
Small investigation shows that this is a problem created by us. Instead of
real fix a hack was committed which break other things and then we have
a series of fixes for problems which were caused by this hack. Just simply
'9' do not interrupt function part of picture expression. This happened
in both Harbour and xHarbour repositories and now both projects have
workarounds for it. When I touch it then I've found other problem with
this function. Neither Harbour nor xHarbour return valid results for
some situations. In xHarbour developers tired to "fix" some of them but
they addressed only some special cases instead of resolving the problem.
The xHarbour transform() implementation has even hard coded hacks to pacify
some hbtest warnings for "@" when result size is smaller then 5 bytes!
It's nonsense because it will work only with hbtest because it depends
on the order of executed transform() and set(_SET_DATEFORMAT,...)
functions - In Clipper it's static buffer overflow bug.
I've even disabled these tests from hbtest left this note:
/* CA-Cl*pper do not check result size and always exchanges
* bytes 1-2 with bytes 4-5 for @E conversion. It's buffer overflow
* bug and I do not want to replicate it inside our transform
* implementation. It also causes that the results for for strings
* smaller then 5 bytes behaves randomly.
* In fact precise tests can show that it's not random behavior
* but CA-Cl*pper uses static buffer for result and when current one
* is smaller then 5 bytes then first two bytes are replaced with
* 4-5 bytes from previous result which was length enough, f.e.:
* ? transform( "0123456789", "" )
* ? transform( "AB", "@E" )
* ? transform( "ab", "@E" )
* [druzus]
*/
I fixed also other problems I found after some small tests:
! fixed bug with '9' used as stop condition of function pattern
this character cannot be stripped, f.e.:
? transform( "abc", "@_99*" )
! fixed bug with '*' or '$' used with @), f.e.:
? transform( -12345, "@) $999999" )
! fixed replacing '.' with ',' when @E is used without picture part, f.e.:
? transform( 123.45, "@E" )
! fixed ',' conversions
? transform( 12.34,"@E ab,cd.ef9,9.99,.--" )
! fixed bug with picture starting with ".", f.e.:
? transform( 0.3456, ".999" )
! fixed "@(" and "@)" conversions, f.e.:
? transform( -12345, "@) 1999*999" )
! fixed late oveflow detection in "@(" and "@)", f.e.:
? transtest( -12345, "@( 6798^999" )
! fixed "@E" conversion for dates to keep user delimiters set in
_SET_DATEFORMAT, f.e.:
set( _SET_DATEFORMAT, "mm:dd:yyyy" ); ? transform( date(), "@E" )
set( _SET_DATEFORMAT, "yyyy<mm>dd" ); ? transform( date(), "@E" )
Please note that Harbour is not strictly Clipper compatible here
because it respects _SET_DATEFORMAT set by user.
! fixed 64bit integer conversion by eliminating conversion to
'double' f.e.:
? transform( 1234567890123456789, "99999999999999999999" )
? transform( -1234567890123456789, "99999999999999999999" )
% speed improvement in numeric conversions
but I do not know if it's good idea to touch such important function
just before release. Your opinion?
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
