On Mon, 02 Jun 2008, Szakáts Viktor wrote:
Hi Viktor,
> 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( "", ( "" ) )
> 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.
> 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.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
