Hi Przemek,
It's not possible to make a perfect decision here,
unless investing extreme energy (like those flags)
to keep bug compatibility, not to mention what an
ugly inconsistency this is. My personal opinion in this
case is to fix this Clipper bug in Harbour, and make it
available using a switch for those few ppl who are relying
on them and haven't yet corrected their code. I suspect
there is not too many such ppl, and even most of this
code is probably macro compiled.
I do not like Clipper behavior. For me it's a bug which may
confuse users, f.e. try this code with Clipper:
? CHR( 256 ) == CHR( 256 ), CHR( 256 ) == CHR( ( 256 ) )
? "" $ "", "" $ (""), ("") $ ""
? AT( "", "" ), AT( ( "" ), "" ), AT( "", ( "" ) )
We agree. I personally don't need this bug at all.
If you ask me we can just fix it and leave it at that.
Question: Do we do all these optimization for macro
code too, and do we have a way to disable it? Yes and
yes is the answer AFAIK, so IMO we're covered.
Clipper does not make any optimizations for macro compiled
code so it gives correct results executing RT functions or
evaluating PCODE. We are making the optimizations but for
macro compiler Harbour calculates correct results so there
is not problem here.
Even better. So I expect not too many ppl having
Chr( 1024 ) and "" $ "string" in real life code, since
the expressions are pointless, they are side cases
(invalid or close to invalid input) by themselves,
someone using such expressions with _full literals_
is even more pointless. So besides inspecting these
in a lab, like some strange viruses, they serve no
purpose, and I don't expect finding them in too much
real world code.
[ NOTE: Clipper '87 had these right, and I bet
- but I cannot try right now - the rest of Clipper
compiler has this right too. ]
I'd plug these just to not forget about them, but these
will need new pcodes, so it's a slightly different story:
- HB_P_PUSHNIL + HB_P_RETVALUE would become: HB_P_RETNIL
- HB_P_FALSE + HB_P_RETVALUE would become: HB_P_RETFALSE
- HB_P_TRUE + HB_P_RETVALUE would become: HB_P_RETTRUE
- SUBSTR(s,n,1) -> HB_P_SUBSTR1 (or whatever name)
- ASC(SUBSTR(s,n,1)) -> HB_P_SUBSTR1ASC (or whatever name)
These I'll add after 1.0. Now I do not want to touch PCODE table
as long as we will not find some serious bug which will force
such operation.
Absolutely fine.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
