On Thu, 28 Jan 2010, smu johnson wrote:
Hi,
> I appreciate the answer. I don't like hacks either, as I have found some
> other hacks that I've had to try to work around. I wrote the EMPTY thing
> (as we do use the .ch file) and it solved the problem! So thanks for that.
> As far as the question of if you want to implement SIX3 defaults... you
> would know a lot better than I would if it's a good idea.
Please only remember that it should not be used for normal indexes.
> I will say one
> thing though, it will help Clipper programmers who have had a hard time
> getting SIX3 to work back 10 years ago and have stumbled upon it "just
> working" back then...
> Since Harbour seems to be 100% Clipper compliant, I would think it would be
> a good idea. But then again, I don't like hacks either :( So it is really
> your call.
SIX3 RDDs are not Clipper part. I know that they are very popular and
I also have SIX3.02 package but when I begin to make deeper tests with
this library I've found such many serious bugs that in my opinion it
was never fully production ready. Buffer overflows, memory corruptions,
index file corruption, memo and data file corruptions, wrongly updated
index files, problems with accessing some valid indexes files, etc.
I can understand that someone make a mistake and the code should be
fixed but in few cases they intentionally introduced hacks which cannot
work and _HAVE_ to give wrong results and this causes that I stop to
trust Successware and their products. This code quite well illustrate it:
request SIXCDX
proc main()
field FINT
rddSetDefault( "SIXCDX" )
dbcreate( "_tst", { { "FINT", "V", 4, 0 } } )
use _tst
dbappend()
FINT := 538976287; ? FINT
FINT := 538976288; ? FINT
FINT := 538976289; ? FINT
return
This code compiled by Clipper and linked with SIX3 SIXCDX RDD shows:
538976287
0
538976289
Funny isn't it?
What is amazing in 538976288 number that it cannot be stored in V4
fields giving 0 as result?
Its binary representation is equal to space(4) and spaces are used
as default initialization value in DBF record. It means that someone
hacked in SIX3 code that exactly this value (538976288) when read from
DBF record is translated to 0. He had to know that such hack breaks
this field usage and it's a bug which can cause very serious problems
for users. But it is very hard to locate such bug for normal users who
do not know what should be tested so it was not creating SIX3 selling
problems and was accepted in the final product. Maybe they didn't have
wrong motivation but in my opinion such things should never happen.
Some anomalies which are not critical I replicated in SIXCDX and HBSIX
library but for sure I cannot replicate hacks like above only to be
bug compatible. In case of Clipper I usually try to document all anomalies
but there are too much problems with SIX3 library to address all of them
so it would be waste of time.
> One last question though, if I may. How often do I have to worry about this
> EMPTY / CUSTOM addition? Is it just whenever I want to use sx_keyadd? Or
> are there other pitfalls I should look out for.
It should be add only to INDEX ON command which create index with key
expression starting with "sxChar(", "sxNum(", "sxDate(" or "sxLog(".
That's all.
best regards,
Przemek
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
