[vbox-dev] Type conflicts in vbox C API

[Klaus Espenlaub]

On 02.06.2014 18:00, Taowei Luo wrote:
> Thank you.
> And the SDKRef.pdf is really useful to me.

Wondering if you're bumping into an accidental regression in the C API 
overhaul a few months ago (made its debut in the SDK for VBox 4.3.8). 
Can you provide a code snippet which suddenly started failing?

Our intention was to keep things 100% backwards compatible (no matter 
how rotten the old C API programming style was, it's a lot nicer now, 
see the updated sample code).

Klaus

> 2014-06-02 21:52 GMT+08:00 Frank Mehnert <frank.mehnert at oracle.com
> <mailto:frank.mehnert at oracle.com>>:
>
>     Hi Taowei,
>
>     On Monday 02 June 2014 12:28:35 Taowei Luo wrote:
>      > Hi, I'm developing the vbox drivers for libvirt, with the vbox c api.
>      >
>      > I have a question. Is there any type conflict in vbox C API between
>      > different versions?
>      >
>      > For example, I have a var type named nsresult. In some C API
>     versions, It
>      > defines nsresult as type PRUint32. Is it true that all nsresults (in
>      > different versions) will be defined as the same type PRUint32?
>      >
>      > I know it may be false for structs which have function pointers.
>     But in
>      > other cases, especially basic types, is the type compatible with
>     all c api
>      > versions?
>
>     nsresult is always PRUint32. Note that this code is always a status
>     code and will never include any pointer or similar. Values bigger
>     than 0x80000000 are used for errors, NS_OK is defined as 0.
>
>     In general, the API will not differ between VBox versions of the same
>     stable branch but the API might change with a new major release. For
>     example, VBox 4.3.2 and 4.3.4 have the same API while VBox 4.2.2 and
>     4.3.2 differ a bit. Usually the changes between different API versions
>     are small and all changes are documented in section 12 of the VirtualBox
>     SDK documentation (SDKRef.pdf, not UserManual.pdf!)
>
>     Kind regards,
>
>     Frank