Am Samstag 23 Dezember 2006 18:08 schrieb Marcel Holtmann: > > The patch fixes this. > > Actually, mingw32 is broken but since there is no alternative... > > do we break any API with this change or is it safe to do it?
Well, we actually do. The name of a variable (a pointer) in a public struct was changed from "interface" to "intf". However, I not know an application that actually uses it. BTW: the same error message would also come up for those applications. You could give it a better name though, e.g. "transport" instead of "intf" since it is a struct obex_usb_intf_transport_t*. So, YES it breaks the API but does NOT break the ABI. I don't know any way but this one to solve this if you want to support compilation on win32 with gcc (even in latest Version 4.1.1). Googling for "interface" is not really helpful ;) I don't know how the Visual C++ compiler from Microsoft reacts to the code but the build system doesn't work with that one anyway. HOWEVER, the struct itself is not defined in any public headerfile, only in lib/usbobex.h. Thus, there is not really an application that actually _could_ use it without a private copy of that header file. So we should actually get rid of it (it exposes internal variables). Instead, obex_usb_intf_t should be a part of struct obex_usb_intf_transport_t and the container_of() from the linux kernel could be use instead of the pointer. But that would break the ABI, in addition to the API, and is thus the lesser compatible solution. HS ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Openobex-users mailing list [email protected] http://lists.sourceforge.net/lists/listinfo/openobex-users
