Lib package compilation error

[cfbsoftware]

An error has been reported on the BlackBox Community forum:

http://community.blackboxframework.org/ ... ?f=16&t=94

[Josef Templ]

assignment of a CHAR to an INTEGER.
It is a bug in the source code.

- Josef

[Robert]

assignment of a CHAR to an INTEGER.
It is a bug in the source code.

Strictly speaking assignment of SHORTCHAR to BOOLEAN caused by a change in the WinApi interface dating from this January.

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.

[Zinn]

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?

[Josef Templ]

Strictly speaking assignment of SHORTCHAR to BOOLEAN caused by a change in the WinApi interface dating from this January.

ooops, of course, its BOOLEAN NOT INTEGER.

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.

It seems that the CPC maintenance could benefit from a (scripting) tool
that rebuilds all packages automatically for a new release.
Thereby you would at least see the inconsistencies pointed out by the compiler.

- Josef

[Robert]

The WinApi interface, at BBox 1.6, used to be:

Code: Select all

LOGFONTW* = RECORD [untagged]
			...
			lfItalic*: SHORTCHAR;
			...

and one sets this field with the code

Code: Select all

VAR
	font  :  WinApi.LOGFONTW;
	style : SET;
	...

	IF Fonts.italic IN style THEN font.lfItalic := 1X ELSE font.lfItalic := 0X END;

In January we changed lfItalic to BOOLEAN, and the application code needs to change to

Code: Select all

	font.lfItalic := Fonts.italic IN style;

Is 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

[Josef Templ]

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.

This 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.
The smallest available memory unit (typically a byte) is used for boolean.

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.

undefined. This should never occur.
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

[Zinn]

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.

[Robert]

This 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.

I have no c experience, but when I see blogs like http://blogs.msdn.com/b/oldnewthing/arc ... 29884.aspx it seems
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

Your guarnateed that someone will put something other than 1 (-1) in as a true value.

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.

[Robert]

You don’t have to know that FALSE is 0 and TRUE is 1.

You do have to know this, because otherwise you do no know you are setting lfItalic to the values the Microsoft documentation asks for.