Commit 3c75fac130b5 fixed the __restrict definition in sys/cdefs.h,
but uncovered a problem in the definition of lio_listio in Cygwin's
aio.h. It uses the C99 extension of using the restrict keyword
to define non-overlapping arrays. However, this is not allowed in
C++.
Use the newly defined __restrict_arr from commit e66c63be6b80
("sys/cdefs.h: introduce __restrict_arr, as in glibc")
Fixes: 3c75fac130b5 ("sys/cdefs.h: fix for use __restrict in C++"
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Per C++11, uchar16_t and uchar32_t are defined the same as
uint_least16_t and uint_least32_t. Also, check for the C++
version to make sure that the types are not colliding with
predefined c++ types.
Fixes: 4f258c55e87f ("Cygwin: Add ISO C11 functions c16rtomb, c32rtomb, mbrtoc16, mbrtoc32.")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Add uchar.h accordingly.
For the c32 functions, use the internal functions wirtomb and mbrtowi
as base, and convert wirtomb and mbrtowi to inline functions calling
the c32 functions.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Commit c743751aafa84 ("Cygwin: Export
posix_spawn_file_actions_add{f}chdir_np")
added two new functions but we forgot to bump the API version.
Catch up.
Fixes: c743751aafa84 ("Cygwin: Export posix_spawn_file_actions_add{f}chdir_np")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
The current version of <sys/cpuset.h> cannot be compiled by Clang due to
the use of builtin versions of malloc, free, and memset. Their presence
here was a dubious optimization anyway, so their usage has been
converted to standard library functions.
The use of __builtin_popcountl remains because Clang implements it just
like gcc does. If/when some other compiler (Rust? Go?) runs into this
issue we can deal with specialized handling then.
The "#include <sys/cdefs>" here to define __inline can be removed since
both of the new includes sub-include it.
Addresses: https://cygwin.com/pipermail/cygwin/2023-July/253927.html
Fixes: 9cc910dd33a5 (Cygwin: Make <sys/cpuset.h> safe for c89 compilations)
Signed-off-by: Mark Geisert <mark@maxrnd.com>
Four modifications to include/sys/cpuset.h:
* Change C++-style comments to C-style also supported by C++
* Change "inline" to "__inline" on code lines
* Add "#include <sys/cdefs.h>" to make sure __inline is defined
* Don't declare loop variables on for-loop init clauses
Tested by first reproducing the reported issue with home-grown test
programs by compiling with gcc option "-std=c89", then compiling again
using the modified <sys/cpuset.h>. Other "-std=" options tested too.
Addresses: https://cygwin.com/pipermail/cygwin-patches/2023q3/012308.html
Fixes: 315e5fbd99ec ("Cygwin: Fix type mismatch on sys/cpuset.h")
Signed-off-by: Mark Geisert <mark@maxrnd.com>
Addresses https://cygwin.com/pipermail/cygwin/2023-March/253220.html
Take the opportunity to follow FreeBSD's and Linux's lead in recasting
macro inline code as calls to static inline functions. This allows the
macros to be type-safe. In addition, added a lower bound check to the
functions that use a cpu number to avoid a potential buffer underrun on
a bad argument. h/t to Corinna for the advice on recasting.
Fixes: 362b98b49af5 ("Cygwin: Implement CPU_SET(3) macros")
Until Cygwin 3.3.6, we define __LARGE64_FILES unconditionally, so we
were using the type __sFILE64 even for 64 bit. That was lazy and wrong.
so commit 2902b3a09e0a ("Cygwin: drop requirement to build newlib's
stdio64") tried to fix that.
Unfortunately this patch forgot to take the exposure of the typename
__sFILE64 in userspace into account. This leads to trouble in C++ due
to name mangling.
Commit 0f376ae22036 tried to fix this by just renaming __sFILE to
__sFILE64 by using a macro. While __sFILE and __sFILE64 are the same
size, they are not exactly congruent.
To avoid backward compatibility problems, make sure to define FILE
as the real __sFILE64, and make sure that __sFILE is not defined at
all on Cygwin.
Fixes: 0f376ae22036 ("Cygwin: rename __sFILE to __sFILE64 for backward
compatibility")
Fixes: 2902b3a09e0a ("Cygwin: drop requirement to build newlib's stdio64")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Until Cygwin 3.3.6, we define __LARGE64_FILES unconditionally, so we
were using the type __sFILE64 even for 64 bit. That was lazy and wrong.
so commit 2902b3a09e0a ("Cygwin: drop requirement to build newlib's
stdio64") tried to fix that.
Unfortunately this patch forgot to take the exposure of the typename
__sFILE64 in userspace into account. This leads to trouble in C++ due
to name mangling.
Fix this by redefining __sFILE to __sFILE64. The type name is very much
internal, so it doesn't really matter, except for the fact that it needs
to stay backward compatible so as not to break building against C++ libs
built under older versions of Cygwin.
Fixes: 2902b3a09e0a ("Cygwin: drop requirement to build newlib's stdio64")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Given that 64 bit Cygwin defines all file access types (off_t,
fpos_t, and derived types) as 64 bit anyway, there's no reason
left to rely on the stdio64 part of newlib. Use base functions
and base types.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Define FD_SETSIZE (<sys/select.h>) to be 1024 by default, and define
NOFILE (<sys/param.h>) to be OPEN_MAX (== 3200) by default.
Remove the comment in <sys/select.h> that FD_SETSIZE should be >=
NOFILE.
Bump API minor.
Addresses: https://cygwin.com/pipermail/cygwin/2022-July/251839.html
Commit e1ce752a1d, "Cygwin: remove miscellaneous 32-bit code", removed
most occurrences of '#ifdef __x86_64__'. Restore those occurrences
that guarded code specific to the AMD64 processor, and #error out if
the processor is different. This will make it easier to find
AMD64-specific code if we ever want to add support for a different
64-bit processor (e.g., ARM64).
The _REENT_GLOBAL_STDIO_STREAMS was introduced by commit
668a4c8722090fffd10869dbb15b879651c1370d in 2017. Since then it was enabled by
default for RTEMS. Recently, the option was enabled for Cygwin which
previously used an alternative implementation to use global stdio streams.
In Newlib, the stdio streams are defined to thread-specific pointers
_reent::_stdin, _reent::_stdout and _reent::_stderr. If the option is disabled
(the default for most systems), then these pointers are initialized to
thread-specific FILE objects which use file descriptors 0, 1, and 2,
respectively. There are at least three problems with this:
(1) The thread-specific FILE objects are closed by _reclaim_reent(). This
leads to problems with language run-time libraries that provide wrappers to
the C/POSIX stdio streams (for example C++ and Ada), since they use the
thread-specific FILE objects of the initialization thread. In case the
initialization thread is deleted, then they use freed memory.
(2) Since thread-specific FILE objects are used with a common output device via
file descriptors 0, 1 and 2, the locking at FILE object level cannot ensure
atomicity of the output, e.g. a call to printf().
(3) There are resource managment issues, see:
https://sourceware.org/pipermail/newlib/2022/019558.htmlhttps://bugs.linaro.org/show_bug.cgi?id=5841
This patch enables the _REENT_GLOBAL_STDIO_STREAMS behaviour for all Newlib
configurations and removes the option. This removes a couple of #ifdef blocks.
These have no effect on x86_64. Retain a few occurrences of __cdecl
in files imported from other sources.
Also retain all occurrences of WINAPI, even though the latter is
simply a macro that expands to __stdcall. Most of these occurrences
are associated with Windows API functions, and removing them might
make the code confusing instead of simpler.
Remove "32" or "64" from each of the following names: acl32,
aclcheck32, aclfrommode32, aclfrompbits32, aclfromtext32, aclsort32,
acltomode32, acltopbits32, acltotext32, facl32, fchown32, fcntl64,
fstat64, _fstat64, _fstat64_r, ftruncate64, getgid32, getgrent32,
getgrgid32, getgrnam32, getgroups32, getpwuid32, getpwuid_r32,
getuid32, getuid32, initgroups32, lseek64, lstat64, mknod32, mmap64,
setegid32, seteuid32, setgid32, setgroups32, setregid32, setreuid32,
setuid32, stat64, _stat64_r, truncate64.
Remove prototypes and macro definitions of these names.
Remove "#ifndef __INSIDE_CYGWIN__" from some headers so that the new
names will be available when compiling Cygwin.
Remove aliases that are no longer needed.
Include <unistd.h> in fhandler_clipboard.cc for the declarations of
geteuid and getegid.
Remove the definitions of the following: acl, aclcheck, aclfrommode,
aclfrompbits, aclfromtext, aclsort, acltomode, acltopbits, acltotext,
chown, fchown, _fcntl, fstat, _fstat_r, ftruncate, getegid, geteuid, getgid,
getgrent, getgrgid, getgrnam, getgroups, getpwduid, getpwuid,
getpwuid_r, getuid, initgroups, lacl, lacl32, lchown, lseek, lstat,
mknod, mmap, setegid, seteuid, setgid, setgroups, setregid, setreuid,
setuid, stat, _stat_r, truncate.
[For most of these, the corresponding 64-bit entry points are obtained
by exporting aliases. For example, acl is an alias for acl32, and
truncate is an alias for truncate64.]
Remove the following structs and all code using them (which is 32-bit
only): __stat32, __group16, __flock32, __aclent16_t.
Remove the typedefs of __blkcnt32_t __dev16_t, __ino32_t, which are
used only in code that has been removed.
Put the typedefs of __uid16_t and __gid16_t in one header, instead of
one header if __INSIDE_CYGWIN__ is defined and a different header
otherwise.
This was a hack to begin with. Clean this mess up:
- Move definition of CYGTLS_PADSIZE to cygwin/config.h and drop
local cygtls_padsize.h
- Rename CYGTLS_PADSIZE to __CYGTLS_PADSIZE__ to keep namespace
clean. Redefine as macro, rather than as const.
- Move struct _reent first in struct _cygtls to allow using
__CYGTLS_PADSIZE__ as offset in __getreent().
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
