#218 64-bit OCFNext

[Vidar Hasfjord]

We have long had 64-bit build support for OCFNext. However, there are issues and missing pieces that prevent full usability in 64-bit build mode. In particular, we have yet no 64-bit support for BOCOLE, the underlying library on which OCFNext is built. Work on addressing this is ongoing [feature-requests:#184]. In addition, there are pointer truncation issues that have not yet been addressed, generating warnings in the build.

[Vidar Hasfjord]

It is immensely useful (even important, I think) to have a clean build, as it very much simplifies regression tests. With a clean build, you can see at a glance that you have not added warnings with your latest changes. If a warning shows up, you have a regression, which needs fixing.

Therefore, it has annoyed me that OCFNext has produced these warnings in 64-bit build mode for all these years. As mentioned in the ticket, 64-bit support in BOCOLE is ongoing, and hopefully at some point, when this work is completed, OCFNext will have full 64-bit support and produce no warnings.

However, to have clean builds in the meantime, I have now addressed the warnings with some preliminary fixes and workarounds. In particular, the warnings had three underlying issues:

1. Truncating cast in member offset calculation in TUknownI::Host [r6258].
2. Truncating BCID casts [r6259].
3. Truncating HREFTYPE casts [r6260].
   
   

The fix for (1) was simply to change int to INT_PTR. However, note that, as a code comment says, the hack used to calculate offset may not be portable. And it is obviously not standard compliant. Changing the code to use offsetof instead may fix that, although use of the latter also has undefined behaviour is some cases (see link).

To fix (2), I redefined BCID from owl::uint32 to UINT_PTR. I also had to update function signatures to consistently use BCID rather than owl::uint32, as many did. I also had to move the definition of BCID from "ocbocole.h" to "appdesc.h" to resolve dependencies. Whether this redefinition of BCID is fully compatible, I don't know. I am not able to test. Although usage within OCFNext seems to indicate it should be OK, this needs testing.

Issue (3) I am not in a position to fix. This must be fixed by those working on 64-bit support for this library. HREFTYPE is a type defined in the Windows API ("oaidl.h"), so it cannot be widened to accommodate 64-bit pointers.

However, to eliminate warnings generated by (3), the library will now throw an exception (TXUnsafePointerOperation), whenever truncating casts are encountered. In my analysis, I found no internal use of any of the functions that perform these casts. Hence, I have in addition marked these functions as deprecated, so that the user is given a warning, if these functions are used in client code.