P.S. 4GL C compiler.

I'm not quite ready to call it either.  Just out of curiosity, what happens
if you write:
     IF m_inv_amt = 0 THEN

Do you get a more consistent result?

I ask because of the comments in the I4GL Concepts and Use Guide.  Null
values are discussed and the manual does tell you (on page 8-27 of manual
Part No. 000-8875) that "If you compare a null value to anything else, the
result is NULL.  Is 'A' equal to unknown?  The only answer can be unknown.
Thus every comparison expression has not two but three possible results:
TRUE, FALSE, and unknown, or NULL."  The manual goes on to tell you that
NULL (unknown) will be treated as FALSE when evaluated by statements such as
IF and WHILE.  My question comes from the fact that you are not testing to
see if the value of m_inv_amt is equal to zero, but rather, is m_inv_amt not
equal to zero.  It is the 'not' part of the comparison that has my interest.

It has been a while since I've had the pleasure of working with pure I4GL,
but we never took the result of a possible NULL for granted.  If the
possibility for a NULL value exists, I would suggest you check specifically
for NULL.  In any case, I'll be interested to see if you get other responses
to this.

--
June Hunt

You must of course realize that the number 0 is NOT equal to NULL! NULL is
not a value but a state (more or less saying 'I am not yet defined'). So it
is entirely possible that when equating to the number zero yu get different
result especialy when comparing to TRUE or FALSE wich or equally NOT the
same as NULL. True and False are constant with the respective value of the
numbers 1 and zero.

------------------------------------------------------------------------
R.A. Reissaus
Risdi, Amsterdam, the Netherlands
Ibm/Informix Consultants
Telefoon: +31(0)20 6331140    : Phone
Mobiel  : +31(0)6 51185352    : Mobile
E-mail  : r.a.reissaus@risdi.com
Website : www.risdi.com
------------------------------------------------------------------------
Disclaimer:
`Externe E-Mail wordt door partijen niet gebruikt voor het aangaan van
verplichtingen`

`Any e-mail messages from sending parties named in this e-mail are given
in good faith but shall not be binding nor shall they be construed as
constituting any obligation on the part of any such party.`
------------------------------------------------------------------------

sending to informix-list

Denis Melnikov said:

Oh? I always thought you had to explicitly check for nulls.

This has been a know issue with decision statements in 4gl as far as I
can remember back in to the early 90's.
If the variable has any possibility of being null then it should be
checked as part of the condition first:

IF m_inv_amt is NULL or m_inv_amt != 0 then
   RETURN true
ELSE
   RETURN false
END IF

unless you want it the other way then
IF m_inv_amt is NOT NULL and m_inv_amt != 0 then
   RETURN true
ELSE
   RETURN false
END IF

sending to informix-list

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.

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

-----Original Message-----
From: owner-informix-list@iiug.org [mailto:owner-informix-list@iiug.org]
On Behalf Of Obnoxio The Clown
Sent: 26 October 2005 05:58 PM
To: Denis Melnikov
Cc: informix-list@iiug.org
Subject: Re: 4GL compares NULL differently

Denis Melnikov said:

This is the way I understand it as well ...
sending to informix-list

Look at Jonathan Leffler answer. Also bare in mind that in compiled 4GL
the variables AFAIK aren't guaranteed to be null before initialization...

I recall hitting a bug with some IF statements and null values but it
had to do with datetime values.

Regards.

Dear Denis,

Given the URL quoted by our Scottish Poet:

http://www-1.ibm.com/support/docview.wss?rs=681&context=SSVT2J&context=SSCVRDE&c
ontext=SSCVRDD&context=SSCVRDJ&context=SSCVRDM&dc=DB520&dc=D600&dc=DB530&dc=D700
&dc=DB500&dc=DB540&dc=DB510&dc=DB550&q1=4GL+NULL&uid=swg21218388&loc=en_US&cs=ut
f-8&lang=en

aka: *http://tinyurl.com/dsq86

*which acknowledges a bug in this area, I withdraw my scepticism. (I have
bones to pick with the wording of the referenced document, but that's one
other story; I am also moderately amazed that people managed to break this
behaviour in I4GL, that that's a second other story.)

--
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