In the case where the input unit was not in the array, the for loop would
complete, but the following test would then read past the end of the array
since 'i' would already have been incremented to the array size.
Spotted because unitless data was getting SI prefixes with no unit, though
this would not have been deterministically reproducible.
This fixes parts of bug #950.
The comment says "A requested value is certainly on the way", but the code no
longer works this way. The receive handler requests a value and blocks until
it is received. There is no value pending between receive handler calls, so
this code now only leads to a timeout.
Applications might pass NULL for the buffer, and input modules might
accept it (or just cope). Eliminate a potential NULL dereference in
the emission of diagnostics messages.
On Windows, this device can either enumerate as 04b4:6022 or 04b5:6022,
depending on which vendor driver is currently being used, so we have to
support both in the hantek-6xxx driver as well.
This fixes bug #918.
This is happening because the send() and recv() functions
have different prototypes on POSIX and Windows. Using the casts
is required on Windows and doesn't hurt on POSIX systems.
[...]/protocol.c: In function 'tcp_send':
[...]/protocol.c:161:26: warning: pointer targets in passing argument 2 of 'send' differ in signedness [-Wpointer-sign]
out = send(tcp->socket, buf, len, 0);
^
In file included from [...]/protocol.c:24:0:
[...]/include/winsock2.h:997:34: note: expected 'const char *' but argument is of type 'const uint8_t * {aka const unsigned char *}'
WINSOCK_API_LINKAGE int WSAAPI send(SOCKET s,const char *buf,int len,int flags);
^
[...]/protocol.c: In function 'ipdbg_la_tcp_receive':
[...]/protocol.c:201:32: warning: pointer targets in passing argument 2 of 'recv' differ in signedness [-Wpointer-sign]
int len = recv(tcp->socket, buf, 1, 0);
^
In file included from [...]/protocol.c:24:0:
[...]/include/winsock2.h:992:34: note: expected 'char *' but argument is of type 'uint8_t * {aka unsigned char *}'
WINSOCK_API_LINKAGE int WSAAPI recv(SOCKET s,char *buf,int len,int flags);
^
[...]/protocol.c: In function 'data_available':
[...]/protocol.c:73:38: error: 'bytes_available' undeclared (first use in this function)
ioctlsocket(tcp->socket, FIONREAD, &bytes_available);
^
[...]/protocol.c:73:38: note: each undeclared identifier is reported only once for each function it appears in
[...]/protocol.c:84:1: warning: no return statement in function returning non-void [-Wreturn-type]
}
^
The fx2lafw(4) driver supports mere logic analyzers as well as mixed
signal devices, but does not support channel group specific device
options. Avoid an error message when channel group device options get
queried, the condition is perfectly legal and non-fatal.
How to reproduce:
$ pulseview -d fx2lafw
$ sigrok-cli -d fx2lafw -g Logic --show
This fixes bug #1267.
The "firmware load failed" message would be even more helpful if users
could learn which firmware file failed to load. Add those filenames to
various FX2-based drivers.
This addresses bug #1262.
As per Daniel Anselmi <danselmi@gmx.ch> in an email conversation, the
code was actually written by Eva Kissling <eva.kissling@bluewin.ch>
(as indicated in the commit logs as well). Fix the headers accordingly.
Use "ipdbg-la" everywhere to refer to the driver, including
in function name prefixes etc. There's no need to encode
website details (.org) into the driver/function name(s).
Martin Ling
Uwe Hermann
Andrej Valek
Soeren Apel
Gerhard Sittig
Eva Kissling