>>>>>>>Gerry-
>>>>>>>
>>>>>>>>"Theoretically" it is possible to have bug free code. Given enough time, _anything_ is possible; eg. "Big Bang".
>>>>>>>
>>>>>>>Nope. Impossible to _prove_. Impossible to test in all contexts on all systems under all conditions. Even your example. However, I did qualify my comments to Jim by saying a program of sufficient complexity to be useful.
>>>>>>
>>>>>>I'll give you a function that's possible to prove that may look impossible. Try this (very simple)

FUNCTION AddTwo
>>>>>>  LPARAMETERS tnOne, tnTwo
>>>>>>
>>>>>>  RETURN tnOne + tnTwo
>>>>>>ENDFUNC

>>>>>
>>>>>Hi George,
>>>>>
>>>>>I suppose you considered the possibility of errors that would result from calling this function with a non-numeric argument, or with 2 numbers whose magnitude would produce an overflow. The failure to check for these cases might be regarded as a bug, or should we conclude that it will suffice in general simply to throw an error and leave the consequences to an all-knowing error handler?
>>>>>
>>>>Mike,
>>>>
>>>>If we add checking either externally (preferably) or interally then we can handle all cases. The point, however, isn't the algorithm itself, but its proof. That's the important thing. If we do proper testing (proving), then the case is accounted for and handled appropriately.
>>>
>>>Right, George. Let's hope that your testing regime would also have included the possibility that there might happen to be a field with the name tnOne or tnTwo in the current record!
>>>
>>Mike,
>>
>>Even, if there were fields by those names (a highly unlikely possibility), the fact that the parameters are local to the routine, removes the possibility of a problem there.
>
>I believe you are mistaken, George. FoxPro's somewhat counterintuitive rules give precedence to a field over a memory variable, regardless of whether it's LOCAL, PRIVATE, or PUBLIC. That is the reason I make it a habit to prefix all of my mvar references with "m.". If the current record happens to contain a field name than matches any of your memory variables, the program would produce an incorrect result, which must surely be regarded as a bug, especially in a piece of generic code like the function you chose to make your point.
>
Mike,

Yep, you're correct. I never checked before (most likely because I don't use Hungarian notation in my field naming conventions but do with my variables).