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.
In platforms 21 and higher of the NDK, linux/serial.h is available,
which it was not before. This broke the build, because the configure
script would detect the availability of 'struct serial_struct' in that
header and set HAVE_STRUCT_SERIAL_STRUCT, but the #ifndef __ANDROID__
in libserialport_internal.h stopped us actually including the header.
This change fixes things to build with all versions of the NDK, and is
tested with builds for arm from versions 9 to 24.
Version 21 also added availability of tcdrain(), so we also use that
where available, and only use the direct ioctl() method on NDK < 21.
Fixes#1078.
serialport.c: In function 'get_time':
serialport.c:64:6: warning: implicit declaration of function 'clock_gettime' [-Wimplicit-function-declaration]
if (clock_gettime(CLOCK_MONOTONIC, &ts) == -1)
^
serialport.c:64:20: error: 'CLOCK_MONOTONIC' undeclared (first use in this function)
if (clock_gettime(CLOCK_MONOTONIC, &ts) == -1)
^
serialport.c:64:20: note: each undeclared identifier is reported only once for each function it appears in
serialport.c:65:17: error: 'CLOCK_REALTIME' undeclared (first use in this function)
clock_gettime(CLOCK_REALTIME, &ts);
^
serialport.c: At top level:
serialport.c:60:13: warning: 'get_time' defined but not used [-Wunused-function]
static void get_time(struct timeval *time)
^
