Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Hello Fred! For this: msedatalist.pas(891,18) Warning: range check error while evaluating constants (-193 must be between 0 and 255) I would try to replace "1" with "byte(1)". const foldhiddenbit = 7; foldhiddenmask = byte(1) shl foldhiddenbit; // < currentfoldhiddenbit = 6; currentfoldhiddenmask = byte(1) shl currentfoldhiddenbit; // < foldlevelmask = byte(not (foldhiddenmask or currentfoldhiddenmask)); Not tested! Regards. Roland -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Hello Roland. Doing this: const foldhiddenbit = 7; foldhiddenmask = byte(1) shl foldhiddenbit; currentfoldhiddenbit = 6; currentfoldhiddenmask = byte(1) shl currentfoldhiddenbit; foldlevelmask = byte(not (foldhiddenmask or currentfoldhiddenmask)); foldissumbit = 0; foldissummask = $01; rowstatemask = $7f; Makes the compiler happy but the warning is still there and point to : ---> foldlevelmask = byte(not (foldhiddenmask or currentfoldhiddenmask)); msedatalist.pas(891,18) Warning: range check error while evaluating constants (-193 must be between 0 and 255) ;-( Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Hello fredvs, you wrote on Tue, 10 Mar 2020 12:52:22 -0700 (MST): > Hello Roland. > > Doing this: > > const > foldhiddenbit = 7; > foldhiddenmask = byte(1) shl foldhiddenbit; > currentfoldhiddenbit = 6; > currentfoldhiddenmask = byte(1) shl currentfoldhiddenbit; > foldlevelmask = byte(not (foldhiddenmask or currentfoldhiddenmask)); > foldissumbit = 0; > foldissummask = $01; > rowstatemask = $7f; > > Makes the compiler happy but the warning is still there and point to : > > ---> foldlevelmask = byte(not (foldhiddenmask or > currentfoldhiddenmask)); > > msedatalist.pas(891,18) Warning: range check error while evaluating > constants (-193 must be between 0 and 255) Does that new fpc version implement (and differentiate between) _signed_ and _unsigned_ byte size values now? This looks a whole lot like similar warnings issued by C compilers when you mix signed and unsigned "char"s. This might even apply to subranges of bytes, like with C with bit field values, which can also have signedness... (In shoert, a mess.) -- -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Hello Seighard. Here a example maybe more clear: msedrawtext.pas(1115,48) Warning: range check error while evaluating constants (-1 must be between 0 and 3) This warning point to: ---> if (kind <> tabulatorkindty(-1)) and 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 as default. What do you think, must a new constant be added in the array, this for the default value, something like: ---> tabulatorkindty = (tak_left,tak_right,tak_centered,tak_decimal, tak_none); ? And then initialize it with: ---> if (kind <> tabulatorkindty(tak_none) ? If so, maybe **lot of** work because Martin did use "-1" in many case. Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Hello. I did create a new topic about this in fpc mailing-list: http://free-pascal-general.1045716.n5.nabble.com/New-Warnings-with-fpc-gt-3-2-0-td5734996.html Maybe some light from there... Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Hi fred
i don't know why martin has disable some warnings while ago and not fixing it
you may have seen this in every msegui unit :
{$if fpc_fullversion >= 030100}
{$warn 5089 off}
{$warn 5090 off}
{$warn 5093 off}
{$warn 6058 off}
{$endif}
so i think this list should be extended
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Hello Code DZ and all others.
> so i think this list should be extended
Maybe.
But after the conversation in:
http://free-pascal-general.1045716.n5.nabble.com/New-Warnings-with-fpc-gt-3-2-0-td5734996.html
Maybe also some code should be fixed with the "good boy" way.
So the question is:
Should we add some {$warn xxx off} or fix original mse code with the "good
boy" way?
Fre;D
--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
For me, I don't understand "tabulatorkindty(-1)". I don't understand why FPC
3.0.4 accept it without even a warning.
With FPC 3.0.4, the following code compiles without warning and works:
type
tabulatorkindty = (ak_left, tak_right, tak_centered, tak_decimal);
var
kind: tabulatorkindty;
begin
kind := tabulatorkindty(-1);
if kind = tabulatorkindty(-1) then
WriteLn('hello');
end.
Maybe we could make the following modification?
type
tabulatorkindty = (tak_nil = -1, tak_left, tak_right, tak_centered,
tak_decimal);
--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Hello Roland. Sorry, I did commit some change following the advises of fpc-mailing list: https://github.com/mse-org/mseide-msegui/commit/ Of course it can be changed but is is to make advance the "schmilblick". It takes the same idea as yours, the only thing changed is that tak_nil is placed at end of the enum. This because sometime ord() is used and so the order of each enum is maintained. And in place to use "-1" "tak_nil" is used: kind := tabulatorkindty(tak_nil); // this to initialize if kind = tabulatorkindty(tak_nil) then // this in code And this for mainly all warnings. I left, for the sport, 2 warnings, feel free the fix it ! Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Hello Fred! Thank you for your answer, and for the schmilblick. I don't know which order is better, but I am sure that "tabulatorkindty(tak_nil)" can be replaced with "tak_nil". Regards. Roland -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Hello Roland. > but I am sure that"tabulatorkindty(tak_nil)" can be replaced with > "tak_nil". ;-) OK, done in last commit b7be824. Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Hello fredvs,
you wrote on Wed, 11 Mar 2020 02:22:07 -0700 (MST):
> Here a example maybe more clear:
Let's see...
> msedrawtext.pas(1115,48) Warning: range check error while evaluating
> constants (-1 must be between 0 and 3)
>
> This warning point to:
>
> ---> if (kind <> tabulatorkindty(-1))
>
> and tabulatorkindty is declared as:
>
> ---> tabulatorkindty = (tak_left,tak_right,tak_centered,tak_decimal);
So the type of the cast is an enumeration type, an ordinal value, that,
basically, will not be negative usually. It might even be regarded as not
having a value in the first place, but just specifying an arbitrary
ordering (hence the name "ordinal").
> So, if I understand ok, with new feature of fpc, "-1" is no more permitted
> as default.
This is not a "new feature", but a design principle.
It might be seen as a "new feature" that the use of an out-of-bounds value
for an enumeration mamber is flagged as a warning. (If it's not appearing
simply because in this specific code area the pertinent warning is for some
reason no longer disabled.)
> What do you think, must a new constant be added in the array, this for the
> default value, something like:
>
> ---> tabulatorkindty = (tak_left,tak_right,tak_centered,tak_decimal,
> tak_none);
There's a simple way to resolve this: You got to throw good Pascal design
principles over bord and introduce mainly, let's say, type indifferent C
usage. In this case, you ought to apply the "assigned enumeration" type
"extension" of fpc, which allows you to _define_ enumeration menmber's
values explicitely instead of enumerating them sequentially.
(fpc reference manual, Types - Base types - Ordinal types - Enumeration
types.)
> ?
Yes, that is plain type ignorant C style.
> And then initialize it with:
>
> ---> if (kind <> tabulatorkindty(tak_none) ?
Maybe, the name of this queer member ist unimportant, you may use this
name, if only you _assign_ it the value you want it to represent. I.e. you
had to define the extended enumeration like this:
tabulatorkindty = (tak_none:= -1, tak_left{:= 0, but that's so anyway},
tak_right, tak_centered,tak_decimal);
That way, everything keeps its well known order and value, and the new
value is added as a _legal_ member of the sequence, even with the
"illegally" added extraneous value used in the statement causing the
warning. This can even be written without the cast then, because it now
references a _legal_ member of the type:
if (kind <> tak_none) ...
> If so, maybe **lot of** work because Martin did use "-1" in many case.
He seems not having been aware of this extension to the enumeration type,
then. (It's part of fpc's definition since at least version 2.1!)
Doing it this way, the amount of required work should not be so enormous.
Only the type definitions where such constructs are used need to be fixed.
(You might even decide to keep the casts from -1 to save on modifications.)
BTW, I'd suggest to use the word "illegal" (or maybe "undefined") as the
base name for these extraneous additional enumeration members, like, for
the example above:
tabulatorkindty = (tak_illegal:= -1, tak_left, tak_right,
tak_centered,tak_decimal);
resulting in
if (kind <> tak_illegal) ...
for the example use, which might even better represent its intention, too.
--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Hello Sieghard **Many thanks** for all that clear explanation. > BTW, I'd suggest to use the word "illegal" Ha, ok, in last commit I did use "none" or "nil", I will change it asap. > tabulatorkindty = (tak_illegal:= -1, tak_left, tak_right, > tak_centered,tak_decimal); Like explained to Roland, in last commits I did place "tak_illegal" as last member of the enum. Take this original example: scrollbarareaty = (sbbu_down,sbbu_move,sbbu_up,sba_start,sba_end,sba_clicked,sba_none) ... const scrollbarclicked = ord(sba_end) + 1; You may see that Martin did add a "extended" value for scrollbarareaty: scrollbarclicked. This is not "catholic" so I did add 2 members in the enum: sba_clicked,sba_none and adapt the code for it: scrollbarareaty = (sbbu_down,sbbu_move,sbbu_up,sba_start,sba_end,sba_clicked,sba_none); In that case the order is important, because at a moment, this is called in original code: bu1:= low(scrollbarareaty) to high(scrollbarareaty) So it was changed with: bu1:= low(scrollbarareaty) to high(scrollbarareaty)-2 Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Oops, in previous mail: >Take this original example: >scrollbarareaty = >(sbbu_down,sbbu_move,sbbu_up,sba_start,sba_end,sba_clicked,sba_none) Please read (forget sba_none): Take this original example: scrollbarareaty = (sbbu_down,sbbu_move,sbbu_up,sba_start,sba_end,sba_clicked) Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Re-ooops. In previous mail: >Take this original example: >scrollbarareaty = >(sbbu_down,sbbu_move,sbbu_up,sba_start,sba_end,sba_clicked,sba_none) Please read (forget sba_clicked,sba_none): Take this original example: scrollbarareaty = (sbbu_down,sbbu_move,sbbu_up,sba_start,sba_end) Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Sorry to monopolize. But re-re ooops. In previous mail, when I did try to explain why I opted to place the new "sba_none" at end, I did choose a wrong example. Of course the order of enum has no influence on bu1:= low(scrollbarareaty) to high(scrollbarareaty). But, (trust me), it was more easy if "sba_none" was placed at end than at begin of enum. Sorry I dont find now the code that demonstrate that it was easier if "sba_none" was placed at end. Of course "sba_none" placed at begin works also, but more code is needed for this. But if you really prefer "sba_none" placed at first place, I will change it with pleasure (asap). Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Hello everybody! We could also make something like this: type TOption = (optNil = -1, optOne, optTwo, optThree); TValidOption = optOne..optThree; var o: TOption; begin o := optNil; for o := Low(TValidOption) to High(TValidOption) do ; end. Regards. Roland -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
>Sorry I dont find now the code that demonstrate that it was easier if > "sba_none" was placed at end. OK, I found it. This was a original code (see scrollbarclicked new added constant): type scrollbarareaty = (sbbu_down,sbbu_move,sbbu_up,sba_start,sba_end); const scrollbarclicked = ord(sba_end) + 1; // not a "good boy" code. I did change code adding 2 new items in scrollbarareaty (scrollbarclicked =sba_clicked) and sba_none: And remove const scrollbarclicked (that becomes sba_clicked in the enum array). ---> scrollbarareaty = (sbbu_down,sbbu_move,sbbu_up,sba_start,sba_end,sba_clicked,sba_none); // sba_none was placed at end because, later in code: ---> for ar1:= low(scrollbarareaty) to high(scrollbarareaty) do begin // was changed with (due to 2 last added items): ---> for ar1:= low(scrollbarareaty) to sba_end do begin Of course you could add sba_none in first position and do: ---> for ar1:= sbbu_down to sba_end do begin So, I wait for the vote for the code you want. Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
> scrollbarclicked = ord(sba_end) + 1; // not a "good boy" code. Imho, it is not a "good boy" code because later there is: ---> if kind = scrollbarareaty(scrollbarclicked) then // this gives a warning with fpc 3.2.0, not fpc 3.0.4. OK, I stop before to become (stay) completely crazy. Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
On 10/03/2020 10:10 am, fredvs wrote: > "msedatalist.pas(891,18) Warning: range check error while evaluating > constants (-193 must be between 0 and 255)" That means the constant (or variable) had the value -193, but used in a data type that only supports values between 0 and 255. That could have serious side effects in the behaviour of [some] code logic if not fixed. Regards, Graeme ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
> if not fixed. Yes, as written in a previous mail, I let, for the sport, 2 Warnings to fix. This is the first, the second is not bad too. ;-) Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Hello fredvs, you wrote on Thu, 12 Mar 2020 02:22:15 -0700 (MST): > > BTW, I'd suggest to use the word "illegal" > > Ha, ok, in last commit I did use "none" or "nil", I will change it asap. The name has no function, so I think it should be chosen on intended function. If the member is used just to satisfy the syntax, "nil" or "none" are alright. If it is used to signify a state outside the normal range or even not normally allowable, "undefined" or even "illegal" seem appropriate to me, because those names express the meaning "literally". > > tabulatorkindty = (tak_illegal:= -1, tak_left, tak_right, > > tak_centered,tak_decimal); From your examples of Martin's use, and the fact that he expressly used a value outside the bounds of the enumeration, I derived the impression that, indeed, this special value was meant to signify some illegal state. That's why I suggested "_illegal" here. > Like explained to Roland, in last commits I did place "tak_illegal" as > last member of the enum. Commonly, the placement of the members has no significance as long as they're not used for enumeration, as in a "for" or "while" statement, where a variable of the type is in- or decremented through some defined range. If that is done, you have to be aware of the specific _sequence_ of the members, and that's where their placement will be of importance. > Take this original example: > > scrollbarareaty = > (sbbu_down,sbbu_move,sbbu_up,sba_start,sba_end,sba_clicked,sba_none) > ... > const > scrollbarclicked = ord(sba_end) + 1; > > You may see that Martin did add a "extended" value for scrollbarareaty: > scrollbarclicked. Not exactly - he defined an _integer_ constant having the value given by the _position_ of "tba_end" in its enumeration, plus one. > This is not "catholic" so I did add 2 members in the enum: > sba_clicked,sba_none and adapt the code for it: > > scrollbarareaty = > (sbbu_down,sbbu_move,sbbu_up,sba_start,sba_end,sba_clicked,sba_none); > > In that case the order is important, because at a moment, this is called > in original code: > > bu1:= low(scrollbarareaty) to high(scrollbarareaty) Yes, that's exactly the case where it is important, the enumeration is scanned sequentially, enumerated, that is. > So it was changed with: > > bu1:= low(scrollbarareaty) to high(scrollbarareaty)-2 You mean, it was changed _from_ this expression? Yes, your way is the more elegant one, and regarding the constant definition, it may well be what was really intended, but because of some condition not immediately done cleanly. you wrote on Thu, 12 Mar 2020 03:08:01 -0700 (MST): ... > Of course the order of enum has no influence on bu1:= low(scrollbarareaty) > to high(scrollbarareaty). Not on the bounds, but on the sequence of members within, which _is_ "the order of enum". > But, (trust me), it was more easy if "sba_none" was placed at end than at > begin of enum. And it was quite correct for this purpose. ... > Of course "sba_none" placed at begin works also, but more code is needed > for this. Sure, that way, you change the main property of the enumeration, its _order_. > But if you really prefer "sba_none" placed at first place, I will change > it with pleasure (asap). No, as that's not a matter of "preference" here, but a matter of _use_. And that's clearly demonstrated by what you wrote later: you wrote on Thu, 12 Mar 2020 10:29:20 -0700 (MST): > > scrollbarclicked = ord(sba_end) + 1; // not a "good boy" code. Right. > Imho, it is not a "good boy" code because later there is: > > ---> if kind = scrollbarareaty(scrollbarclicked) then // this gives a > warning with fpc 3.2.0, not fpc 3.0.4. Yes, this triggered the "out of bounds" warning for enumeration values that seems to have been added to the later version of fpc. > OK, I stop before to become (stay) completely crazy. Why could that drive someone crazy, if he thought somewhat about the purpose and construction of enumerations? You probabely won't get crazy, e.g., if someone tells you he wants to get to the third seat in a theater seat row that's number from 124 to 188 - you probabely can tell him immediately he should take seat number 126, don't you? -- -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Hello Sieghard. > Why could that drive someone crazy, ? Huh, I was talking about all the possibilities that enum gives and the difficult task to choose the best one. The "new illegal-nil-none item" in the enum can be placed everywhere but imho at end will give shorter code and so less chance to introduce new bug. This when code like this is used: --> for ar1:= low(scrollbarareaty) to high(scrollbarareaty) do begin // was changed with (due to 2 last added items): ---> for ar1:= low(scrollbarareaty) to sba_end do begin And there is also the proposition of Roland that is great: type TOption = (optNil = -1, optOne, optTwo, optThree); TValidOption = optOne..optThree; var o: TOption; begin o := optNil; for o := Low(TValidOption) to High(TValidOption) do _ You see, not easy to decide what code to choose. Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Hello fredvs,
you wrote on Thu, 12 Mar 2020 18:02:03 -0700 (MST):
> > Why could that drive someone crazy, ?
>
> Huh, I was talking about all the possibilities that enum gives and the
> difficult task to choose the best one.
An enum (C-speak) aka enumeration is just that: An enumeration of
identifiers that may be used as selectors for arbitrary things.
In contrast to sets, though, the identifiers have a defined _order_ and
so they may be represented by a sequence of numerals of the same order.
> The "new illegal-nil-none item" in the enum can be placed everywhere but
Yes. Any member can, as long as its position in the sequence is not used.
> imho at end will give shorter code and so less chance to introduce new
> bug.
Not so if there's no use of the position of any member.
(Yes, then it's also possible to use a set.)
> This when code like this is used:
>
> --> for ar1:= low(scrollbarareaty) to high(scrollbarareaty) do begin
_This_ code _does_ make use of the _order_ and the members' positions in
the sequence, thus it _is_ sensitive to the ordering of the members and
_will_ be affected by insertions or removals of members, at least in the
range used.
> // was changed with (due to 2 last added items):
>
> ---> for ar1:= low(scrollbarareaty) to sba_end do begin
If the last 2 members shall not be used here, the modification is required.
The expression "high (scrollbarareaty)" is equvalent to the last member of
the type, and "low (...)" to its first member, of course.
>
>
> And there is also the proposition of Roland that is great:
>
> type
> TOption = (optNil = -1, optOne, optTwo, optThree);
> TValidOption = optOne..optThree;
That's just a use of the (C-derived) extension of enumerations by fpc to
allow "assigned" members, i.e. members given an explicit value.
Preceding members start counting from 0 (there are none above), following
members count on with the next available value.
CAUTION: THERE IS NO PROVISION TO AVOID DUPLICATE VALUES!
But duplicate values will probabely, hopefully, produce a compiler error
or at least a warning.
And there is NO PROVISION TO AVOID HOLES in the sequence of values.
Holes are expressly allowed, even:
TYPE weird = (we_2:= 2, we_5:= 5, we_next, we_more, we_decade:= 20);
is perfectly valid, but using it as a counting sequence, e.g. in a "FOR"
statement like this:
FOR we:= low (weird) TO high (weird) DO Write (ord (we), ': ', we);
WILL NOT WORK. It throws a runtime error and aborts the program.
Why? Because the type member sequence IS NOT (numerically) COMPLETE, as
would be required by the "FOR" statement counter. It contains holes, the
counter will try to produce the value of members that simply DO NOT EXIST.
And fails.
> var
> o: TOption;
>
> begin
> o := optNil;
> for o := Low(TValidOption) to High(TValidOption) do
But if done correctly, this will work correctly, of course.
BTW, I'm NOT using the latest development version of fpc, I'm using
"Free Pascal Compiler version 3.0.4 [2020/03/06] for x86_64".
(Recently upgraded from version 2.6.4.)
> _
>
> You see, not easy to decide what code to choose.
Welll...
It's even _very_ easy to decide what code to choose:
choose _correct code_! Provably and proven correct code.
Yes, that's not that easily produced, it may even be a lot of work.
As to the use of enumerations, you may play a bit with the following
program, which is, BTW, _not_ fully correct. Find out why and how to make
it behave:
PROGRAM weird;
TYPE weird = (we_2:= 2, we_5:= 5, we_next, we_more, we_decade:= 20);
VAR we: weird; wn: integer;
BEGIN
WriteLn ('low: ', low (weird), ', value: ', ord (low (weird)),
'; high: ', high (weird), ', value: ', ord (high (weird)));
FOR wn:= ord (low (weird)) TO ord (high (weird)) DO Write (wn, ' ');
WriteLn;
FOR we:= low (weird) TO high (weird) DO Write (we, ': ', ord (we));
WriteLn;
END.
Have a lot of fun!
--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Hello Sieghard.
> Have a lot of fun!
With your code I get this:
$ /home/fred/weird/weirdtest
low: we_2, value: 2; high: we_decade, value: 20
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
we_2: 2Runtime error 107 at $00401293
$00401293
$0040104F
___
Would you be happy with this:?
PROGRAM weirdtest;
TYPE weird = (we_2:= 2, we_5:= 5, we_next, we_more, we_decade:= 20);
const
weirdorder: Array[1..5] of weird=(we_2,we_5,we_next, we_more,
we_decade);
VAR we: weird; wn: integer;
BEGIN
WriteLn ('low: ', low (weird), ', value: ', ord (low (weird)),
'; high: ', high (weird), ', value: ', ord (high (weird)));
FOR wn:= ord (low (weird)) TO ord (high (weird)) DO Write (wn, ' ');
WriteLn;
we:=Low(weird);
for we in weirdorder
DO Write (we, ': ', ord (we));
WriteLn;
END.
___
Gives as result:
$ /home/fred/weird/weirdtest
low: we_2, value: 2; high: we_decade, value: 20
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
we_2: 2 we_5: 5 we_next: 6 we_more: 7 we_decade: 20
Fre;D
--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Hello. An interesting post here: http://free-pascal-general.1045716.n5.nabble.com/Re-New-Warnings-with-fpc-gt-3-2-0-fredvs-td5735027.html To resume, a enum variable is initialized with the first item of the enum list. Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
> To resume, a enum variable is initialized with the first item of the enum. Fake news, this is true: To resume, a enum variable is initialized with 0. Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Hello fredvs, you wrote on Fri, 13 Mar 2020 17:19:37 -0700 (MST): > With your code I get this: > > $ /home/fred/weird/weirdtest > > low: we_2, value: 2; high: we_decade, value: 20 > 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 > we_2: 2Runtime error 107 at $00401293 > $00401293 > $0040104F > > ___ > > Would you be happy with this:? Yes, that's the expected result. > Would you be happy with this:? > PROGRAM weirdtest; ... > TYPE weird = (we_2:= 2, we_5:= 5, we_next, we_more, we_decade:= 20); > > const > weirdorder: Array[1..5] of weird=(we_2,we_5,we_next, we_more, > we_decade); ... > we:=Low(weird); > for we in weirdorder ... Except from multiple non-Pascal syntax elements, this is correct. Although the initialization of "we" before the second "FOR" loop is superfluous, it does no harm. The FOR loop itself uses yet another fpc extension to the Pascal syntax, the "in" operator applied to the elements of an array. The "in" operator was originally only defined for sets, as it does not imply any ordering, as is the case with sets in general. But it can be found in many programming languages for other data types as well (even Linux's bash implements it), and regarding the fact that any computer (memory) resident data structure has, due to the one dimensional structure of memory addresses, a "natural" or implied order, this kind of use commonly works as naively expected. > Gives as result: > > $ /home/fred/weird/weirdtest > > low: we_2, value: 2; high: we_decade, value: 20 > 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 > we_2: 2 we_5: 5 we_next: 6 we_more: 7 we_decade: 20 ^ ^ ^ ^ Not quite, it does not produce the spaces marked above... But my point - that you addressed by introducing _yet another_ data structure, the "weirdorder" array - was that there is _no_ possibility in fpc to access the enum members directly in order. The standard functions "pred"(ecessor) and "succ"(essor) _DON'T WORK_, so there's no natural way to _enumerate_ an enumeration in fpc! What a glaring omission, no? -- -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
>> we_2: 2 we_5: 5 we_next: 6 we_more: 7 we_decade: 20 ^ ^ ^ ^ > Not quite, it does not produce the spaces marked above... Wow, there you impressed me a lot. Good eyes, indeed, to make it more visible, I did add spaces after pasting from the terminal. Fre;D De : Sieghard Envoyé : dimanche 15 mars 2020 23:25 À : mseide-msegui-talk@lists.sourceforge.net Objet : Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0 Hello fredvs, you wrote on Fri, 13 Mar 2020 17:19:37 -0700 (MST): > With your code I get this: > > $ /home/fred/weird/weirdtest > > low: we_2, value: 2; high: we_decade, value: 20 > 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 > we_2: 2Runtime error 107 at $00401293 > $00401293 > $0040104F > > ___ > > Would you be happy with this:? Yes, that's the expected result. > Would you be happy with this:? > PROGRAM weirdtest; ... > TYPE weird = (we_2:= 2, we_5:= 5, we_next, we_more, we_decade:= 20); > > const > weirdorder: Array[1..5] of weird=(we_2,we_5,we_next, we_more, > we_decade); ... > we:=Low(weird); > for we in weirdorder ... Except from multiple non-Pascal syntax elements, this is correct. Although the initialization of "we" before the second "FOR" loop is superfluous, it does no harm. The FOR loop itself uses yet another fpc extension to the Pascal syntax, the "in" operator applied to the elements of an array. The "in" operator was originally only defined for sets, as it does not imply any ordering, as is the case with sets in general. But it can be found in many programming languages for other data types as well (even Linux's bash implements it), and regarding the fact that any computer (memory) resident data structure has, due to the one dimensional structure of memory addresses, a "natural" or implied order, this kind of use commonly works as naively expected. > Gives as result: > > $ /home/fred/weird/weirdtest > > low: we_2, value: 2; high: we_decade, value: 20 > 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 > we_2: 2 we_5: 5 we_next: 6 we_more: 7 we_decade: 20 ^ ^ ^ ^ Not quite, it does not produce the spaces marked above... But my point - that you addressed by introducing _yet another_ data structure, the "weirdorder" array - was that there is _no_ possibility in fpc to access the enum members directly in order. The standard functions "pred"(ecessor) and "succ"(essor) _DON'T WORK_, so there's no natural way to _enumerate_ an enumeration in fpc! What a glaring omission, no? -- -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
> What a glaring omission, no? Yes. Also I am not totally convinced by the arguments to defend the choice of 0 as initialization of a enum var. Imho, it would be much more logic to initialize with the first item and I do not see what could be the problems. Here the answer in fpc mailing-list > Hi Sven, sorry to come back, (dont forget I am a enum-guru now). > > But to be totally logic, in the previous code: > >> if kind = tabulatorkindty(0) then > Should it not be something illegal because of definition: > >> tabulatorkindty = >> (tak_none := 1,tak_left,tak_right,tak_centered,tak_decimal); > the values assigned are tak_none = 1, tak_left = 2, tak_right = 3, > tak_centered = 4, tak_decimal = 5 > and 0 is never assigned. > > Then (re-imho) there is something strange with initialization with 0 > because > 0 should be out of range. The thing about the default value is that it's some known value, not necessarily some legal value. Also what value should the compiler select otherwise? The first one? The last one? The one with the lowest value? (enum values can be negative by the way) The one with the highest? The same also applies to range types: MyRange = 3..6. 0 is simply a sane default. It's the task of the programmer to make sure that their code works correctly nevertheless. Not to mention that 0 initialization is something that's very likely to be supported by the operating system: for global variables without explicit value set the BSS section is used which tells the OS to allocate a certain memory area with its content set to 0 (this area contains all unitialized global variables). Same is also true for class instances: it's easy to simply allocate the whole memory area to zero, however to initialize each and every field to a known default is much more costly (see the performance impact that management operators had for managed fields inside classes, before that was improved again). Regards, Sven -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Hello fredvs, you wrote on Sun, 15 Mar 2020 16:53:12 -0700 (MST): > > What a glaring omission, no? > > Yes. Thank you for your support. > Also I am not totally convinced by the arguments to defend the choice of 0 > as initialization of a enum var. > Imho, it would be much more logic to initialize with the first item and I > do not see what could be the problems. This "choice" is just an artefact of the way the runtime library prepares the program's memory - it simply "clears" the whole area, i.e. it writes zeroes all the way. There's _NO_ provision to make sure that this is in any way useful or "legal". But here seems to be anothe rproblem in fpc's implementation, when, as you seem to have verified, the cast of a value that _may not have a binary representation consisting of 0s_ is simply accepted for use in a program. This is inconsistent, even dangerous, and at least misleading. > Here the answer in fpc mailing-list Thanks, I already read that by means of your links last time. I won't comment on this, as the argumentation is, to say the least, extremely weak. Why don't they simply accept that a variable may be initialized by some illegal value that way? There's no guarantee that _any_ variable will be "initialized" to some useable value if it's a local variable, either. Your local variable will get some arbitrary byte pattern from whatever used the memory before, be it an enumeration, integer or floating point value. Even when integers cannot have a really "illegal" value - all bit patterns are allowed - there are many types where this is _not_ so, among them also floating point values, which may be denormalized or even "NaN"s (Not a Number"), which latter _may_ produce an exception or just an unexpected result... I think, it's better to get a warning than a crash, even if it's not a big aircraft (like those recently...). -- -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Hello Sieghard and others.
Just by curiosity, do you have try the enum program example with Delphi ?
Sadly I dont have delphi installed any more.
Here the test program:
PROGRAM enumtest;
type
tabulatorkindty =
(tak_none := 1,tak_left,tak_right,tak_centered,tak_decimal);
var
kind: tabulatorkindty;
begin
if kind = tak_none then
WriteLn('OK it is tak_none')
else WriteLn('No it is not tak_none') ;
if kind = tabulatorkindty(0) then
WriteLn('OK it is 0')
else WriteLn('No it is not 0') ;
end.
This to compare with fpc result:
$ /home/fred/enumtest
> No it is not tak_none
> OK it is 0
--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Hello fredvs, you wrote on Wed, 18 Mar 2020 15:18:20 -0700 (MST): > Hello Sieghard and others. > > Just by curiosity, do you have try the enum program example with Delphi ? > Sadly I dont have delphi installed any more. No, sorry, at least not an even marginally recent version. Only Delphi 6 (very outdated), and Windows only in a virtual machine. -- -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
With last fpc 3.3.1 trunk, there are warnings in case like this:
procedure test;
var
b: 1..10;
begin
case b of // here warning
1: writeln('hello');
end
end;
" Warning: (6060) Case statement does not handle all possible cases."
In MSEgui there is lot of code that is similar and generate that warning.
I propose to simply disable that warning with {$warn 6060 off} and not touch
at rest of code.
What do you think?
Fre;D
--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Hello fredvs,
you wrote on Fri, 27 Mar 2020 15:04:49 -0700 (MST):
> With last fpc 3.3.1 trunk, there are warnings in case like this:
>
> procedure test;
> var
> b: 1..10;
> begin
> case b of // here warning
> 1: writeln('hello');
> end
> end;
>
> " Warning: (6060) Case statement does not handle all possible cases."
>
> In MSEgui there is lot of code that is similar and generate that warning.
>
> I propose to simply disable that warning with {$warn 6060 off} and not
> touch at rest of code.
I propose to add a - possibly empty, but AT LEAST commented! - default
(else) clause.
NOT handling some of the possible cases _might_ produce "interesting"
effects, so it should be considered to at least contemplate the possible
behaviour, maybe even add corresponding code raising an exception or
providing an error message - sometimes, an innocent looking modification
someplace else can trigger such an unhandled case and produce a rather
obscure failure.
"Sometimes" warnings _do_ have a serious reason!
--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Hello Sieghard.
I totally agree with you, sometimes the warnings helps.
I can understand that in a case of the variable is part of the procedure,
like this:
procedure test;
var
b: 1..10;
begin
case b of // here warning
1: writeln('hello');
end
end;
Here I understand and the warning is welcome.
But for this, when the variable is global:
var
b: 1..10;
...
procedure test;
begin
case b of // here warning
1: writeln('hello');
end
end;
Here, imho, the warning is not really needed.
It is the case in mostly all the warning of msegui, so, imho, we may disable
the warning in that case.
Fre;D
--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Re-hello Sieghard. > I propose to add a - possibly empty, but AT LEAST commented! - default > (else) clause. Yes I was thinking to do that but it is **lot of work**, +- 500 cases to fix, sometimes in complicated code. Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Re-re-hello Sieghard. > I propose to add a - possibly empty, but AT LEAST commented! - default > (else) clause. You are right. I will revert the last commit (that disabled the warning for many units) and re-commit the code with warning on. And if somebody want to do the fixes adding "else" in case statement he is welcome. (Otherwise I will do it asap). PS: You need to compile MSEide with fpc 3.3.1 to see those warnings. PS2: For people that does not know: MSEgui is now fully compatible with fpc 3.3.1, the msestat bug was fixed in previous commit. Fre;D Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
well done fred :D In a moment, I lost hope , and eventually you did it :) thanks for your effort ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Hello Code DZ. Me too I was desperate, without to make MSEgui compatible with fpc trunk, sure MSEgui will disappear. But thanks to Sven (who knows maybe that I never give up) MSEgui is still on the road. Did you try to compile MSEide with fpc trunk, are layout problems all ok now? Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
yes , every things works fine so far ;) ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
> yes , every things works fine so far ;) Yep, excellent news! So MSEgui will be fully compatible with last generation of ARM devices (that is what promised by FPC team). About trunk-warning fixes, it seems that there is not lot of candidate to do it. OK,asap, first lots of cups of coffee and then I will jump into it. Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
did you try compiling with fpc 3.0.4 with all these changes? just to be sure of backward compatibility . ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
> did you try compiling with fpc 3.0.4 with all these changes? Yes and did not find any problem. -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
> Yes and did not find any problem. ok , thats cool :) ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
> OK,asap, first lots of cups of coffee and then I will jump into it.
Top chrono!
Done in commit 2da0695 following the Sieghard advises:
Not using {$warn 6060 off} but fixed for real, adding this statement at end
of case:
else; // Case statment added to make compiler happy...
Ok now compilation of MSEide makes fpc 3.3.1 happy.
Only 2 warnings remain but I let you discover how to fix it:
msedatalist.pas(891,18) Warning: (4110) Range check error while evaluating
constants (-193 must be between 0 and 255)
mseactions.pas(762,34) Warning: (4110) Range check error while evaluating
constants (-63489 must be between 0 and 65535)
;-)
Fre;D
--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Sorry I am a never-give-it-up... So, about those famous 2 last warnings: I propose this to make the compiler happy: - First warning: > msedatalist.pas(891,18) Warning: (4110) Range check error while evaluating > constants (-193 must be between 0 and 255) Point to: foldlevelmask = byte(not (foldhiddenmask or currentfoldhiddenmask)); I propose this instead (see abs()): foldlevelmask = byte(abs(not (foldhiddenmask or currentfoldhiddenmask))); - Last warning: > mseactions.pas(762,34) Warning: (4110) Range check error while evaluating > constants (-63489 must be between 0 and 65535) Point to: result:= (key <> 0) and (key <> word(not modmask)); I propose this instead (see abs()): result:= (key <> 0) and (key <> word(abs(not modmask))); What do you think? Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
why not just replace byte with integer , i am not sure ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
why not just replace byte with integer , i am not sure ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
> why not just replace byte with integer I just try it and with this you get 8 new warnings... -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
What is very strange is that I get also a warning with this (see abs() added): const foldhiddenbit = 7; foldhiddenmask = abs(1 shl foldhiddenbit); currentfoldhiddenbit = 6; currentfoldhiddenmask = abs(1 shl currentfoldhiddenbit); foldlevelmask = byte(not (foldhiddenmask or currentfoldhiddenmask)); // here warning msedatalist.pas(891,18) Warning: (4110) Range check error while evaluating constants (-193 must be between 0 and 255) So only this make him happy: foldlevelmask = byte(abs(not (foldhiddenmask or currentfoldhiddenmask))); -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
The same for the last warning: Changing with this: modmask = abs(shift or ctrl or alt or $1000 or pad); ... result:= (key <> 0) and (key <> word((not modmask))); Gives the warning: mseactions.pas(763,34) Warning: (4110) Range check error while evaluating constants (-63489 must be between 0 and 65535) Only this make fpc happy: result:= (key <> 0) and (key <> word(abs(not modmask))); ? Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Hello fredvs, you wrote on Sun, 29 Mar 2020 08:36:10 -0700 (MST): > So, about those famous 2 last warnings: > > I propose this to make the compiler happy: ... > > msedatalist.pas(891,18) Warning: (4110) Range check error while > > evaluating constants (-193 must be between 0 and 255) > >Point to: >foldlevelmask = byte(not (foldhiddenmask or currentfoldhiddenmask)); > >I propose this instead (see abs()): >foldlevelmask = byte(abs(not (foldhiddenmask or > currentfoldhiddenmask))); I'm rather afraid that this will _not_ result in the intended value. I.e. a statement testing an expression of either "foldhiddenmask" or "currentfoldhiddenmask" against the value of "foldlevelmask" will _not_ neccessarily always fail (it should fail because of the "not"). This seems to derive from an uncanny mixture of signed and unsigned values, perhaps due to a range overflow during evaluation of the expression, triggering an unwanted sign extension and thus turning an unsigned value "negative". -193 is $FF3F(32bit), byte ($3F) = 63, NOT $3F = $C0 = 192. So it seems the expression ors together bit 6 & 7 of a byte-size type, and the compiler's evaluator sign extends the result, regarding a set bit 7 as a negative sign bit... A rather weird compiler error, not a program error. > - Last warning: > > > mseactions.pas(762,34) Warning: (4110) Range check error while > > evaluating constants (-63489 must be between 0 and 65535) > >Point to: >result:= (key <> 0) and (key <> word(not modmask)); > >I propose this instead (see abs()): >result:= (key <> 0) and (key <> word(abs(not modmask))); > > What do you think? About the same as for the case above, Same analysis as above yields: -63489 = $07FF, word ($07FF) = 2047, NOT $07FF = $F800 = 63488. Here, a lot more bits are involved, but this may also derive from a masking or combining operation, setting the 16-bit-value "sign bit" (bit 15) and triggering a - false - sign extension by the compiler. It _may be_ that it's sufficient to just mask off any unused bits within the evaluation expression _before_ casting the result to the destination size. So foldlevelmask = byte(not (foldhiddenmask or currentfoldhiddenmask)); might become foldlevelmask = byte (not (foldhiddenmask or currentfoldhiddenmask) AND $FF); and result:= (key <> 0) and (key <> word(not modmask)); might become result:= (key <> 0) and (key <> word ((not modmask) AND $)); And yes, you wrote on Sun, 29 Mar 2020 09:37:10 -0700 (MST): > What is very strange is that I get also a warning with this (see abs() > added): > > const > foldhiddenbit = 7; ^ This is the place that could trigger such a sign extension. > foldhiddenmask = abs(1 shl foldhiddenbit); And it's even used indirectly to produce a value "of indeterminate size", and with indeterminate signedness above that. > currentfoldhiddenbit = 6; > currentfoldhiddenmask = abs(1 shl currentfoldhiddenbit); On the other hand, this sequence does not produce a borderline value, and thus won't trigger any unexpected (mis-) behaviour. I suspect a similar situation with the other warning. Should the second case _not_ arise from such a borderline situation, you might attempt to report a serious compiler error on the fpc bug tracker. (There's not any reason to regard every 4th bit as a sign bit! Bit 11, the probable culprit in the second case above, has no such function at all.) -- -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Hello fredvs,
you wrote on Fri, 27 Mar 2020 18:30:11 -0700 (MST):
> I can understand that in a case of the variable is part of the procedure,
> like this:
...
> begin
> case b of // here warning
> 1: writeln('hello');
> end
> end;
...
> But for this, when the variable is global:
...
> Here, imho, the warning is not really needed.
There's no difference between the cases - why should a global variable be
regarded any different from a local one? Because it's initalized by the
start up code? Well, it might at any point in the program before be
modified, and thus fall outside the range of values the case statement
covers, what is the _reason_ for the warning.
Your declaration even defines a variable that's initialized to an illegal
value in the first place, using it without prior assignment should produce
a program failure!
> It is the case in mostly all the warning of msegui, so, imho, we may
> disable the warning in that case.
No.
You wrote on Fri, 27 Mar 2020 18:39:41 -0700 (MST):
> > I propose to add a - possibly empty, but AT LEAST commented! - default
> > (else) clause.
If you see that this clause will _never_ cause a problem, it can be left
alone and be disregarded (until it may be needed). Otherwise this clause
should rather raise an exception, so _if_ an extraneous case occurs, it
will show up and can be handled, and the reason noted. (That's one of
the problems with heritage: what's that good for?)
> Yes I was thinking to do that but it is **lot of work**, +- 500 cases to
> fix, sometimes in complicated code.
Working on Windows? But even there you can get those fine Unix utilities
like grep, awk, sed and others that make it easy to take care of such
things. Certainly that's some work on the outset, but you can cover 500
cases with the same effort as only 5 or 15. And have the tools (and skills)
ready for other, similar cases.
--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Hello Seignard.
> Yes I was thinking to do that but it is **lot of work**, +- 500 cases to
> fix, sometimes in complicated code.
It was terminated yesterday, after lot of cups of coffee,
checking every case individually and following your advice: adding a last
else statement + comment.
> else; // added statement to make compiler happy.
https://github.com/mse-org/mseide-msegui/commit/2da0695
About range check error:
> > msedatalist.pas(891,18) Warning: (4110) Range check error while
> > evaluating constants (-193 must be between 0 and 255)
Many thanks for your explanations.
It seems that the conclusion is, in this case, to use {$warn 6060 off} and
dont touch to the original code.
OK everybody to disable warn 6060 for those 2 cases?
Fre;D
--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Ooops, in previous mail, please read: (warning 4110 in place of warning
6060):
About range check error:
> > msedatalist.pas(891,18) Warning: (4110) Range check error while
> > evaluating constants (-193 must be between 0 and 255)
Many thanks for your explanations.
It seems that the conclusion is, in this case, to use {$warn 4110 off} and
dont touch to the original code.
OK everybody to disable warn 4110 for those 2 cases?
--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Hello fredvs,
you wrote on Mon, 30 Mar 2020 11:12:11 -0700 (MST):
> About range check error:
>
> > > msedatalist.pas(891,18) Warning: (4110) Range check error while
> > > evaluating constants (-193 must be between 0 and 255)
>
> Many thanks for your explanations.
> It seems that the conclusion is, in this case, to use {$warn 4110 off} and
> dont touch to the original code.
>
> OK everybody to disable warn 4110 for those 2 cases?
Seems to be acceptable in these cases, as they look very strongly like an
unfortunate algorithm's misbehaviour.
--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Hello Sieghard.
OK warning disabled for those 2 cases.
I did use {$warnings off}/{$warnings on} vs {$warn 4110 off}.
This to isolate the warnings off only for those 2 lines:
{$warnings off}
result:= (key <> 0) and (key <> word(not modmask));
{$warnings on}
{$warnings off}
foldlevelmask = byte(not (foldhiddenmask or currentfoldhiddenmask));
{$warnings on}
It was committed here:
https://github.com/mse-org/mseide-msegui/commit/28290d
Many thanks Sieghard for your attention and highly relevant advice.
Fre;D
--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] About Warnings with mseide + fpc 3.0.4 / 3.2.0
Hello fredvs,
you wrote on Mon, 30 Mar 2020 13:50:54 -0700 (MST):
> OK warning disabled for those 2 cases.
> I did use {$warnings off}/{$warnings on} vs {$warn 4110 off}.
>
> This to isolate the warnings off only for those 2 lines:
>
> {$warnings off}
> result:= (key <> 0) and (key <> word(not modmask));
> {$warnings on}
>
> {$warnings off}
> foldlevelmask = byte(not (foldhiddenmask or currentfoldhiddenmask));
> {$warnings on}
>
> It was committed here:
>
> https://github.com/mse-org/mseide-msegui/commit/28290d
>
> Many thanks Sieghard for your attention and highly relevant advice.
Thank you for your high esteem - just want to mention that I'm NOT a
computer scientist, just a freelancer doing low visibility electronics
and software projects, mostly controllers of any kind, for little
manufacturers hereabouts...
--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
