#661 Compiler error messages inconsistencies

[Nikos Papageorgiou]

I might have found some inconsistenties. If some of these are expected, please write so in a comment. I am learning COBOL.

Here they are:

---

:::cobolfree
01 foo pic a(2) value '""'       *> gives warning
01 foo pic a(2) value quotes     *> doesn't.

I'd expect them to both have the same behaviour

---

:::cobolfree
 01 foo pic a(2) value zero        *> gives error
 01 foo1 pic a(2) value 0 0        *> gives warning.

I'd expect them to both have the same behaviour

---

:::cobolfree
01 foo pic 9(2) value all 2      *> gives error
add all 2 to foo                 *> doesn't.
01 foo pic 9(2) value 22         *> doesn't.

I'd expect them to all have the same behaviour

---

:::cobolfree
01 foo pic 9(2)v9(2) value all 11        *> gives error
01 foo pic 9(2)v9(2) value all '11'      *> doesn't.

I'd expect them to both have the same behaviour

---

:::cobolfree
1 boo.
      2 boo2 pic 9(2)v9(2) value all '#'.

       display boo.    *> ####
       display boo2.   *> ##.00

I would expect both items to be consistent on whether the decimal part has been populated or no.

---

:::cobolfree
if person is equal to 0 display "#"        *> Compiles.
if person is equal to to 0 display "#"     *> Compiles!
if person is equal to to to 0 display "#"  *> Compilation error

---

:::cobolfree
multiply "foo" by "foo" *> Error not numetic type.

Same for all math operations except of:

:::cobolfree
divide "foo" by "foo"   *> Not error.

I'd expect all math operations to either work or not work with non numeric items/literals.

[Vincent (Bryan) Coen]

Starting at the top :

You used simgle quotes and default (unless changed) uses double so hence the error.

1. Using zero can only be used on a numeric field and AA is alpha only thats A-Z, A-z.
2. technically the next one 0 0 should have come up with a error so a warning is a bonus :)
3. All 2 , hmm That does not supprise me but I would have used 22.
4. issue with 11 same as above.
5. The last one if you had turned on all checks it would have given you an error as value is wrong BUT the compiler should have rejected it (error) so this look very much like an error so the questions is

What version of the compiler are you using and what platform ?

[Nikos Papageorgiou]

Hi, I use this image: hurriedreformist/gnucobol:3.1-builder

Regarding the answers, I cant say I understood them unfortunately... I do not mean to be pedantic, but I would really love an explanation so as to know how to proceed with the IDE syntax highlighting in these cases.

You used single quotes and default (unless changed) uses double so hence the error.

value quotes fills item with "", value '""' gives warning, although string literals can be wrapped either in " or '. So one would expect '""' to be no differnet than 'foo'. In short, is '""' not an OK string literal?

Using zero can only be used on a numeric field and AA is alpha only thats A-Z, A-z.

Yes, it is alphabetic, so value 00 correctly gives a warning, in the same way that all "non-matching" initial values give warnings (for example value "foo" to a numeric). So it is inconistent that only value zero gives an error.

All 2 , hmm That does not supprise me but I would have used 22.

I agree, it is weird to write that, but in case someone does, why does value all 2 give an error and value 22 doesnt? Isnt a literal that got constructed by a figurative constant (all 2) the same as the "normal" literal value 22?

issue with 11 same as above.

I am not sure it is the same issue, let me try to phrase that better: It is unclear to me what is wrong with filling a decimal numeric with all 11, while it is OK to fill it with all "11"

Also the second and third from the bottom (boo2 pic 9(2)v9(2) value all '#' and if person is equal to to 0 display) did not get a reply.

Thanks :)

[Vincent (Bryan) Coen]

Simply put -
Please read the Programmers Guide manual regarding data fields and the rules for moving data.

But in a nut shell -
You must only use numbers when moving to a numeric field.
You must only use alphabetic characters when moving to a Alpha field (A).

If the field might hold any thing other than A to Z or a to z then set the field type to X.

When using numeric field (99) etc, you can only use a number 0 to 9, - (for minus), " . " (period/full stop to indicate a edited decimal point).

Any thing else read the rules for moving data.
You can also read any good book on Cobol.

[Nikos Papageorgiou]

It seems like we do not speak of the same things.

I am aware of these basic things. I do not contest them.

What I write is that for some cases the behaviour of the compiler is inconsistent. It is surprising. It treats seemingly same scenarios as different.

For example, the point:
01 foo pic a(2) value zero gives error
01 foo1 pic a(2) value 0 0 gives warning.
I d expect them to both have the same behaviour

is not contesting any of the rules about what data can be assigned to what type. Thats not the point. The point is that it reveals an inconsintency. Same as all the other issues.

You say

When using numeric field (99) etc, you can only use a number 0 to 9, - (for minus), " . " (period/full stop to indicate a edited decimal point).

I agree. That is why one of the things I report is that:
01 foo pic 9(2)v9(2) value all 11 gives error
01 foo pic 9(2)v9(2) value all '11' doesn't.
I d expect them to both have the same behaviour

And so on. I am, pointing out inconsistenties. I am pointing out cases the compiler behaves surprisingly considering the rules we all know and that you just wrote. It contradicts them.

[Vincent (Bryan) Coen]

On 17/07/2020 13:27, Nikos Papageorgiou wrote:

It seems like we do not speak of the same things.

I am aware of these basic things. I do not constest them.

What I write is that for some cases the behaviour of the compiler is
inconsistent. It does NOT make sense. It is surprising. It treats
seemingly same scenarios as different.

For example, the point:
01 foo pic a(2) value zero gives error
01 foo1 pic a(2) value 0 0 gives warning.
I d expect them to both have the same behaviour

is not constesting any of the rules about what data can be assigned to
what type.Thats not the point. The point is that it reveals an
incisinsency. Same as all the other issues.

Yes agreed  both should produce an error message and not a warning or be
ignored.

[Edward Hart]

Thank you for the report. Some of the inconsistencies are problems with the compiler and some are just idiosyncracies of COBOL.

1. QUOTE and '""'. This is a bug, using QUOTE should give a warning.
2. ZERO and 0. This is a bug; since 0 is accepted with a warning, so should ZERO.
3. Inconsistent display with invalid numeric data. This is a valid instance of undefined behaviour. By default, the option pretty-display is enabled and this clearly leads to odd results with invalid data. Compiling with -fno-pretty-display gives consistent output.
4. EQUAL TO TO being accepted. This is a bug, likely needing a fix similar to [bugs:#663].
5. DIVIDE "foo" BY "foo". I can't reproduce this. I either get a syntax error or a message saying "foo" is not a numeric value.