Error messages of regtool can't be read, which are encoded in,
for instance, SHIFT_JIS in Japanese Windows. Fix by using
wide chars instead of multibyte.
Commit 8a3b3bb4d7 changed the guard on
some functions from _POSIX_THREADS to __POSIX_VISIBLE. As a consequence,
some use of siginfo_t and pthread_t became visible under configurations
where _POSIX_THREADS is unset but __POSIX_VISIBLE is. Build then fails
because the definition of those types are still unavailable.
This commit make those type definition visible for __POSIX_VISIBLE
configurations. This requires moving the siginfo_t definition out of the
RTEMS specific definitions in sys/signal.h while still guarding it
against cygwin case.
When SA_RESTART is not set on a socket, a blocking send() that is
interrupted mid-transition by a signal should return success (and
report just how many bytes were actually transmitted).
The err variable used here was not always guaranteed to be set
correctly in the loop, so better to just remove it and call
WSAGetLastError() explicitly.
There are two common sigpause variants, both of which take an int argument.
If you request _XOPEN_SOURCE or _GNU_SOURCE, you get the System V version,
which removes the given signal from the process's signal mask; otherwise
you get the BSD version, which sets the process's signal mask to the given
value.
Signed-off-by: Yaakov Selkowitz <yselkowi@redhat.com>
While POSIX allows these functions to also be defined as macros in C, in
C++ this is not allowed, and prevents these names (particularly feof) from
being used in a custom namespace.
Signed-off-by: Yaakov Selkowitz <yselkowi@redhat.com>
So far Cygwin's readdir returned the inode number of a mount target
in d_ino, rather than the actual inode number of the mount point in
the underlying filesystem. This not only results in a performance
hit if the mount target is a remote FS, it is also not done on other
POSIX systems.
Remove the code evaluating the mount target inode number.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
This patch fixes a minor compatibility issue w/ cygwin mount point handling in
readdir(), compared to equivalent behavior of Linux and MacOS. dentry.d_ino
should indicate the INO of the mount point itself, not the target volume root
folder.
Changed return type from readdir_check_reparse_point to uint8_t, to avoid
unnecessarily being implicitly cast to and from a signed int.
Renamed a related local variable "attr" to "oattr" that was eclipsing a member
variable with the same name.
Joe L.
For whatever reason FreeBSD renames several functions provided by
<arpa/inet.h> and uses weak references to provide the standard function
names. This causes problems on targets lacking proper support for weak
references. We do not need this function renaming on RTEMS.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
Don't over-read memory returned by _DTOA_R, and never write to it
since the result might be a string literal.
For example, when doing:
swprintf(tt, 20, L"%.*f", 6, 0.0);
we will get back "0".
Instead, write the result returned by _DTOA_R to the output buffer.
After this, write the 0 chars directly to the the output buffer
(if there are any). This also has the (marginal) advantage that
we read/write less memory overall.
According to the FreeBSD man page BIT_CMP() returns true in case the two
sets are NOT equal.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
Mingw-w64 (where the code has been taken from) has 4 byte longs
independently of the architecture but x86_64 Cygwin has 64 bit longs.
So use fistpll instead of fistpl on x86_64 Cygwin.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Workaround a bug (or undocumented behaviour) in LCMapStringW:
It's documented(*) that the cchDest parameter is a byte count with
LCMAP_SORTKEY, but a character count otherwise. But the docs don't
state what happens if you combine LCMAP_SORTKEY with LCMAP_BYTEREV.
Tests indicate that LCMAP_SORTKEY treats cchDest as byte count, but
then LCMAP_BYTEREV treats it as char count in the same call. So the
latter swaps twice as much bytes in the destination buffer than the
byte count it returns, which potentially results in writing past the
end of the given output buffer.
Solution: Don't specify LCMAP_BYTEREV in the LCMapStringW(LCMAP_SORTKEY)
call, rather byte swap afterwards.
(*) https://msdn.microsoft.com/en-us/library/windows/desktop/dd318702(v=vs.85).aspx
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Aditya Upadhyay
Dionna Glaze
Corinna Vinschen
Brian Inglis
Sebastian Pop
Jon Turney
Fujii Hironori
Joe_Lowe
Yaakov Selkowitz
Thomas Preud'homme
Erik M. Bray
Joel Sherrill
Claudiu Zissulescu
Sebastian Huber
Silviu Baranga
David Macek
Prakhar Bahuguna
Kito Cheng