----- Original Message -----
From: "Przemyslaw Czerpak" <[EMAIL PROTECTED]>
To: "Harbour Project Main Developer List." <harbour@harbour-project.org>
Sent: Thursday, September 04, 2008 1:25 PM
Subject: Re: [Harbour] debug bug
On Thu, 04 Sep 2008, bill robertson wrote:
Hi Bill,
In the example below:
-------------------------------------
FUNCTION MAIN()
LOCAL cVar
ALTD()
cVar:= 5 // Just to stop on something
RETURN 0
--------------------------------------
If I go to the command window of the debugger and ask a few questions:
? s // nil as expected
This is a bug, should be: "Undefined" instead of "NIL"
? (s:= 3) // 3 as expected
It's OK.
? s // nil - not expected
We can implement it but it in Clipper it creates new
private variable 's' inside main() function in the above
example what may effect executing program.
xHarbour and Clipper show s = 3 instead of nil.
Which xHarbour version?
I've tested current one and it gives exactly the same results
as Harbour. Some older xHarbour versions may behaves differently
because all memvar variables created inside macro evaluated by
TYPE() function were created as PUBLIC ones instead of PRIVATE
which should be destroyed after leaving current function. A side
effect of this behavior can give the results you are looking for.
It's very useful to do a few calculations and save results for tests you
didn't anticipate.
What do you need exact Clipper behavior or temporary variables inside
debugger only?
best regards,
Przemek
Hi Przemek,
I used whatever the latest xHarbour build was
xHarbour Compiler build 1.1.0 (SimpLex) (Rev. 6207)
I was trying to debug an Extrasensory Software program for another
developer. He is moving an old clipper application to xHarbour that uses
their implementation of DES (ECB mode) and needed it duplicated so he could
run the clipper app while moving from 16-bit to 32-bit system. I was just
trying to duplicate some of their behavior and was using the debugger to
calc some values that I hadn't anticipated when I noticed the difference
between Harbour and Clipper. Clipper compatibility for this is not anything
that needs to be done; I can always throw in a few temp values if I need to
do this sort of play. I'm doing most of tests in clipper anyway since thats
where the library functions are.
I noticed that you fixed the md5 problem (xHarbour hasn't) so you will
understand this. Extrasensory DES ignored the high-order bit of each of the
8-byte key instead of the low-order bit producing wrong answers to any copy
of DES that is available. They don't support the product anymore and didn't
seem to have the source when asked. I tried to get advice on sci.crypt but
got only one reply and it was something that I had already tried. Have you
any experience with DES? What might I try? I don't have their DES library
but I could give other developer instructions on stripping object out of
library and try obj2c or something. I hate to do that it's such a mess. I
have a small program incorporating their library in Clipper where I can get
anything I need. Little needs to be done in harbour or clipper; most of the
work must be done in c since I need to fix the real DES to work their way.
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
