On 10/26/05, Denis Melnikov <dmo?=lnik@regent.ru <http://regent.ru>> wrote:
>
> 4GL 7.32.UC2
> Solaris 2.6
>
> 4GL must compare NULL to any not-NULL value as FALSE.



No. Except in the context of IS [NOT] NULL, NULL compared with anything,
including another null, is unknown. Since unknown is not TRUE, the IF
condition fails and the ELSE clause is taken.

And it acts this way... sometimes.
>
> Please review the following sample:
>
> >>>>>>>>>>>>>>>>>>
> DEFINE m_inv_amt DECIMAL(12,2)
>
> FUNCTION AmtUsed()
>
> IF m_inv_amt != 0 THEN
> RETURN true
> ELSE
> RETURN false
> END IF
> END FUNCTION
> <<<<<<<<<<<<<<<<<<
>
> When m_inv_amt is NULL, AmtUsed() returns FALSE at one moment,
> and TRUE at another. And the FALSE/TRUE sequence doesn't
> change from run to run.



The function should always return FALSE when given NULL as an argument. The
condition compares NULL with something, which is unknown, and unknown is not
true, so the ELSE clause should *always* be chosen when the argument is
NULL.

If you can demonstrate that iteratively calling the function with a NULL
does indeed sometimes return true and sometimes returns false, then you have
a bug. I have my doubts about that - but if you can demonstrate the problem,
you have found a bug.

Is it a known bug or a new feature?
>


Now, I notice that in fact you are not passing m_inv_amt as an argument; it
is a global variable. All of a sudden, there are other mechanisms available
for producing indeterminate behaviour. Basically, anything that could be
modifying the global variable could be triggering the problem. And
'anything' could include accidental buffer overflows in some shape or form.
How do you know that m_inv_amt is always NULL before calling the function?

This is a case where there is precious little obvious advantage to using a
global and some obvious advantages to using a parameter.

To instrument, add an simple IF statement to the function:

IF m_inv_amt IS NULL THEN DISPLAY "m_inv_amt IS NULL" ELSE DISPLAY
"m_inv_amt IS NOT NULL" END IF

Or, if you have an error log open, log the message to the log.

Also track the return values - probably by modifying the main IF clause.

Keep track of whether there are any cases where minv_amt is null and you get
a true return from the function. In all honesty, I don't expect you to find
any, but show the demo code and the log and we can see what it takes to
reproduce it.

--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/
sending to informix-list

> > Please review the following sample:
> >
> > >>>>>>>>>>>>>>>>>>
> > DEFINE m_inv_amt DECIMAL(12,2)
> >
> > FUNCTION AmtUsed()
> >
> > IF m_inv_amt != 0 THEN
> > RETURN true
> > ELSE
> > RETURN false
> > END IF
> > END FUNCTION
> > <<<<<<<<<<<<<<<<<<
> >
> > When m_inv_amt is NULL, AmtUsed() returns FALSE at one moment,
> > and TRUE at another. And the FALSE/TRUE sequence doesn't
> > change from run to run.
>
> If you can demonstrate that iteratively calling the function with a NULL
> does indeed sometimes return true and sometimes returns false, then you have
> a bug. I have my doubts about that - but if you can demonstrate the problem,
> you have found a bug.

Yes, we inserted check for NULL before the first IF. It always
DISPLAYed "NULL!" when m_inv_amt was NULL but AmtUsed() returned
TRUE/FALSE discordantly.

Thank you.

"Jonathan Leffler" <jleffler.iiug@gmail.com> wrote in message
news:1130398544.0bd479d9bce4d712e15af1668726710e@t eranews...
>
> On 10/26/05, Denis Melnikov <dmo?=lnik@regent.ru <http://regent.ru>>
> wrote:
>>
>> 4GL 7.32.UC2
>> Solaris 2.6
>>
>> 4GL must compare NULL to any not-NULL value as FALSE.
>
>
>
> No. Except in the context of IS [NOT] NULL, NULL compared with anything,
> including another null, is unknown. Since unknown is not TRUE, the IF
> condition fails and the ELSE clause is taken.

I've often found it expedient to use the construct:

if ( <logical expression(s)> )
then
else
<executable code>
end if

to help filter out NULL considerations. That is, there is no "then"
section of code. Does anyone know of a reason why this approach might be
deprecated?

Walt.

Denis Melnikov wrote:
>>>Please review the following sample:
>>>
>>>
>>>DEFINE m_inv_amt DECIMAL(12,2)
>>>
>>>FUNCTION AmtUsed()
>>>
>>>IF m_inv_amt != 0 THEN
>>>RETURN true
>>>ELSE
>>>RETURN false
>>>END IF
>>>END FUNCTION
>>><<<<<<<<<<<<<<<<<<
>>>
>>>When m_inv_amt is NULL, AmtUsed() returns FALSE at one moment,
>>>and TRUE at another. And the FALSE/TRUE sequence doesn't
>>>change from run to run.
>>
>>If you can demonstrate that iteratively calling the function with a NULL
>>does indeed sometimes return true and sometimes returns false, then you have
>>a bug. I have my doubts about that - but if you can demonstrate the problem,
>>you have found a bug.
>
>
> Yes, we inserted check for NULL before the first IF. It always
> DISPLAYed "NULL!" when m_inv_amt was NULL but AmtUsed() returned
> TRUE/FALSE discordantly.


Please show some demo code that demonstrates this behaviour on your
machine. In the absence of a reproduction, I find the claim implausible.

Can you do it in 30 lines (apart from debugging code)? Why not? What
does it take to get to a point where you can demonstrate the problem?
In what context do you use the result - or how do you know it returns
TRUE sometimes and FALSE others?

--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/

> Please show some demo code that demonstrates this behaviour on your
> machine. In the absence of a reproduction, I find the claim implausible.

Unfortunately we couldn't reproduce the behavior with a short code.
In small sandbox it behaves as documented.

> Can you do it in 30 lines (apart from debugging code)? Why not? What
> does it take to get to a point where you can demonstrate the problem?
> In what context do you use the result - or how do you know it returns
> TRUE sometimes and FALSE others?
>
> --
> Jonathan Leffler #include <disclaimer.h>
> Email: jleffler@earthlink.net, jleffler@us.ibm.com
> Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/