Hello.

Compiling that code with fpc 3.2.0 gives the warning that follows:

---> if (kind tabulatorkindty(-1)) --> gives now the warning:

"msedrawtext.pas(1115,48) Warning: range check error while evaluating
constants (-1 must be between 0 and 3)"

tabulatorkindty is declared as:

---> tabulatorkindty = (tak_left,tak_right,tak_centered,tak_decimal);

So, if I understand ok, with new feature of fpc, "-1" is no more permitted.

What must be changed, a new constant should be added at end of the array, something like:

---> tabulatorkindty = (tak_left,tak_right,tak_centered,tak_decimal,
tak_none);

?

And then use:

---> if (kind tabulatorkindty(tak_none) ?

Or do you have a other idea?

Thanks.

Fre;D

-----
Many thanks ;-)

Re-hello.

What must be changed, a new constant should be added at end of the array,

Lot of work because with this the array must be initialized with tak_none.

But maybe there is now a new fpc trick to write:

--> if (kind tabulatorkindty(-1))

That will say "if kind is different of something that is not in the array tabulatorkindty"

?

PS: Imho, using "-1" was a nice trick and it is sad that it cannot more be used.

Fre;D

-----
Many thanks ;-)

Op 2020-03-11 om 11:44 schreef fredvs via fpc-pascal:

PS: Imho, using "-1" was a nice trick and it is sad that it cannot more be used.

It is a warning not an error.

Don't use tricks. Do it properly, and add a tab_None or somesuch. That should be standard practice.

Michael.

Do it properly, and add a tab_None or somesuch

If I may, I would prefer "somesuch" vs adding a new constant.

But, really, would it not possible to write the equivalent of

if (kind  tabulatorkindty(-1)) then

Maybe using in this case:

if (kind = tabulatorkindty(tak_lef)) or (kind = tabulatorkindty(tak_right)) or (kind = tabulatorkindty(tak_centered)) or (kind = tabulatorkindty(tak_decimal)) then

But I would prefer a shorter way, mainly if the array is big.

----------------------

Other question relative to Warnings:

How to do this:

tdataevent(de_afterapplyupdate)

where TDataEvent is defined as

TDataEvent = (deFieldChange, deRecordChange, deDataSetChange, deDataSetScroll, deLayoutChange, deUpdateRecord, deUpdateState, deCheckBrowseMode, dePropertyChange, deFieldListChange, deFocusControl,

    deParentScroll,deConnectChange,deReconcileError,deDisabledStateChange);

and de_afterapplyupdate was defined with:

const
...
 de_afterapplyupdate = ord(high(tdataevent))+6;

________________

Now:

---> tdataevent(de_afterapplyupdate)

Gives as Warning:

"msebufdataset.pas(4070,16) Warning: range check error while evaluating
constants (20 must be between 0 and 14)"

?

It is a warning not an error.

Yes, but it shows that something is wrong and it is time now to fix this before problems

Fre;D

-----
Many thanks ;-)

fredvs wrote

> Do it properly, and add a tab_None or somesuch If I may, I would prefer "somesuch" vs adding a new constant.

Of course you may. It is a free world.

But, really, would it not possible to write the equivalent of if (kind tabulatorkindty(-1)) then

You can write it, but the compiler will warn you that -1 can never be a correct tabulatorkindty value. And the compiler is correct in such matters.

That's the price you pay for using such "tricks". Pascal is a type-safe language, and the compiler goes to great lengths to ensure you have correct data.

Here you deliberately try to trick the compiler with an invalid data value. So, don't be surprised it complains...

You'll need to disable that particular warning if you want to use such tricks.

Michael.

Thanks Michael.

You'll need to disable that particular warning if you want to use such tricks.

For the "-1" trick, it can be easy fixed with

if (kind = tabulatorkindty(tak_lef)) or (kind = tabulatorkindty(tak_right)) or (kind = tabulatorkindty(tak_centered)) or (kind = tabulatorkindty(tak_decimal)) then

But for the other example:

--> tdataevent(de_afterapplyupdate)

Do you think it would be better to add the "extended" elements of the array like
de_afterapplyupdate:

--> de_afterapplyupdate = ord(high(tdataevent))+6;

Directly in the original tdataevent array?

By the way, huh, yes, if I am totally sure that the code is safe, I would be happy to know the code-number of those Warning and disable it.

Of course in last resort (no time to be lazy).

Fre;D

-----
Many thanks ;-)

Yes. The above is just bad programming.

Michael.

fredvs via fpc-pascal schrieb am Mi., 11.
März 2020, 11:16:

By definition an enum value can only contain the values that are listed in its declaration, anything else is an invalid value. If it contains another value then you have already made a mistake when converting some other type to the enum.

To highlight the problem: if the variable "kind" would contain -2 instead of -1 then your check would still fail.

To safely convert a non-enum value (e.g. an Integer) to an enum you should use something like this:

if (Ord(Low(TMyEnum)) <= MyInt) and (MyInt <= Ord(High(TMyEnum))) then
  MyEnum := TMyEnum(MyInt)
else
  raise Exception.Create('Curse you!');

Regards,
Sven

fredvs via fpc-pascal schrieb am Mi., 11.
März 2020, 12:51:

You are abusing enums. Either use them correctly or your code you're moving outside of what is defined for the language (aka "undefined behaviour") and thus you can expect misbehavior.

Regards,
Sven

fredvs via fpc-pascal schrieb am Mi., 11.
März 2020, 13:25:

You can find out any message id by compiling with the -vq option. The number at the front is the id of the message.

Regards,
Sven

You are abusing enums. Either use them correctly or not at all....

Hum, it is not my code but, yes I understood, I will fix it with the "good boy" way.

Thanks for all that clear, fast and with solutions answers.

Fre;D

-----
Many thanks ;-)

admittedly i don't do a lot with pascal these days but wouldn't

if (kind in tabulatorkindty) then blah

work as desired?

f (kind in tabulatorkindty) then

Yes, I like it!

But, sadly, the compiler no.

"Error: Operator is not overloaded"...

Fre;D

-----
Many thanks ;-)

that's weird... i thought that construct was standard for arrays and similar... hummm...

schrieb am Mi., 11. März 2020, 16:37:

No, what you're thinking is sets.

Regards,
Sven

Do it the other way around ee
if (integer(kind)  -1) then

which will make it always true. I see no reason for that "if" to exists at least not with out the code.

which will make it always true. I see no reason for that "if" to exists at least not with out the code.

Yes I know, it is strange.

But, like explained Roland Chastain in a other topic:

fpc <= 3.0.4 accept it, without any warnings.

It is fpc 3.2.0 that reveals it and gives warnings ( and that can be considered, imho, as a bug).

Fre;D

-----
Many thanks ;-)

( and that can be considered, imho, as a bug).

I was talking about mse code, not new behavior of warning of fpc 3.2.0.

Fre;D

-----
Many thanks ;-)

Yes, for my taste that is the way to go.

But you don't need to convert the type:

if (kind tak_none)

Nevertheless. I supposse you are reading from a format that stores tabulatorkindty value as an integer. In such cases I want to be in the safe side and control  everything of external input data:

function ToTabulartoryKind(intValue:Integer):tabulatorkindty;
begin
   if (intValue>=ord(Low(tabulatorkindty))) and (intValue<=ord(high(tabulatorkindty)))
           then Result:=tabulatorkindty(intValue)
           else Result:=tak_none;
//you could use set and IN operando but sometimes I've had problems with big integers
end;

I'd probable would add a value tk_invalid.

Hello Santiago.

I supposse you are reading from a format that stores tabulatorkindty value as an integer

No, imho it was a bug, tabulatorkindty is a enumeration array and using integer instead of a enum is not ok.

if (intValue>=ord(Low(tabulatorkindty))) and (intValue<=ord(high(tabulatorkindty))) then Result:=tabulatorkindty(intValue) else Result:=tak_none;

Yes, this is the good solution for integer value in enum or if tabulatorkindty was not initialized.

But in mse code, originally tabulatorkindty was initialized with:

---> kind := tabulatorkindty(-1); // not good coding

And now, with the last enum item added, the initialization is done with:

---> kind := tak_none;

So, imho, this can be used :

  if (kind   tak_none) then dosomething;

What do you think?

Fre;D

-----
Many thanks ;-)

fredvs wrote

Hello Santiago. What do you think?

IMHO

---> kind := tabulatorkindty(-1);

makes no sense.

Why should you initialize a variable on purpose to an out-of-range value? If you need a sentinel value, or a non valid value, create one, like NIL for pointers or NaN for numbers or Nul in variants

kind := tak_none

Yeah. That is the way.

---> kind := tabulatorkindty(-1); makes no sense.

Yes of course, it is the reason of that topic.
fpc 3.0.4 does not give any warning for this (strange...).

And it is fpc 3.2.0 that reveals that bug, giving a warning for that.

Note that fpc 3.2.0 is still tolerant, with a strict compiler, the application should raise a exception when calling this:

kind := tabulatorkindty(-1);

But that is a other story. (For me, I am happy with a tolerant fpc that gives warnings for "bad boy" code).

kind := tak_none Yeah. That is the way.

Yes, thanks to this topic, imho, all is clear and fixed now.

Thanks to all of you.

Fre;D

-----
Many thanks ;-)

You should define

type Set_Of_tabulatorkindty= set of  tabulatorkindty;
const
    
AlltabValues:Set_Of_tabulatorkindty=[low(tabulatorkindty)..high(tabulatorkindty)];
then
if (kind in AlltabValues) then

is right

Nevertheless, "kind" is of type "tabulatorkindty", so it is always in the range. The only case when it is not in the range is if it is uninitialized. And in Pascal, fields of objects are initialized (nil, or zero, or empty string etc), but uninitilized variables don't contain uninitialized values, contain garbage, dangerous garbage. So, in pascal,  you don't test if a variable contains an uninitiliazed value, you initialize it before referring the variable.

And before assigning a value, you verify it is in the range.

type Set_Of_tabulatorkindty= set of tabulatorkindty;

Yes, it was proposed too.
It has the advantage to fix the tabulatorkindty(-1) bug without adding a new item-enum.

But the disadvantage is: lot of change in code, maybe more than simply adding "tak_nil" at end of the enum-array.
And initialize it with "kind := tak_nil".

It is not yet decided in mse-org forum what we will use (+- 50 similar cases).
I vote for keeping type enum + adding at end "tak_nil" in array + initialize "kind := tak_nil".

Gracias Santiago.

Fre;D

-----
Many thanks ;-)

Apologies if already suggested as there are a lot of messages in this thread - but would this meet your needs:

tabulatorkindty = (tak_none=-1,tak_left,tak_right,tak_centered,tak_decimal);

This ensures -1 is a valid enum value so tabulatorkindty(-1) should not raise a warning (I’ve not tried it as still using 3.0.4).

Regards,

as there are a lot of messages in this thread

Yes, it is an epidemic, and it has already muted there:

http://free-pascal-general.1045716.n5.nabble.com/Re-New-Warnings-with-fpc-gt-3-2-0-fredvs-td5735027.html

You will see with last message that all is not so simple:

Initialization of a enum-var is set it to 0.

Then with tabulatorkindty =
(tak_none=-1,tak_left,tak_right,tak_centered,tak_decimal);
kind will be initialized with 0 and not with -1;

Hum, the enum-saga is not yet closed.

Fre;D

-----
Many thanks ;-)