Passed by Reference failed - Clipper 5.2e bug ? 
Author Message
 Passed by Reference failed - Clipper 5.2e bug ?

Hi all,

I met a situation where an argument passed by reference still
retained it's old value. Is it Clipper's bug or I miss something
obvious ? I use Clipper 5.2e + Blinker 5.1. Here are the test case:

---- 8< cut ---------------

PROC MAIN
local bAction
bAction := ActionBlok()
eval( bAction )
RETURN

FUNCTION ACTIONBLOK()
local nValue

                 qout( nValue ) ; // <=Should print 1,however it is
still
NIL
             }

PROCEDURE DOSOMETHING(nValue)
nValue := 1
? nValue
RETURN

---- 8< cut ---------------

TIA,

--
Bambang P
Semarang 50144
Central Java
Indonesia.
----
Author of:
 FBrowse  - General browser class for Force Language
 MakForce - Powerful and Intuitive Make utility for almost any language
 < http://www.*-*-*.com/ ;
----
Send private messages to bpranoto at indosat dot net dot id



Mon, 12 Nov 2001 03:00:00 GMT  
 Passed by Reference failed - Clipper 5.2e bug ?

Quote:

> I met a situation where an argument passed by reference still retained
> it's old value. Is it Clipper's bug or I miss something obvious ? I use
> Clipper 5.2e + Blinker 5.1. Here are the test case:

> [SNIP test case]

The following code should better illustrate the problem:

----------------------------------------------------------------------------
Function Main()
Local nTest
Local bBlock1 := MakeBlock()

   eval( bBlock1 )
   eval( bBlock2 )

Return( NIL )

Function MakeBlock()
Local nTest

Function DoThing( n )

   n := 42

Return( NIL )
----------------------------------------------------------------------------

With CA-Clipper 5.2e the output is NIL and 42. What appears to be happening
here is some side-effect of local binding. It would appear that the binding
of nTest in MakeBlock() is stopping the modification via pass-by-reference.
While there isn't anything in the documentation to support such an ability
common sense and extrapolation of the workings of codeblocks would suggest
that it should and that this is indeed a bug.

You'll be interested to know that FlagShip gives the output 42 and 42.
Perhaps someone would be kind enough to run the above via CA-Clipper 5.3,
Xbase++ and harbour?

Those still on the harbour mailing list who may recall my attempt at raising
the subject of "bug compatibility" may want to take note of the above. I'd
strongly suggest that CA-Clipper is wrong and FlagShip is right.

--
Take a look in Hagbard's World: |   w3ng - The WWW Norton Guide reader.
http://www.acemake.com/hagbard/ |     eg - Norton Guide reader for Linux.
http://www.hagbard.demon.co.uk/ |    weg - Norton Guide reader for Windows.
Free software, including........| dgscan - DGROUP scanner for Clipper.



Mon, 12 Nov 2001 03:00:00 GMT  
 Passed by Reference failed - Clipper 5.2e bug ?

Quote:
>You'll be interested to know that FlagShip gives the output 42 and 42.
>Perhaps someone would be kind enough to run the above via CA-Clipper 5.3,
>Xbase++ and harbour?

Xbase++ will give 42 and 42 as output also

Peter Hendriks



Mon, 12 Nov 2001 03:00:00 GMT  
 Passed by Reference failed - Clipper 5.2e bug ?

Quote:

> You'll be interested to know that FlagShip gives the output 42 and 42.
> Perhaps someone would be kind enough to run the above via CA-Clipper 5.3,
> Xbase++ and harbour?

This is likely to be academic, but Clipper 5.01a gives NIL and 42.

Richard



Mon, 12 Nov 2001 03:00:00 GMT  
 Passed by Reference failed - Clipper 5.2e bug ?
Quote:


> > I met a situation where an argument passed by reference still retained
> > it's old value. Is it Clipper's bug or I miss something obvious ? I use
> > Clipper 5.2e + Blinker 5.1. Here are the test case:

> > [SNIP test case]

> The following code should better illustrate the problem:

> ----------------------------------------------------------------------------
> Function Main()
> Local nTest
> Local bBlock1 := MakeBlock()

>    eval( bBlock1 )
>    eval( bBlock2 )

> Return( NIL )

> Function MakeBlock()
> Local nTest

> Function DoThing( n )

>    n := 42

> Return( NIL )
> ----------------------------------------------------------------------------

> With CA-Clipper 5.2e the output is NIL and 42. What appears to be happening
> here is some side-effect of local binding. It would appear that the binding
> of nTest in MakeBlock() is stopping the modification via pass-by-reference.
> While there isn't anything in the documentation to support such an ability
> common sense and extrapolation of the workings of codeblocks would suggest
> that it should and that this is indeed a bug.

Not a bug, I think.  It is the nature of local and static variables that
their names don't actually exist in the compiled code so that references
to them must be in scope at compile time.  MakeBlock() violates this
constraint.  nTest in MakeBlock() is not the same as nTest in Main().  

If you define Private nTest in Main() and remove Local nTest from
MakeBlock() the above code works as you want it to.  

Quote:
> You'll be interested to know that FlagShip gives the output 42 and 42.
> Perhaps someone would be kind enough to run the above via CA-Clipper 5.3,
> Xbase++ and harbour?

> Those still on the harbour mailing list who may recall my attempt at raising
> the subject of "bug compatibility" may want to take note of the above. I'd
> strongly suggest that CA-Clipper is wrong and FlagShip is right.

If FlagShip allows this construct, it could be called an extension I
suppose.  I still don't think it's a 'bug' in Clipper.
--

"Everything should be made as simple as possible, but not simpler."
                    --- Albert Einstein ---


Mon, 12 Nov 2001 03:00:00 GMT  
 Passed by Reference failed - Clipper 5.2e bug ?


Quote:


>> > I met a situation where an argument passed by reference still retained
>> > it's old value. Is it Clipper's bug or I miss something obvious ? I use
>> > Clipper 5.2e + Blinker 5.1. Here are the test case:

>> > [SNIP test case]

>> The following code should better illustrate the problem:

>> [SNIP code]

>Not a bug, I think.  It is the nature of local and static variables that
>their names don't actually exist in the compiled code so that references
>to them must be in scope at compile time.  MakeBlock() violates this
>constraint.

Yes this is a bug. The non avaibility of local/static variable's name
doesn't have anything to do with this.

Quote:
>  nTest in MakeBlock() is not the same as nTest in Main().  

Look again to the Dave's MakeBlock() :

Function MakeBlock()
Local nTest

The nTest instance in the qout is definetely the same nTest in
DoThing()'s argument which should be 42 but not.

--
Bambang P
Semarang 50144
Central Java
Indonesia.
----
Author of:
 FBrowse  - General browser class for Force Language
 MakForce - Powerful and Intuitive Make utility for almost any language
 <http://force.szolnex.hu/pages/download/ftphigh.htm>
----
Send private messages to bpranoto at indosat dot net dot id



Mon, 12 Nov 2001 03:00:00 GMT  
 Passed by Reference failed - Clipper 5.2e bug ?

Quote:


>> I met a situation where an argument passed by reference still retained
>> it's old value. Is it Clipper's bug or I miss something obvious ? I use
>> Clipper 5.2e + Blinker 5.1. Here is the test case:

>> [SNIP test case]

>The following code should better illustrate the problem:

> [SNIP]

>While there isn't anything in the documentation to support such an ability
>common sense and extrapolation of the workings of codeblocks would suggest
>that it should and that this is indeed a bug.

> [SNIP]

>Those still on the harbour mailing list who may recall my attempt at raising
>the subject of "bug compatibility" may want to take note of the above. I'd
>strongly suggest that CA-Clipper is wrong and FlagShip is right.

My time doesn't permit to follow harbour mailing list for quite
sometime. I know you are a major participant in Harbour - has harbour
have detached local capability ? if it has, does it suffer the same
problem ?

--
Bambang P
Semarang 50144
Central Java
Indonesia.
----
Author of:
 FBrowse  - General browser class for Force Language
 MakForce - Powerful and Intuitive Make utility for almost any language
 <http://force.szolnex.hu/pages/download/ftphigh.htm>
----
Send private messages to bpranoto at indosat dot net dot id



Mon, 12 Nov 2001 03:00:00 GMT  
 Passed by Reference failed - Clipper 5.2e bug ?
Quote:





> >> > I met a situation where an argument passed by reference still retained
> >> > it's old value. Is it Clipper's bug or I miss something obvious ? I use
> >> > Clipper 5.2e + Blinker 5.1. Here are the test case:

> >> > [SNIP test case]

> >> The following code should better illustrate the problem:

> >> [SNIP code]

> >Not a bug, I think.  It is the nature of local and static variables that
> >their names don't actually exist in the compiled code so that references
> >to them must be in scope at compile time.  MakeBlock() violates this
> >constraint.

> Yes this is a bug. The non avaibility of local/static variable's name
> doesn't have anything to do with this.

> >  nTest in MakeBlock() is not the same as nTest in Main().

> Look again to the Dave's MakeBlock() :

> Function MakeBlock()
> Local nTest

> The nTest instance in the qout is definetely the same nTest in
> DoThing()'s argument which should be 42 but not.


refers to the Local nTest in MakeBlock().  The codeblock is returned to
Main() and executed there.  At that time, after MakeBlock() returns,
there is nothing left of any part of MakeBlock() and the codeblock
reference points nowhere.  

You may contend, and I may agree that it should be otherwise.  But it is
not.

I am not privy to CA-Clipper's imtimate implementation details but I
guess that Local variables are C automatic thingys which are placed on
the call stack.  When the function returns, they are gone.  I think.
--

"Everything should be made as simple as possible, but not simpler."
                    --- Albert Einstein ---



Mon, 12 Nov 2001 03:00:00 GMT  
 Passed by Reference failed - Clipper 5.2e bug ?


Quote:


>refers to the Local nTest in MakeBlock().


afterward.


                               |                       ^
                               |                       |
                               +----------------------

DoThing() and qout() are in the same block - could the both nTest are
not the same ?

Quote:
>  The codeblock is returned to
>Main() and executed there.  At that time, after MakeBlock() returns,
>there is nothing left of any part of MakeBlock() and the codeblock
>reference points nowhere.  

After makeblock() returns, Clipper run time system copies local
variables which are referred in the return codeblock - this feature is
called detached locals.

Quote:
>You may contend, and I may agree that it should be otherwise.  But it is
>not.

That's called discussion, right ? and I believe discussion is healthy
.  Please don't take it too serious. :)

Quote:

>I am not privy to CA-Clipper's imtimate implementation details but I
>guess that Local variables are C automatic thingys which are placed on
>the call stack.  When the function returns, they are gone.  I think.

You are quite right. However, the p-code model of Clipper makes some
magic are possible like detached locals, codeblocks,macros etc.

--
Bambang P
Semarang 50144
Central Java
Indonesia.
----
Author of:
 FBrowse  - General browser class for Force Language
 MakForce - Powerful and Intuitive Make utility for almost any language
 <http://force.szolnex.hu/pages/download/ftphigh.htm>
----
Send private messages to bpranoto at indosat dot net dot id



Tue, 13 Nov 2001 03:00:00 GMT  
 Passed by Reference failed - Clipper 5.2e bug ?

Quote:


> > With CA-Clipper 5.2e the output is NIL and 42. What appears to be
> > happening here is some side-effect of local binding. It would appear
> > that the binding of nTest in MakeBlock() is stopping the modification
> > via pass-by-reference. While there isn't anything in the documentation
> > to support such an ability common sense and extrapolation of the
> > workings of codeblocks would suggest that it should and that this is
> > indeed a bug.

> Not a bug, I think. It is the nature of local and static variables that
> their names don't actually exist in the compiled code so that references
> to them must be in scope at compile time. MakeBlock() violates this
> constraint. nTest in MakeBlock() is not the same as nTest in Main().

I think you've missed the point of the code. None of the code I posted
sought to make a link between nTest in MakeBlock() and nTest in Main(). The
error has nothing to do with variable names (locals don't have names, as you
yourself point out) and everything to do with the effects of lexical scoping
and the binding effects of codeblocks.

Quote:
> If you define Private nTest in Main() and remove Local nTest from
> MakeBlock() the above code works as you want it to.

You'll also have totally different code and you'll be missing the point of
the test and the point of the problem.

Quote:
> > Those still on the harbour mailing list who may recall my attempt at
> > raising the subject of "bug compatibility" may want to take note of the
> > above. I'd strongly suggest that CA-Clipper is wrong and FlagShip is
> > right.

> If FlagShip allows this construct, it could be called an extension I
> suppose.  I still don't think it's a 'bug' in Clipper.

I think you're wrong, re-read the code and re-evaluate the problem, think
about how local-binding works and consider what the example does. If you
still can't see it, consider the following instead:

----------------------------------------------------------------------------
Function Main()
Local nJoe
Local bBlock1 := MakeBlock()

   eval( bBlock1 )
   eval( bBlock2 )

Return( NIL )

Function MakeBlock()
Local nDave

Function DoThing( n )

   n := 42

Return( NIL )
----------------------------------------------------------------------------

Notice that the variables are now called nJoe and nDave to emphasize that
this has got nothing to do with variables names. Concentrate on the output
of the two evals(). Also, ask yourself what difference it would make if the
codeblock in MakeBlock() read like:

  {|| nDave := DoThing(), qout( nDave ) }

and DoThing() returned 42 instead. I think you'll see that the question is
regarding the effects of local binding in codeblocks in conjunction with
pass-by-reference.

--
Take a look in Hagbard's World: |   w3ng - The WWW Norton Guide reader.
http://www.acemake.com/hagbard/ |     eg - Norton Guide reader for Linux.
http://www.hagbard.demon.co.uk/ |    weg - Norton Guide reader for Windows.
Free software, including........| dgscan - DGROUP scanner for Clipper.



Tue, 13 Nov 2001 03:00:00 GMT  
 Passed by Reference failed - Clipper 5.2e bug ?

Quote:



> >Those still on the harbour mailing list who may recall my attempt at
> >raising the subject of "bug compatibility" may want to take note of the
> >above. I'd strongly suggest that CA-Clipper is wrong and FlagShip is
> >right.

> My time doesn't permit to follow harbour mailing list for quite sometime.
> I know you are a major participant in Harbour - has harbour have detached
> local capability ? if it has, does it suffer the same problem ?

I don't currently have any involvement with the harbour project so that
question is better asked of a harbour developer (I would download the latest
copy and try but the last time I looked someone had decided to package it
using one of the less well-known archive formats that, back when I used to
use it (the packager), was a non-open format. <deity> knows why someone
would want to use non-OpenSource tools to package an OpenSource project).

--
Take a look in Hagbard's World: |   w3ng - The WWW Norton Guide reader.
http://www.acemake.com/hagbard/ |     eg - Norton Guide reader for Linux.
http://www.hagbard.demon.co.uk/ |    weg - Norton Guide reader for Windows.
Free software, including........| dgscan - DGROUP scanner for Clipper.



Tue, 13 Nov 2001 03:00:00 GMT  
 Passed by Reference failed - Clipper 5.2e bug ?

Quote:


> refers to the Local nTest in MakeBlock(). The codeblock is returned to
> Main() and executed there. At that time, after MakeBlock() returns, there
> is nothing left of any part of MakeBlock() and the codeblock reference
> points nowhere.

> You may contend, and I may agree that it should be otherwise. But it is
> not.

Wrong. It doesn't "point nowhere", CA-Clipper has a limited implementation
of closures. Consider:

----------------------------------------------------------------------------
Function Main()
Local b := MakeBlock()

  ? eval( b )
  eval( b, 42 )
  ? eval( b )

Return( NIL )

Function MakeBlock()
Local nTest
Return( {|x| if( x == NIL, nTest, nTest := x ) } )
----------------------------------------------------------------------------

What output do you expect? What do you find when you run it? How does it
demonstrate that when the codeblock is returned to the level of Main() that
the variable nTest in the codeblock (which was a local in MakeBlock())
"points nowhere"?

Quote:
> I am not privy to CA-Clipper's imtimate implementation details but I guess
> that Local variables are C automatic thingys which are placed on the call
> stack. When the function returns, they are gone. I think.

Wrong.

--
Take a look in Hagbard's World: |   w3ng - The WWW Norton Guide reader.
http://www.acemake.com/hagbard/ |     eg - Norton Guide reader for Linux.
http://www.hagbard.demon.co.uk/ |    weg - Norton Guide reader for Windows.
Free software, including........| dgscan - DGROUP scanner for Clipper.



Tue, 13 Nov 2001 03:00:00 GMT  
 Passed by Reference failed - Clipper 5.2e bug ?

Quote:

> Perhaps someone would be kind enough to run the above via CA-Clipper 5.3,
> Xbase++ and harbour?

Clipper 5.3 outputs NIL and 42. Harbour outputs NIL and NIL.

Quote:
> I don't currently have any involvement with the harbour project so that
> question is better asked of a harbour developer (I would download the latest
> copy and try but the last time I looked someone had decided to package it
> using one of the less well-known archive formats that, back when I used to
> use it (the packager), was a non-open format. <deity> knows why someone
> would want to use non-OpenSource tools to package an OpenSource project).

Fortunately, that nonsense only lasted a few builds. The last few builds
that were posted to the email list were in ZIP format. Plus the group has
decided to mandate the use of open source development tools. Members will
be free to use any compiler they want, but the code has to compile with
GCC/DJGPP and build with GNUmake.

Quote:
>Those still on the harbour mailing list who may recall my attempt at
>raising the subject of "bug compatibility" may want to take note of the
>above. I'd strongly suggest that CA-Clipper is wrong and FlagShip is
>right.

We miss you, Dave! Please come back...
--
David G. Holm, Managing Member
Joint Software Development L.L.C
3134 Niles Rd  Suite D
St Joseph  MI  49085
(616)556-9600 Fax: 556-9950


Tue, 13 Nov 2001 03:00:00 GMT  
 Passed by Reference failed - Clipper 5.2e bug ?
Quote:



> > refers to the Local nTest in MakeBlock(). The codeblock is returned to
> > Main() and executed there. At that time, after MakeBlock() returns, there
> > is nothing left of any part of MakeBlock() and the codeblock reference
> > points nowhere.

> > You may contend, and I may agree that it should be otherwise. But it is
> > not.

> Wrong. It doesn't "point nowhere", CA-Clipper has a limited implementation
> of closures. Consider:

> ----------------------------------------------------------------------------
> Function Main()
> Local b := MakeBlock()

>   ? eval( b )
>   eval( b, 42 )
>   ? eval( b )

> Return( NIL )

> Function MakeBlock()
> Local nTest
> Return( {|x| if( x == NIL, nTest, nTest := x ) } )
> ----------------------------------------------------------------------------

> What output do you expect? What do you find when you run it? How does it
> demonstrate that when the codeblock is returned to the level of Main() that
> the variable nTest in the codeblock (which was a local in MakeBlock())
> "points nowhere"?

> > I am not privy to CA-Clipper's imtimate implementation details but I guess
> > that Local variables are C automatic thingys which are placed on the call
> > stack. When the function returns, they are gone. I think.

> Wrong.

I do stand corrected.  I had missed the bit about codeblocks carrying
around with them any locals and statics that they reference.  I have now
read up on it a little and practiced some.  Indeed, I have seen that it
works for the most part but does fail when the codeblock contains a
function which passes the local by reference expecting it to be changed
by the callee.  
--

"Everything should be made as simple as possible, but not simpler."
                    --- Albert Einstein ---


Tue, 13 Nov 2001 03:00:00 GMT  
 Passed by Reference failed - Clipper 5.2e bug ?

Quote:

> > Perhaps someone would be kind enough to run the above via CA-Clipper
> > 5.3, Xbase++ and harbour?

> Clipper 5.3 outputs NIL and 42. Harbour outputs NIL and NIL.

Codeblock binding still on the TODO list I take it? ;-)

Quote:
> > [SNIP harbour was using RAR as an archiver]

> Fortunately, that nonsense only lasted a few builds. The last few builds
> that were posted to the email list were in ZIP format. Plus the group has
> decided to mandate the use of open source development tools. Members will
> be free to use any compiler they want, but the code has to compile with
> GCC/DJGPP and build with GNUmake.

I notice that the (GCC) makefiles all still seem to assume that the
filesystem is case insensitive and that the file and directory names are
upper-case (even more interesting considering the archive is packed using
lowercase names). I take it nobody is working on Linux compatibility any
more?

--
Take a look in Hagbard's World: |   w3ng - The WWW Norton Guide reader.
http://www.acemake.com/hagbard/ |     eg - Norton Guide reader for Linux.
http://www.hagbard.demon.co.uk/ |    weg - Norton Guide reader for Windows.
Free software, including........| dgscan - DGROUP scanner for Clipper.



Tue, 13 Nov 2001 03:00:00 GMT  
 
 [ 29 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Clipper 5.2e update fails. HELP

2. Observation : Clipper 5.2e - Pre-processor bug

3. !!!Clipper 5.2e round() bug!!!

4. Clipper 5.2e round() bug!!!

5. Caution, DBSEEK() Bug Report, Clipper 5.2e

6. CA-Clipper 5.2e DBFCDX *BUG*

7. Are method args pass-by-value or pass-by-reference

8. Speed of pass by reference vs pass by value

9. Clipper DLL's using Clipper 5.2e and Blinker 5.10

10. Clipper 5.2e --> Clipper 5.3b

11. clipper 5.2e -vs- clipper 5.3

12. Clipper 5.2e, Clipper Tools and Novell 5 ???

 

 
Powered by phpBB® Forum Software