Home › projects › Prolint Issue Tracker › Issues

"wrong usage of ASSIGN..WHEN..statement" rule too restrictive

Thu, 2006-10-19 11:20 — dlauzon
Project:Prolint Issue Tracker
Component:Rules
Category:bug report
Priority:minor
Assigned:Unassigned
Status:won't fix
Description

(originally issued by dlauzon)

I get this notification ("wrong usage of ASSIGN..WHEN..statement") when I use something like:

---
ASSIGN
lLogical = FALSE WHEN lLogical = ?
...
.
---

Since the variable in the WHEN is on the same line, it's evident that it uses the value of the variable as it was before the ASSIGN, it's not confounding as if I had:
ASSIGN
lLogical = ?
...
lLogical = FALSE WHEN lLogical = ?
.

It's not different then with a non-ASSIGN.
e.g.
If I have:
cSomeVar = cSomeVar + "hello".
I know that the right cSomeVar is the value of cSomeVar prior to this line.


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Thu, 2006-10-19 17:09 — jurjen
jurjen's picture

agreed, but complicated

Thanks, I agree it is too restrictive, but it will be quite difficult to fix. Back to your example:

ASSIGN
   lLogical = FALSE WHEN lLogical = ?

Having lLogical on the same line is not really a good filter, see following example:

ASSIGN
   lLogical = TRUE.
ASSIGN
   lLogical = ?
   lLogical = FALSE WHEN lLogical = ?

Ok it is a bit far fetched, but I think it illustrates the complexity of the algorithm :-)


Thu, 2006-10-19 23:40 — tamhas
tamhas's picture

Intent

Being on the same line may indicate programmer intent, but it doesn't matter to the compiler.

I guess I would wonder why you want to write code like this instead of

If iLogical = ? THEN iLogical = FALSE.

which is so much clearer.


Sun, 2007-04-29 20:09 — jurjen
jurjen's picture

#1

Assigned to:Anonymous» jurjen
Status:active» won't fix

Won't fix this, because I would not know how. Sorry.


Thu, 2007-07-12 23:12 — jurjen
jurjen's picture

#2

Assigned to:jurjen» Anonymous
Status:won't fix» active

Tim Townsend wrote:

Is it really that hard? I would think it would just be:

for each variable-or-field-referenced-in-when-clause:
  if can-find(first assign-target where assign-target.assign-stmt = this-assign-stmt and
              assign-target.line-num lt this-line-num) then
    message "Houston we have a problem".

IOW, we are looking for fields that are referenced in a when clause and that are assigned a value on a previous line in the same assign statement, since that is the case where Progress' behavior is not what you might expect. Or maybe I'm missing something, it's happened before. :)


Sat, 2008-04-12 16:47 — jurjen
jurjen's picture

#3

Priority:normal» minor
Status:active» won't fix

I am not interested in fixing this, but if someone else would like to give it try...