Finally got a chance to check out the updated branch.
First, the usual stream of compilation errors:
1. cygwin is being an ass (as usual), with:
sam3u_benchmark.c: In function ‘benchmark_in’:
sam3u_benchmark.c:100:5: warning: passing argument 7 of
‘libusb_fill_iso_transfer’ from incompatible pointer type
../libusb/libusb.h:1568:20: note: expected ‘libusb_transfer_cb_fn’ but
argument is of type ‘void (*)(struct libusb_transfer *)’
sam3u_benchmark.c:104:5: warning: passing argument 6 of
‘libusb_fill_bulk_transfer’ from incompatible pointer type
../libusb/libusb.h:1511:20: note: expected ‘libusb_transfer_cb_fn’ but
argument is of type ‘void (*)(struct libusb_transfer *)’
I'm attaching the patch to fix this, which I hope can be integrated with
the sample addon commit during integration.
2. WDK also produces the following:
1>d:\libusbx-hans\libusb\descriptor.c(339) : error C2220: warning
treated as error - no 'object' file generated
1>d:\libusbx-hans\libusb\descriptor.c(339) : warning C4242: '=' :
conversion from 'int' to 'uint8_t', possible loss of data
1>d:\libusbx-hans\libusb\descriptor.c(445) : warning C4242: '=' :
conversion from 'int' to 'uint8_t', possible loss of data
1>d:\libusbx-hans\libusb\descriptor.c(482) : warning C4242: '=' :
conversion from 'int' to 'uint8_t', possible loss of data
1>d:\libusbx-hans\libusb\descriptor.c(880) : warning C4242: '=' :
conversion from 'int' to 'uint8_t', possible loss of data
Patch attached (went for the simplest but maybe we want to switch to
using an uint8_t rather than an int for i). "Happy are those who need
compile on one platform only, for they shall have much time to spare
after supper..."
3. With its gettimeofday(), unistd.h and sigaction, sam3u_benchmark is
not compatible with native Windows at all, i.e. MSVC and WDK are out
(and likely MinGW too). Therefore I'm gonna have reservations including
that sample, until we can make it work on all the main platforms.
While it was acceptable for samples that were crafted before the Windows
backend inclusion not to be included in MSVC/WDK (such as dpfp), I'm not
too happy about samples that were crafted post to still be platform
specific. We're trying to demo a cross-platform library here, so I think
it makes sense to want new samples to be cross-platform too.
Apart from that, and as far testing and compilation go on Windows,
things look OK. We do get an extra warning in the new Code Analysis tool
from MSVC (we already had 2), which doesn't surprise or bother me too
much as the MS tool can't quite grasp that yes there may be separate but
companion functions, to handle the creation and deletion of descriptor
data, and where we're fairly positive that null derefs won't happen.
Now, for additional non-compilation remarks:
* There's a bunch of whitespace issues in
https://github.com/jwrdegoede/libusbx/commit/2da19ff1ada7ea00f26645d7094e6b2525b0d829#L0R131
where tabs should be used instead of spaces.
* With the new BOS/ep_comp structs, and zero sized arrays, don't we want
to also go with the heavy but present everywhere else:
#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)
[] /* valid C99 code */
#else
[0] /* non-standard, but usually working code */
#endif
?
* We have quite a lot of libusb-1.0 references all over the place
(libusb-1.0.lib in much of the MSVC project files, libusb-1.0.def,
libusb-1.0.pc.in, etc.). Don't we want libusb-1.2 everywhere?
If the answer to that is "On POSIX, we don't" then I guess I will go
back on my vote for the next release to be 1.2, and instead push to
stick to 1.0 until we are actually ready to update the minor. The last
thing I want is have to spend the next few years explaining to Windows
users, who don't necessarily have a clue that on POSIX library
versioning and source versioning don't necessarily follow, that, yes,
the libusb-1.0.dll they are using is *really* v1.2...
If we're going to be non-intuitive for a whole set of platform
developers (in the vein of "system32 is for 64 bit apps, whereas
SysWOW64 is for 32 bit ones"), I'd rather avoid the non-intuitiveness of
one platform being exported across the board => either we replace every
last 1.0 we have with 1.2 (and yeah, that'll mean devs having to update
their linking and stuff), or we stick to 1.0.
Now, if we want to go 1.2 everywhere, judging by what a search on
libusb-1.0 returned, we still have quite a lot of work ahead of us...
On 2013.05.27 15:45, Hans de Goede wrote:
Working towards that goal I've added BOS and SS EP comp support to my tree
today. It takes all things discussed previously into account. One new thing
is that I've renamed the libusb_bos_attributes enum to
libusb_usb_2_0_extension_attributes
and added a libusb_ss_usb_device_capability_attributes enum, as the 2 are not
the same. The USB 2.0 Extension descriptor has a LPM bit, where as the
SuperSpeed USB Device Capability descriptor has a TPM bit, close, but
definitely not the same!
Sounds good to me. xusb checks against an FX3 device looked fine too.
Btw, when did we add topology to listdevs? That looks real neat!
Regards,
/Pete
>From d888b306f62ea372f1db6ee6dbd614e49bc45e65 Mon Sep 17 00:00:00 2001
From: Pete Batard <p...@akeo.ie>
Date: Wed, 29 May 2013 00:08:10 +0100
Subject: [PATCH] Samples: Add calling convention for sam3u callback
* prevents an incompatible type warning on cygwin
---
examples/sam3u_benchmark.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/examples/sam3u_benchmark.c b/examples/sam3u_benchmark.c
index 6a1f5ee..99d6b0f 100644
--- a/examples/sam3u_benchmark.c
+++ b/examples/sam3u_benchmark.c
@@ -40,7 +40,7 @@ static struct libusb_device_handle *devh = NULL;
static unsigned long num_bytes = 0, num_xfer = 0;
static struct timeval tv_start;
-static void cb_xfr(struct libusb_transfer *xfr)
+static void LIBUSB_CALL cb_xfr(struct libusb_transfer *xfr)
{
unsigned int i;
--
1.8.0.msysgit.0
>From bd158a67e9c3df6ee26aa12fd3bd8c6822ac8d66 Mon Sep 17 00:00:00 2001
From: Pete Batard <p...@akeo.ie>
Date: Wed, 29 May 2013 01:19:34 +0100
Subject: [PATCH] Windows: Fix broken WDK compilation
---
libusb/descriptor.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libusb/descriptor.c b/libusb/descriptor.c
index 161be36..358ae61 100644
--- a/libusb/descriptor.c
+++ b/libusb/descriptor.c
@@ -336,7 +336,7 @@ static int parse_interface(libusb_context *ctx,
if (r < 0)
goto err;
if (r == 0) {
- ifp->bNumEndpoints = i;
+ ifp->bNumEndpoints = (uint8_t)i;
break;;
}
@@ -442,7 +442,7 @@ static int parse_configuration(struct libusb_context *ctx,
usbi_warn(ctx,
"short extra config desc read %d/%d",
size, header.bLength);
- config->bNumInterfaces = i;
+ config->bNumInterfaces = (uint8_t)i;
return size;
}
@@ -479,7 +479,7 @@ static int parse_configuration(struct libusb_context *ctx,
if (r < 0)
goto err;
if (r == 0) {
- config->bNumInterfaces = i;
+ config->bNumInterfaces = (uint8_t)i;
break;
}
@@ -877,7 +877,7 @@ static int parse_bos(struct libusb_context *ctx,
buffer += dev_cap.bLength;
size -= dev_cap.bLength;
}
- _bos->bNumDeviceCaps = i;
+ _bos->bNumDeviceCaps = (uint8_t)i;
*bos = _bos;
return LIBUSB_SUCCESS;
--
1.8.0.msysgit.0
------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
