Lib package compilation error
-
- Posts: 204
- Joined: Wed Sep 18, 2013 10:06 pm
- Contact:
Lib package compilation error
An error has been reported on the BlackBox Community forum:
http://community.blackboxframework.org/ ... ?f=16&t=94
http://community.blackboxframework.org/ ... ?f=16&t=94
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: Lib package compilation error
assignment of a CHAR to an INTEGER.
It is a bug in the source code.
- Josef
It is a bug in the source code.
- Josef
Re: Lib package compilation error
Strictly speaking assignment of SHORTCHAR to BOOLEAN caused by a change in the WinApi interface dating from this January.Josef Templ wrote:assignment of a CHAR to an INTEGER.
It is a bug in the source code.
This illustrates an interesting problem for CPC (and other collections). Should their packages be compatible with the latest stable release, the latest unstable release, or do they need to try to keep multiple versions? Not easy.
Anyway Helmut, thanks for publishing the fix to this problem.
Re: Lib package compilation error
Robert, in my opinion we should update subsystem Lib and write a change note in the document Quick-Start.
Should I update CPC?
Or would you like to take the opportunity to do some other changes?
Should I update CPC?
Or would you like to take the opportunity to do some other changes?
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: Lib package compilation error
ooops, of course, its BOOLEAN NOT INTEGER.Robert wrote: Strictly speaking assignment of SHORTCHAR to BOOLEAN caused by a change in the WinApi interface dating from this January.
It seems that the CPC maintenance could benefit from a (scripting) toolRobert wrote: This illustrates an interesting problem for CPC (and other collections). Should their packages be compatible with the latest stable release, the latest unstable release, or do they need to try to keep multiple versions? Not easy.
that rebuilds all packages automatically for a new release.
Thereby you would at least see the inconsistencies pointed out by the compiler.
- Josef
Re: Lib package compilation error
The WinApi interface, at BBox 1.6, used to be:and one sets this field with the code
In January we changed lfItalic to BOOLEAN, and the application code needs to change toIs this a good change?
1 - It certainly looks simpler and more direct.
2 - It breaks back compatibility.
My concern is more serious than either of these points.
It only looks simpler if we look only at the BBox WinApi interface.
If we look at the Microsoft documentation it tells us that lfItalic should be 1 byte, and we should set that byte to 0 (false) or 1 (true) for no italic, italic respectively.
I now look at the new BBox code and it is not obvious to me that:
1 - BOOLEAN is 1 byte
2 - FALSE is coded as 0
3 - TRUE is coded as 1.
With the old code I could see I was doing what Microsoft asked, with the new code I can't.
Even if I think the 3 facts above are true, I might want to check them to be on the safe side. This means they must be easy to find in the BBox documentation. I can't find them at all.
Another issue is when lfItalic is set by Windows. The value 0 should be interpreted as FALSE. Any other value (eg 36) should be interpreted as TRUE. How do we know that BBox will react correctly when getting a BOOLEAN coding that differs from its usual codings for TRUE & FALSE?
Assuming TRUE is coded as 1, how does BlackBox interpret:
"36", ~"36", "36" & "1", etc, where by "36" I mean a variable of type BOOLEAN with the same bit-pattern as a BYTE of value 36.
Robert
Code: Select all
LOGFONTW* = RECORD [untagged]
...
lfItalic*: SHORTCHAR;
...
Code: Select all
VAR
font : WinApi.LOGFONTW;
style : SET;
...
IF Fonts.italic IN style THEN font.lfItalic := 1X ELSE font.lfItalic := 0X END;
Code: Select all
font.lfItalic := Fonts.italic IN style;
1 - It certainly looks simpler and more direct.
2 - It breaks back compatibility.
My concern is more serious than either of these points.
It only looks simpler if we look only at the BBox WinApi interface.
If we look at the Microsoft documentation it tells us that lfItalic should be 1 byte, and we should set that byte to 0 (false) or 1 (true) for no italic, italic respectively.
I now look at the new BBox code and it is not obvious to me that:
1 - BOOLEAN is 1 byte
2 - FALSE is coded as 0
3 - TRUE is coded as 1.
With the old code I could see I was doing what Microsoft asked, with the new code I can't.
Even if I think the 3 facts above are true, I might want to check them to be on the safe side. This means they must be easy to find in the BBox documentation. I can't find them at all.
Another issue is when lfItalic is set by Windows. The value 0 should be interpreted as FALSE. Any other value (eg 36) should be interpreted as TRUE. How do we know that BBox will react correctly when getting a BOOLEAN coding that differs from its usual codings for TRUE & FALSE?
Assuming TRUE is coded as 1, how does BlackBox interpret:
"36", ~"36", "36" & "1", etc, where by "36" I mean a variable of type BOOLEAN with the same bit-pattern as a BYTE of value 36.
Robert
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: Lib package compilation error
This is done in the same way in most if not all compilers in the world as a de-facto standard because ofRobert wrote: I now look at the new BBox code and it is not obvious to me that:
1 - BOOLEAN is 1 byte
2 - FALSE is coded as 0
3 - TRUE is coded as 1.
compatibility with C programming interfaces. C does not have boolean but uses 0 and 1 instead.
The smallest available memory unit (typically a byte) is used for boolean.
undefined. This should never occur.Robert wrote: Assuming TRUE is coded as 1, how does BlackBox interpret:
"36", ~"36", "36" & "1", etc, where by "36" I mean a variable of type BOOLEAN with the same bit-pattern as a BYTE of value 36.
Using BOOLEAN instead of SHORTCHAR in WinApi is only valid if
the values are always 0 or 1 and nothing else.
I guess that if Helmut were aware of the compatibility problem with Lib, he would not have
changed WinApi that way. Helmut, please comment on that.
- Josef
Re: Lib package compilation error
With this change the source is more readable.
You don’t have to know that FALSE is 0 and TRUE is 1.
By the way there exist some systems where TRUE is all ones (-1)
As far as I know the modules HostDialog, HostFonts, HostPictures, HostPorts and HostWindows
was adapted to this change of WinApi.
I compiled most of the CPC subsystem and fond so far only LibFonts & LibPlot3D.
You don’t have to know that FALSE is 0 and TRUE is 1.
By the way there exist some systems where TRUE is all ones (-1)
As far as I know the modules HostDialog, HostFonts, HostPictures, HostPorts and HostWindows
was adapted to this change of WinApi.
I compiled most of the CPC subsystem and fond so far only LibFonts & LibPlot3D.
Re: Lib package compilation error
I have no c experience, but when I see blogs like http://blogs.msdn.com/b/oldnewthing/arc ... 29884.aspx it seemsThis is done in the same way in most if not all compilers in the world as a de-facto standard because of
compatibility with C programming interfaces. C does not have boolean but uses 0 and 1 instead.
dangerous, and unnecessary, to assume that a BYTE variable (as Microsoft define lfItalic) is guaranteed to be 0 or 1.
The second comment in the link above includes
I am sure I have seen other examples on the net where WinApi procedures that claim to return a boolean (I am not using the word in a technical sense here) actually return numbers other than 1 which contain undocumented, but potentially useful information.Your guarnateed that someone will put something other than 1 (-1) in as a true value.
Last edited by Robert on Wed Jun 17, 2015 9:10 am, edited 1 time in total.
Re: Lib package compilation error
You do have to know this, because otherwise you do no know you are setting lfItalic to the values the Microsoft documentation asks for.Zinn wrote:You don’t have to know that FALSE is 0 and TRUE is 1.