Re: [Libusbx-devel] [PATCH/RFC] logging timestamps v3
2012/5/6 Pete Batard : > And this was exactly my intention. The bulk of the patch is yours, and > I don't really see the need to split it when the addon is minimal. Pete, to avoid any more problems in the future maybe you should refrain from editing patches from others. I have no problem in having 2 patches (even trivial ones) from 2 people instead of 1 patch being the merged work of 2 people. I think it is better for code authorship attribution and project history. Regards, -- Dr. Ludovic Rousseau -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusbx-1.0.11 RC1
On Mon, May 7, 2012 at 8:40 AM, Pete Batard wrote: > Libusbx v1.0.11 RC1 is now available either from git, or as a source > tarball from: > https://sourceforge.net/projects/libusbx/files/releases/1.0.11/source/ > > This is the RC for the 1.0.11 bugfix release, that reverts the > removal of critical Windows event handling call, which was > introduced in 1.0.10, and also adds timestamped logging as > its main features. For other changes, either see the git log > or the NEWS file. > > Please test and report issues within 48 hours. The official release is > planned for Tuesday. There is one minor warning under OpenBSD (5.1 Current). But I think that is not a problem for the 1.0.11 release. bash-4.2$ make make all-recursive Making all in libusb CC libusb_1_0_la-core.lo CC libusb_1_0_la-descriptor.lo CC libusb_1_0_la-io.lo CC libusb_1_0_la-sync.lo CC libusb_1_0_la-openbsd_usb.lo CC libusb_1_0_la-threads_posix.lo CCLD libusb-1.0.la Making all in doc Making all in examples CC listdevs.o CCLD listdevs CC xusb.o CCLD xusb xusb.o(.text+0x10a3): In function `main': /home/mcuee/Desktop/build/libusbx/libusbx-1.0.11-rc1/examples/xusb.c:781: warning: strcat() is almost always misused, please use strlcat() CC dpfp.o CCLD dpfp CC dpfp_threaded-dpfp_threaded.o CCLD dpfp_threaded -- Xiaofan -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH/RFC] logging timestamps v3
On 2012.05.07 09:22, Ludovic Rousseau wrote: > Pete, to avoid any more problems in the future maybe you should > refrain from editing patches from others. If you think there ever was a problem, then Peter successfully managed to make you believe that he had a say as to the content of the patch or the commit message, which he hasn't. The idea on the contrary, is that to avoid problems and be efficient with our time constraints, which is the one issue we need to address at all times, we should very much have the ability to edit patches as we see fit, especially as we're expected to constantly pick items from libusb and add ontop of them for libusbx usage. Let's consider this patch. If we were to do it the way you advocate, we'd have picked up Peter's commit, submitted it for review (with some possible small modifications for libusbx retrofit) while indicating that the thread ID addon would be handled in a subsequent patch. Ideally then, people would have first added this patch to their tree and tested (takes a little bit of time), possibly proposed a modification within the limited scope of the original patch (eg: output formatting), which people would (ideally) then have retested. OK, we're good, now we can integrate the patch. But wait, that's not all: now we want to add the thread ID, so here we go again reviewing a different patch, integrating it in one's own repo, testing it, commenting, potentially re-testing it, etc... Personally, I think it did make a lot of sense to address the review process with a single patch here, since not much was added and it very much pertains to the same feature, as it should save some time for everybody participating in the review process. And that's exactly what I aimed for. > I think it is better for code authorship attribution and project history. I think there's a threshold for which addons should be split into a separate commits, which is probably subjective to the person modifying the patch as well as the features being dealt with plus the time constraints, and which I didn't see being reached here. As to project history, I already indicated that there was hardly anything to be gained here, especially as we can hardly be expected to provide consistent referencing to libusb.git commits when we are likely to pick and integrate patches of interest submitted to the libusb-devel mailing list before they are integrated in libusb.git (which is one of the reasons we forked). Regards, /Pete -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH/RFC] logging timestamps v3
On Sun, May 6, 2012 at 10:39 AM, Xiaofan Chen wrote: > On Sun, May 6, 2012 at 7:35 AM, Pete Batard wrote: >> With BSD support becoming a headache, and no official >> maintainer for the *BSD backends to help us out, along with >> the need to go to bugfix release soon, I propose dropping >> thread IDs for OpenBSD/NetBSD for the time being, >> and just return -1 there. > > I think that is fair. > > I will forward this to the OpenBSD developer to see if he > has some input. As per Matin (the author of the OpenBSD backend), you can use the getthrid() syscall that returns a pid_t. But he does know if that works for NetBSD or not. http://ftp.fr.openbsd.org/pub/OpenBSD/src/sys/sys/syscall.h I searched NetBSD's syscall.h and it does not have getthrid(). http://fxr.watson.org/fxr/source/sys/syscall.h?v=NETBSD So I think for 1.0.11 release, it is okay just to leave out OpenBSD/NetBSD. And Pete is right that NetBSD and OpenBSD may need to diverge in the future. -- Xiaofan -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH/RFC] logging timestamps v3
Pete Batard wrote: > If you think there ever was a problem, Maybe Ludovic's point is that it would be nice to track authorship in more detail than you care to. > then Peter successfully managed to make you believe that he had a > say as to the content of the patch or the commit message I wrote many times that the point is about authorship, not about commit content or description of commit content. One easy way to add "small" authorship information is a line in the commit message. > people would have first added this patch to their tree and tested If you want to go with what I think Ludovic suggested then you would send the two patches only when they were both finished. No point in something that will be changed right after, as you wrote regarding the device filtering. > I think there's a threshold for which addons should be split into a > separate commits I agree. Below the threshold I think a note in the commit message is a good idea; a reasonable tradeoff between effort and benefit. //Peter -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH/RFC] logging timestamps v3
How about moving on to discuss things that actually move the project forward... -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusbx-1.0.11 RC1
On 2012.05.07 12:32, Xiaofan Chen wrote:
There is one minor warning under OpenBSD (5.1 Current).
CCLD xusb
xusb.o(.text+0x10a3): In function `main':
/home/mcuee/Desktop/build/libusbx/libusbx-1.0.11-rc1/examples/xusb.c:781:
warning: strcat() is almost always misused, please use strlcat()
I am also testing with OpenBSD 5.1 (installed using i386/install51.iso),
and I'm not seeing the warning ATM.
What did you use to install your OpenBSD platform?
I don't think switching to strlcat is something we want to go through
especially as it doesn't seem to be part of string.h on Linux and isn't
mentioned in the manpages there either.
If achievable, I wouldn't have minded silencing the warning with a gcc
option, but what I'm reading [1] seem to indicate that these are
generated from a libc compiled with APIWARN defined, and thus one cannot
silence those without recompiling libc...
I guess the only option left is to remove the strcat call altogether,
which doesn't seem too difficult. Can you apply the attached patch on
your OpenBSD platform and confirm the warning goes away?
Regards
[1] http://www.daemonforums.org/showthread.php?t=6249
>From 9247468c515c40a32a509da1b96d269b23f802e3 Mon Sep 17 00:00:00 2001
From: Pete Batard
Date: Mon, 7 May 2012 15:41:50 +0100
Subject: [PATCH] Samples: fix strcat vs strlcat warning on OpenBSD
* Without this, OpenBSD produces the following warning:
strcat() is almost always misused, please use strlcat()
---
examples/xusb.c |3 +--
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/examples/xusb.c b/examples/xusb.c
index a98ebb4..c811353 100644
--- a/examples/xusb.c
+++ b/examples/xusb.c
@@ -54,7 +54,7 @@
// Global variables
bool binary_dump = false;
-char binary_name[64];
+char binary_name[64] = "raw.bin";
static int perr(char const *format, ...)
{
@@ -778,7 +778,6 @@ int main(int argc, char** argv)
debug_mode = true;
break;
case 'b':
- strcat(binary_name, "raw.bin");
if (j+1 < argc) {
strncpy(binary_name, argv[j+1],
64);
j++;
--
1.7.9.msysgit.0
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH/RFC] logging timestamps v3
On 2012.05.07 14:40, Xiaofan Chen wrote: > As per Matin (the author of the OpenBSD backend), you can > use the getthrid() syscall that returns a pid_t. Great. I'll give it a try and if it works, add it for the release. Regards, /Pete -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH/RFC] logging timestamps v3
On 2012.05.07 15:47, Pete Batard wrote: > On 2012.05.07 14:40, Xiaofan Chen wrote: >> As per Matin (the author of the OpenBSD backend), you can >> use the getthrid() syscall that returns a pid_t. > > Great. I'll give it a try and if it works, add it for the release. Seems to require linking against rthread and possibly some kernel options that may not be enabled. I can't seem to find a linkable version of getthrid() on the system I have, and issuing a syscall with SYS_getthrid, which is defined in syscall.h, always returns -1... Regards, /Pete -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusbx-1.0.11 RC1
On Mon, May 7, 2012 at 10:45 PM, Pete Batard wrote: > On 2012.05.07 12:32, Xiaofan Chen wrote: >> There is one minor warning under OpenBSD (5.1 Current). >> libusbx-1.0.11-rc1/examples/xusb.c:781: >> warning: strcat() is almost always misused, please >> use strlcat() > > I am also testing with OpenBSD 5.1 (installed using > i386/install51.iso), and > I'm not seeing the warning ATM. > What did you use to install your OpenBSD platform? It is the snapshot release, which is more recent than 5.1 release. Snapshot: http://ftp.openbsd.org/pub/OpenBSD/snapshots/i386/ 5.1: http://ftp.openbsd.org/pub/OpenBSD/5.1/i386/ > I guess the only option left is to remove the strcat call > altogether, which doesn't seem too difficult. Can you > apply the attached patch on your OpenBSD > platform and confirm the warning goes away? > Yes this is good and now there are no warning messages after applying the patch. Thanks. -- Xiaofan -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusbx-1.0.11 RC1
On Mon, May 7, 2012 at 8:40 AM, Pete Batard wrote: > Libusbx v1.0.11 RC1 is now available either from git, or as a source > tarball from: > https://sourceforge.net/projects/libusbx/files/releases/1.0.11/source/ > > This is the RC for the 1.0.11 bugfix release, that reverts the removal > of critical Windows event handling call, which was introduced in 1.0.10, > and also adds timestamped logging as its main features. For other > changes, either see the git log or the NEWS file. > > Please test and report issues within 48 hours. The official release is > planned for Tuesday. A few warnings under NetBSD 6.0 Beta. Other than that, it seems to work fine. localhost$ gmake gmake all-recursive gmake[1]: Entering directory `/home/mcuee/Desktop/build/libusbx/libusbx-1.0.11-rc1' Making all in libusb gmake[2]: Entering directory `/home/mcuee/Desktop/build/libusbx/libusbx-1.0.11-rc1/libusb' CC libusb_1_0_la-core.lo CC libusb_1_0_la-descriptor.lo CC libusb_1_0_la-io.lo CC libusb_1_0_la-sync.lo CC libusb_1_0_la-openbsd_usb.lo os/openbsd_usb.c: In function '_sync_control_transfer': os/openbsd_usb.c:638:2: warning: dereferencing type-punned pointer will break strict-aliasing rules os/openbsd_usb.c:639:2: warning: dereferencing type-punned pointer will break strict-aliasing rules os/openbsd_usb.c:640:2: warning: dereferencing type-punned pointer will break strict-aliasing rules CC libusb_1_0_la-threads_posix.lo CCLD libusb-1.0.la gmake[2]: Leaving directory `/home/mcuee/Desktop/build/libusbx/libusbx-1.0.11-rc1/libusb' Making all in doc gmake[2]: Entering directory `/home/mcuee/Desktop/build/libusbx/libusbx-1.0.11-rc1/doc' gmake[2]: Nothing to be done for `all'. gmake[2]: Leaving directory `/home/mcuee/Desktop/build/libusbx/libusbx-1.0.11-rc1/doc' Making all in examples gmake[2]: Entering directory `/home/mcuee/Desktop/build/libusbx/libusbx-1.0.11-rc1/examples' CC listdevs.o CCLD listdevs CC xusb.o CCLD xusb CC dpfp.o CCLD dpfp CC dpfp_threaded-dpfp_threaded.o CCLD dpfp_threaded gmake[2]: Leaving directory `/home/mcuee/Desktop/build/libusbx/libusbx-1.0.11-rc1/examples' gmake[2]: Entering directory `/home/mcuee/Desktop/build/libusbx/libusbx-1.0.11-rc1' gmake[2]: Nothing to be done for `all-am'. gmake[2]: Leaving directory `/home/mcuee/Desktop/build/libusbx/libusbx-1.0.11-rc1' gmake[1]: Leaving directory `/home/mcuee/Desktop/build/libusbx/libusbx-1.0.11-rc1' localhost$ gcc -v Using built-in specs. COLLECT_GCC=gcc Target: i486--netbsdelf Configured with: /usr/src2/tools/gcc/../../external/gpl3/gcc/dist/configure --target=i486--netbsdelf --enable-long-long --enable-threads --with-bugurl=http://www.NetBSD.org/Misc/send-pr.html --with-pkgversion='NetBSD nb2 20111202' --enable-__cxa_atexit --with-arch=i486 --with-tune=nocona --with-mpc=/var/obj/mknative/i386/usr/src2/destdir.i386/usr --with-mpfr=/var/obj/mknative/i386/usr/src2/destdir.i386/usr --with-gmp=/var/obj/mknative/i386/usr/src2/destdir.i386/usr --enable-tls --disable-multilib --disable-symvers --disable-libstdcxx-pch --build=x86_64-unknown-netbsd5.99.56 --host=i486--netbsdelf Thread model: posix gcc version 4.5.3 (NetBSD nb2 20110806) localhost$ uname -a NetBSD localhost.localdomain 6.0_BETA NetBSD 6.0_BETA (GENERIC) i386 -- Xiaofan -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH/RFC] logging timestamps v2
On Sat, May 5, 2012 at 3:18 PM, Hans de Goede wrote: >>> libusbx is already calling pthread_setname_np() for the thread it creates. >> >> But only for OS X I assume... >> > > Sean, maybe it would be an idea for the os dependent code to print a > thread "name" + id when creating a thread and debugging is enabled, > this way a user can easily find which thread-id is which thread > in the logs? > Maybe this is a good idea. NetBSD also has pthread_getname_np(). http://www.daemon-systems.org/man/pthread_getname_np.3.html -- Xiaofan -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] USB port number
On Sat, May 5, 2012 at 1:02 AM, Tim Roberts wrote: > Janko Kolar wrote: >> I am new to libusbx and I have one basic question >> >> I would like to determine to which usb port particular device is attached. > > Why? Of what possible use is this information? USB hubs are not > externally labeled. If I tell you "you are in port 3", what good does > that do you? > Many users ask for this feature. Probably they would label the port with a marker pen once they know which post is Port 3. :-) There is a recent discussion in the linux-usb mailing list and indeed there are some rules at least. http://comments.gmane.org/gmane.linux.kernel/1285168 -- Xiaofan -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
[Libusbx-devel] Fwd: problems with libusb_get_string_descriptor()
This may be good to be indexed in the libusbx mailing list as well.
Whole thread:
http://libusb.6.n5.nabble.com/FreeBSD-libusb-missing-libusb-get-descriptor-td5689243.html
Regards,
Xiaofan
-- Forwarded message --
From: Peter Stuge
Date: Mon, May 7, 2012 at 10:47 PM
Subject: Re: FreeBSD libusb missing libusb_get_descriptor()
To: libusb-de...@lists.sourceforge.net
Xiaofan Chen wrote:
> > Maybe you want to import some of those checks
> > for the input parameters to this function.
>
> Thanks. Indeed the check may be good.
>
> Let's see Peter's view on this.
Mh, I actually don't think so. I'll explain:
> FreeBSD's implementation:
> 296 int
> 297 libusb_get_string_descriptor(libusb_device_handle *pdev,
> 298 uint8_t desc_index, uint16_t langid, unsigned char *data,
> 299 int length)
> 300 {
> 301 if (pdev == NULL || data == NULL || length < 1)
> 302 return (LIBUSB_ERROR_INVALID_PARAM);
Checking pdev and data is consistently not done in libusb - if you
pass garbage then you get a crash. libusb wants to be thin.
The USB 2.0 spec doesn't say that wLength=0 is invalid, so I think we
should let that go down to the device if for whatever reason someone
requests it.
> 304 if (length > 65535)
> 305 length = 65535;
libusb-1.0 casts to uint16_t, which also truncates the value. The
real error is that the API doesn't use uint16_t for the length, but
that can't be fixed until next API.
> 307 /* put some default data into the destination buffer */
> 308 data[0] = 0;
I'd rather not do this either, I don't think it's libusb's business
to mess with the data, and 0 for descriptor length doesn't make so
much sense.. The return value needs to be checked, and this is just
one special case of the sync API, where the actual length is never
available anyway. :\
> 1369 int LIBUSB_CALL
> libusb_get_string_descriptor_ascii(libusb_device_handle *dev,
> 1370 uint8_t desc_index, unsigned char *data, int length);
This function could very well need some love, and actually it would
be nice to do something more intelligent than only support ASCII
contents, such as libusb_get_string_descriptor_utf8(), but it could
also be nice to offer an API which ties nicely into some or many
different character set conversion libraries..
//Peter
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Fwd: problems with libusb_get_string_descriptor()
I'll just add my opinion on parameter checking...
Anyone remember the "User Application Error" that old Windows versions used
to pop up? It was Microsoft's attempt to deflect blame for exactly the
same kind of crash in the Windows environment - most likely the user had
passed in a bad pointer (of course sometimes it was Microsoft's fault, but
not usually). The point here is if a program crashes in libusb, libusb
gets the blame. Doesn't matter if it was a null pointer from the
application, crash in libusb, libusb gets blamed.
Modern CPUs are so fast, there is no excuse not to check pointers or
handles for/to your own data structures. It's simply defensive
programming. So, in the example below, there is no excuse not to check
pdev. A pointer that's passed down into the OS untouched by libusb? No
need to check that as long as the OS doesn't do anything nasty (where nasty
is a fault rather than an invalid parameter, EFAULT or similar return).
Orin.
On Mon, May 7, 2012 at 8:01 PM, Xiaofan Chen wrote:
> This may be good to be indexed in the libusbx mailing list as well.
>
> Whole thread:
>
> http://libusb.6.n5.nabble.com/FreeBSD-libusb-missing-libusb-get-descriptor-td5689243.html
>
> Regards,
> Xiaofan
>
>
> -- Forwarded message --
> From: Peter Stuge
> Date: Mon, May 7, 2012 at 10:47 PM
> Subject: Re: FreeBSD libusb missing libusb_get_descriptor()
> To: libusb-de...@lists.sourceforge.net
>
>
> Xiaofan Chen wrote:
> > > Maybe you want to import some of those checks
> > > for the input parameters to this function.
> >
> > Thanks. Indeed the check may be good.
> >
> > Let's see Peter's view on this.
>
> Mh, I actually don't think so. I'll explain:
>
>
> > FreeBSD's implementation:
> > 296 int
> > 297 libusb_get_string_descriptor(libusb_device_handle *pdev,
> > 298 uint8_t desc_index, uint16_t langid, unsigned char *data,
> > 299 int length)
> > 300 {
> > 301 if (pdev == NULL || data == NULL || length < 1)
> > 302 return (LIBUSB_ERROR_INVALID_PARAM);
>
> Checking pdev and data is consistently not done in libusb - if you
> pass garbage then you get a crash. libusb wants to be thin.
>
> The USB 2.0 spec doesn't say that wLength=0 is invalid, so I think we
> should let that go down to the device if for whatever reason someone
> requests it.
>
>
> > 304 if (length > 65535)
> > 305 length = 65535;
>
> libusb-1.0 casts to uint16_t, which also truncates the value. The
> real error is that the API doesn't use uint16_t for the length, but
> that can't be fixed until next API.
>
>
> > 307 /* put some default data into the destination buffer */
> > 308 data[0] = 0;
>
> I'd rather not do this either, I don't think it's libusb's business
> to mess with the data, and 0 for descriptor length doesn't make so
> much sense.. The return value needs to be checked, and this is just
> one special case of the sync API, where the actual length is never
> available anyway. :\
>
>
> > 1369 int LIBUSB_CALL
> > libusb_get_string_descriptor_ascii(libusb_device_handle *dev,
> > 1370 uint8_t desc_index, unsigned char *data, int length);
>
> This function could very well need some love, and actually it would
> be nice to do something more intelligent than only support ASCII
> contents, such as libusb_get_string_descriptor_utf8(), but it could
> also be nice to offer an API which ties nicely into some or many
> different character set conversion libraries..
>
>
> //Peter
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> libusbx-devel mailing list
> libusbx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libusbx-devel
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH/RFC] logging timestamps v3
On Mon, May 7, 2012 at 11:16 PM, Pete Batard wrote: > On 2012.05.07 15:47, Pete Batard wrote: >> On 2012.05.07 14:40, Xiaofan Chen wrote: >>> As per Matin (the author of the OpenBSD backend), you can >>> use the getthrid() syscall that returns a pid_t. >> >> Great. I'll give it a try and if it works, add it for the release. > > Seems to require linking against rthread and possibly some kernel > options that may not be enabled. I can't seem to find a linkable version > of getthrid() on the system I have, and issuing a syscall with > SYS_getthrid, which is defined in syscall.h, always returns -1... > I will check with Martin again on this topic. On the other hand, I think the enhancement on BSDs and Mac OS X side can be done later and the current implementation is good enough for 1.0.11 release. -- Xiaofan -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
