The last release (0.1.1) had the libtool version (current:revision:age)
set to 1:0:1. Since this release doesn't change/remove any
interfaces, 'current' and 'age' remain unchanged and
'revision' is increased, resulting in 1:1:1.
http://www.gnu.org/software/libtool/manual/libtool.html#Updating-version-info
Programs using libserialport don't need to be recompiled or relinked.
These variables are being used to store the result of read/write calls,
which return a ssize_t value, which depending on platform can be bigger
than an int.
This constant is now deprecated since macOS 12.0 and a new constant
named kIOMainPortDefault is provided. There is a fallback in place
that retains compatibility for older macOS versions.
https://developer.apple.com/documentation/iokit/kiomasterportdefault
[ gsi: tweak style to match existing code base ]
termiox was removed from linux in e0efb3168d34
Some more information available in https://www.spinics.net/lists/linux-serial/msg41926.html
Attempting to use the termiox ioctls on more modern kernels results in
"Inappropriate IOCTL" errors.
While the "right" solution might be to remove the termiox code from the
linux path, simply not checking for termiox builds a libserialport that
functions on modern linux kernels.
Signed-off-by: Karl Palsson <karlp@etactica.com>
The comment and code are out of sync. The comments say "leave control
lines alone on close." The HUPCL bit, when set, will "Lower modem control
lines after last process closes the device (hang up)."
To match the intent captured in the comment, the HUPCL bit should be
cleared.
Signed-off-by: Ben Gardiner <ben.l.gardiner@gmail.com>
The above function must always return an 'enum sp_transport'. So, return
NATIVE if no port is present because its effective meaning within the
API is "you shouldn't call any transport-specific functions for this
port handle".
Fixes bug #1531.
Signed-off-by: Wolfram Sang <wsa@kernel.org>
I don't think these two mentions of cygwin ever did anything useful.
In fact they stop libserialport being buildable under cygwin.
The first one caused builds on cygwin to try to build windows.c,
which uses the Win32 API, not the POSIX layer provided by cygwin.
The second asserts that enumeration and port metadata are supported
on cygwin, but that isn't the case.
Without these matches for cygwin as $host_os, libserialport builds
and works just fine on old-school cygwin with the original mingw32.
The only reason that MSYS2 worked better is that it uses "msys" as
the $host_os identifier, not cygwin.
There were two issues: first, feature test macros were only defined
for __linux__, so defintions we needed were not included. Enable the
same feature test macros for __CYGWIN__.
Second, the Cygwin headers do not define TIOCOUTQ, needed to use
ioctl() to get the number of bytes in the output queue. Return
SP_ERR_SUPP on Cygwin for this operation.
This fixes bug #963.
When built with MSVC with unicode enabled, this gave:
warning C4133: 'function': incompatible types - from 'char *' to 'LPCWSTR'
due to CreateFile expanding to CreateFileW which accepts UTF-16 filenames.
The device name used here is in 8-bit format, having come from a call to
wc_to_utf8() in either get_root_hub_name() or get_external_hub_name(). So
we need to use CreateFileA.
Building with MSVC gave:
warning C4267: '=': conversion from 'size_t' to 'USHORT', possible loss of data
The value here is known to be safe for the sizes involved. Add an
explicit cast to suppress the warning.
The result should be safe because we only use this function on time
differences as part of timeout calculations, not on absolute times.
Add an explicit cast to suppress the warning.
Building with MSVC gave:
warning C4244: '=': conversion from 'LONGLONG' to 'long', possible loss of data
when assigning the results of these calculation to the long fields
of struct timeval. The result should be OK, but put an explicit
cast in to make the change clear and suppress the warning.
VS2019 IntelliSense reported:
Warning C6308: 'realloc' might return null pointer: assigning null
pointer to 'port->write_buf', which is passed as an
argument to 'realloc', will cause the original memory
block to be leaked.
This is correct, we would leak the buffer on a realloc failure.
Put the realloc result in a separate variable and handle the error
path before assigning the result to port->write_buf.
When built with MSVC and unicode enabled, using 'message' gave:
warning C4133: 'initializing': incompatible types - from 'TCHAR *' to 'char *'
FormatMessage expands to either FormatMessageA or FormatMessageW
depending if unicode is enabled, and generates either a char (8-bit)
or WCHAR (UTF-16) string accordingly.
Since sp_last_error_message() returns char *, we must use the 8-bit
variant. The message will be encoded in the current code page.
When built with MSVC and unicode enabled, using CreateFile gave:
warning C4133: 'function': incompatible types - from 'char *' to 'LPCWSTR'
CreateFile is a macro expanding to either CreateFileW if unicode
mode is enabled, or CreateFileA if not.
For CreateFileW, the filename is a UTF-16 string. For CreateFileA
it is an 'ANSI' string, meaning 8-bit chars in the current Windows
code page.
We do need to stick to 8-bit strings for port names, since
sp_get_port_by_name() and sp_get_port_name() are defined with
char * types, and that is what we store in struct sp_port. So
CreateFileA is the correct version to use.
Since Windows serial port names are always just 'COM' and a digit,
with a '\\.\' prefix for higher numbers, encoding is fortunately
not an issue - ASCII, UTF-8 and all the Windows code pages seem to
be equivalent for these characters.
We should however explicitly document what the encoding of strings
accepted and returned by libserialport is.
These cases are all in the sp_[non]blocking_{read,write} functions.
On MSVC, these conversions would generate warnings such as:
warning C4267: '=': conversion from 'size_t' to 'DWORD', possible loss of data
The warnings are genuine. There are some places where overflow is technically
possible, due to our use of size_t for sizes in function parameters (unsigned
64-bit on Windows x64), but an enum for return values (typically signed int
and 32-bit, but not guaranteed to be so by the standards), plus the Win32 API
usage of DWORD (unsigned 32-bit) for sizes in ReadFile/WriteFile.
However, overflow in practice would require reading/writing more than 2GB
over a serial port in a single call and is therefore unlikely to be a
real-world concern. I have therefore not tried to catch those cases - but the
places it is possible do now have explicit casts to the smaller types so that
they are more obvious.
We could document and test for a maximum read/write size of INT_MAX, but that
would still depend on the storage of 'enum sp_return' being at least a signed
int, which as I understand it the C standard does not require.
To be absolutely correct we would need a different API where sp_return
was only used for result codes, and the read/write functions took a
pointer to size_t for result sizes.
