If the Cygwin dll's architecture is different from the host system's
architecture, append an additional tag that indicates the host system
architecture (the Cygwin dll's architecture is already indicated in
machine).
Signed-off-by: Jeremy Drake <cygwin@jdrake.com>
This was already used in the FAST_CWD check, and could be used in a
couple other places.
I found the "emulated"/process value returned from the function largely
useless, so I did not cache it. It is useless because, as the docs say,
it is set to IMAGE_FILE_MACHINE_UNKNOWN (0) if the process is not
running under WOW64, but Microsoft also doesn't consider x64-on-ARM64 to
be WOW64, so it is set to 0 regardless if the process is ARM64 or x64.
You can tell the difference via
GetProcessInformation(ProcessMachineTypeInfo), but for the current
process even that's overkill: what we really want to know is the
IMAGE_FILE_MACHINE_* constant for the Cygwin dll itself, which is
conveniently located in memory already, so cache that in wincap also for
easy comparisons.
Signed-off-by: Jeremy Drake <cygwin@jdrake.com>
Return new nice value instead of 0 on success.
Set errno to EPERM instead of EACCES on failure.
Signed-off-by: Christian Franke <christian.franke@t-online.de>
In _cygtls::handle_SIGCONT(), the sig thread waits for the main thread
to process the signal without unlocking the TLS area. This causes a
deadlock if the main thread tries to acquire a lock for the TLS area
in the meantime. With this patch, unlock the TLS before calling yield()
in handle_SIGCONT().
Addresses: https://cygwin.com/pipermail/cygwin/2024-November/256744.html
Fixes: 26158dc3e9c2("* exceptions.cc (sigpacket::process): Lock _cygtls area of thread before accessing it.")
Reported-by: Christian Franke <Christian.Franke@t-online.de>
Reviewed-by: Corinna Vinschen <corinna@vinschen.de>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
Previously, the retry flag was always set when pending_signal::pending()
was called. However, if the queue is empty sig thread tries to flush
the queue even though it is not necessary. With this patch, the retry
flag is set only if the queue is not empty.
Addresses: https://cygwin.com/pipermail/cygwin/2024-November/256744.html
Fixes: 5e31c80e4e ("(pending_signals::pending): Force an additional loop through wait_sig by setting retry whenever this function is called.")
Reported-by: Christian Franke <Christian.Franke@t-online.de>
Reviewed-by: Corinna Vinschen <corinna@vinschen.de>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
With the previous code, the queued signal is tried to resend only when
a new signal arrives or pending_signals::pending() is called.
With this patch, if the signal is queued and the retry flag is not set
and the new signal is not received yet, the sig thread tries to handle
the queued signal again. Without this patch, the chance to handle the
queue would be delayed.
Addresses: https://cygwin.com/pipermail/cygwin/2024-November/256744.html
Fixes: 5e31c80e4e ("(pending_signals::pending): Force an additional loop through wait_sig by setting retry whenever this function is called.")
Reported-by: Christian Franke <Christian.Franke@t-online.de>
Reviewed-by: Corinna Vinschen <corinna@vinschen.de>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
Previously, a deadlock happened if many SIGSTOP/SIGCONT signals were
received rapidly. If the main thread sends __SIGFLUSH at the timing
when SIGSTOP is handled by the sig thread, but not is handled by the
main thread yet (sig_handle_tty_stop() not called yet), and if SIGCONT
is received, the sig thread waits for cygtls::current_sig (is SIGSTOP
now) cleared. However, the main thread waits for the pack.wakeup using
WaitForSingleObject(), so the main thread cannot handle SIGSTOP. This
is the mechanism of the deadlock. This patch uses cygwait() instead of
WaitForSingleObject() to be able to handle the pending SIGSTOP.
Addresses: https://cygwin.com/pipermail/cygwin/2024-November/256744.html
Fixes: 7759daa979 ("(sig_send): Fill out sigpacket structure to send to signal thread rather than racily sending separate packets.")
Reported-by: Christian Franke <Christian.Franke@t-online.de>
Reviewed-by: Corinna Vinschen <corinna@vinschen.de>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
Behave like sched_setparam() if the requested policy is identical
to the fixed value (SCHED_FIFO) returned by sched_getscheduler().
Fixes: 9a08b2c02e ("* sched.cc: New file. Implement sched*.")
Signed-off-by: Christian Franke <christian.franke@t-online.de>
Windows silently sets a lower priority than requested if the new priority
requires administrator privileges. Revert to previous priority and fail
with EACCES or EPERM in this case.
Signed-off-by: Christian Franke <christian.franke@t-online.de>
It appears this is causing hangs on native x86_64 in similar scenarios
as the hangs on ARM64, because `CancelSynchronousIo` is returning `TRUE`
but not canceling the `ReadFile` call as expected.
Addresses: https://github.com/msys2/MSYS2-packages/issues/4340#issuecomment-2491401847
Fixes: b091b47b9e ("cygthread: suspend thread before terminating.")
Signed-off-by: Jeremy Drake <cygwin@jdrake.com>
The currently handled signal in a thread is called _cygtls::sig.
The variable name "sig" is used pretty often in the Cygwin source.
This makes it tricky to distinguish the currently handled signal
from any other usage of "sig".
Therefore, rename _cygtls::sig to _cygtls::current_sig
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Previously, two bugs exist in sigtimedwait(). One is, that since
_my_tls.sigwait_mask was left non-zero if the signal arrives after
the timeout, sigpacket::process() would wrongly try to handle it.
The other is if a timeout occurs after sigpacket::process() is
called, but not completed yet, the signal handler can be called
accidentally. If the signal handler is set to SIG_DFL or SIG_IGN,
access violation will occur in both cases.
With this patch, in sigwait_common(), check if sigwait_mask == 0
to confirm that sigpacket::process() cleared it. In this case,
do not treat WAIT_TIMEOUT, but call cygwait() again to retrieve
the signal. Furthermore, sigpacket::process() checks whether
timeout occurs in sigwait_common() and if timeout already happens,
do not treat the signal as waited. In both cases, to avoid race
issues, the code is guarded by cygtls::lock().
Addresses: https://cygwin.com/pipermail/cygwin/2024-November/256762.html
Fixes: 24ff42d79a ("Cygwin: Implement sigtimedwait")
Reported-by: Christian Franke <Christian.Franke@t-online.de>
Reviewed-by: Corinna Vinschen <corinna@vinschen.de>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
The following debug message occassionally shows up in strace output:
SetThreadName: SetThreadDescription() failed. 00000000 10000000
The HRESULT of 0x10000000 is not an error, rather the set bit just
indicates that this HRESULT has been created from an NTSTATUS value.
Use the IS_ERROR() macro instead of just checking for S_OK.
Fixes: d4689b99c6 ("Cygwin: Set threadnames with SetThreadDescription()")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Currently, create_lock_obj() can create multiple locks with the same
lock range that have different version number. However, lf_setlock()
and lf_clearlock() cannot handle this case appropriately. With this
patch, make lf_setlock() and lf_clearlock() find overlap again even
when ovcase = 1 (lock and overlap have the same lock range).
Addresses: https://cygwin.com/pipermail/cygwin/2024-November/256750.html
Fixes: 2e560a092c ("* flock.cc (LOCK_OBJ_NAME_LEN): Change to accommodate extra lf_ver field.")
Reported-by: Sebastian Feld <sebastian.n.feld@gmail.com>
Reviewed-by: Corinna Vinschen <corinna@vinschen.de>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
The commit ae181b0ff1 has a bug that the pointer is referred bofore
NULL check in the function lf_clearlock(). This patch fixes that.
Addresses: https://cygwin.com/pipermail/cygwin/2024-November/256750.html
Fixes: ae181b0ff1 ("Cygwin: lockf: Make lockf() return ENOLCK when too many locks")
Reported-by: Sebastian Feld <sebastian.n.feld@gmail.com>
Reviewed-by: Corinna Vinschen <corinna@vinschen.de>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
This addresses an extremely difficult to debug deadlock when running
under emulation on ARM64.
A relatively easy way to trigger this bug is to call `fork()`, then within the
child process immediately call another `fork()` and then `exit()` the
intermediate process.
It would seem that there is a "code emulation" lock on the wait thread at
this stage, and if the thread is terminated too early, that lock still exists
albeit without a thread, and nothing moves forward.
It seems that a `SuspendThread()` combined with a `GetThreadContext()`
(to force the thread to _actually_ be suspended, for more details see
https://devblogs.microsoft.com/oldnewthing/20150205-00/?p=44743)
makes sure the thread is "booted" from emulation before it is suspended.
Hopefully this means it won't be holding any locks or otherwise leave
emulation in a bad state when the thread is terminated.
Also, attempt to use `CancelSynchonousIo()` (as seen in `flock.cc`) to avoid
the need for `TerminateThread()` altogether. This doesn't always work,
however, so was not a complete fix for the deadlock issue.
Addresses: https://cygwin.com/pipermail/cygwin-developers/2024-May/012694.html
Signed-off-by: Jeremy Drake <cygwin@jdrake.com>
Provide libaio.a for those projects (such as stress-ng) checking for
POSIX aio support by looking for this library at configure time.
A release note is provided for Cygwin 3.6.0.
Signed-off-by: Mark Geisert <mark@maxrnd.com>
Fixes: N/A (new code)
The pointer pfni gets allocated the buffer at the begin,
and is used in the NtQueryDirectoryFile call before the loops.
In the loop the pointer pfni is also used as iterator.
Therefore it holds no longer the initial buffer at the call
to NtQueryDirectoryFile in the while conditition at the bottom.
Fixes: 28fa2a72f8 ("* syscalls.cc (check_dir_not_empty): Check surplus directory entries")
Co-authored-by: Corinna Vinschen <corinna@vinschen.de>
Signed-off-by: Bernhard Übelacker <bernhardu@mailbox.org>
Change the first parameter of pthread_sigqueue() to be a thread id rather
than a thread pointer. The change is to match the Linux implementation of
this function.
The user-visible function prototype is changed in include/pthread.h.
The pthread_sigqueue() function is modified to work with a passed-in thread
id rather than an indirect thread pointer as before. (It used to be
"pthread_t *thread", i.e., class pthread **.) The release note for Cygwin
3.5.5 is updated.
Reported-by: Christian Franke <Christian.Franke@t-online.de>
Addresses: https://cygwin.com/pipermail/cygwin/2024-September/256439.html
Signed-off-by: Mark Geisert <mark@maxrnd.com>
Fixes: 50350cafb3 ("* cygwin.din (pthread_sigqueue): Export.")
This commit revises `pthread_cleanup_push` and `pthread_cleanup_pop`
macros to use a `do { ... } while(0)` wrapper, preventing syntax errors
when used in certain contexts. The original code could fail when they
are wrapped within a `do { ... } while(0)`, causing unintended behavior
or compilation issues.
Example of error:
#include <pthread.h>
#define pthread_cleanup_push_wrapper(_fn, _arg) do { \
pthread_cleanup_push(_fn, _arg); \
} while (0)
#define pthread_cleanup_pop_wrapper(_execute) do { \
pthread_cleanup_pop(_execute); \
} while (0)
void cleanup_fn (void *arg) {}
void *thread_func (void *arg)
{
pthread_cleanup_push_wrapper(cleanup_fn, NULL);
pthread_cleanup_pop_wrapper(1);
return NULL;
}
int main (int argc, char **argv) {
pthread_t thread_id;
pthread_create(&thread_id, NULL, thread_func, NULL);
}
This would fail due to unmatched braces in the macro expansion. The new
structure ensures the macro expands correctly in all cases.
Fixes: 007276b30e ("* cygwin.din: Add _pthread_cleanup_push and _pthread_cleanup_pop.")
Signed-off-by: Shaobo Song <shnusongshaobo@gmail.com>
Previously, the condition to clean up input/output mode was based
on wrong premise. This patch fixes that.
Fixes: 8ee8b0c974 ("Cygwin: console: Use GetCurrentProcessId() instead of myself->dwProcessId")
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
The commit 90ddab9878 uses myself->dwProcessId to get windows pid.
However, it will be overridden in stub process if exec() is called.
With this patch, GetCurrentProcessId() instead of myself->dwProcessId.
Fixes: 90ddab9878 ("Cygwin: console: Re-fix open() failure on exec() by console owner")
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
Previous fix (commit df0953aa29) fixes only a part of the problem.
Since exec() overrides the cygwin pid of the caller process, it makes
console owner handling complex. This patch makes console use Windows
pid as the owner pid (con.owner) instead of cygwin pid to make the
handling simpler.
Fixes: df0953aa29 ("Cygwin: console: Fix open() failure when the console owner calls exec().")
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
If the write length is more than the pipe space in non-blocking
mode, the write length is wrongly set to 65536. This causes access
violation. This patch fixes that.
Fixes: 7ed9adb356 ("Cygwin: pipe: Switch pipe mode to blocking mode by default")
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
Currently, open() tries to attach to the console which is owned by
the console owner process. However, when the owner process calls
exec(), AttachConsole() to dwProcessId may sometimes fail due to
unlucky timing. With this patch, open() tries to attach also to
exec_dwProcessId if attaching to dwProcessId fails. That is, open()
tries to attach to both the stub process and target process to
prevent the above situation.
Fixes: 3721a756b0 ("Cygwin: console: Make the console accessible from other terminals.")
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
Previously, sigfe had a bug that the signal handler destroys fpu state.
This is caused by fninit instruction in sigdelayed. With this patch,
saving/restoring the FPU/SIMD state is done using fxsave/fxrstor or
xsave/xrstor rather than fnstcw/fldcw, stmxcsr/ldmxcsr and push/pop
xmm0-xmm15. Since xsave/xrstor is used, not only x87/MMX/SSE states
but also AVX/AVX2/AVX-512 states can be maintained unlike before.
Addresses: https://cygwin.com/pipermail/cygwin/2024-October/256503.html
Fixes: ed89fbc3ff ("* gendef (sigdelayed (x86_64)): Save and restore FPU control word.")
Reported-by: Christian Franke <Christian.Franke@t-online.de>
Suggested-by: Brian Inglis <Brian.Inglis@SystematicSW.ab.ca>
Reviewed-by: Corinna Vinschen <corinna@vinschen.de>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
Previously, cygwin read pipe used non-blocking mode although non-
cygwin app uses blocking-mode by default. Despite this requirement,
if a cygwin app is executed from a non-cygwin app and the cygwin
app exits, read pipe remains on non-blocking mode because of the
commit fc691d0246. Due to this behaviour, the non-cygwin app
cannot read the pipe correctly after that. Similarly, if a non-
cygwin app is executed from a cygwin app and the non-cygwin app
exits, the read pipe mode remains on blocking mode although cygwin
read pipe should be non-blocking mode.
These bugs were provoked by pipe mode toggling between cygwin and
non-cygwin apps. To make management of pipe mode simpler, this
patch has re-designed the pipe implementation. In this new
implementation, both read and write pipe basically use only blocking
mode and the behaviour corresponding to the pipe mode is simulated
in raw_read() and raw_write(). Only when NtQueryInformationFile
(FilePipeLocalInformation) fails for some reasons, the raw_read()/
raw_write() cannot simulate non-blocking access. Therefore, the pipe
mode is temporarily changed to non-blocking mode.
Moreover, because the fact that NtSetInformationFile() in
set_pipe_non_blocking(true) fails with STATUS_PIPE_BUSY if the pipe
is not empty has been found, query handle is not necessary anymore.
This allows the implementation much simpler than before.
Addresses: https://github.com/git-for-windows/git/issues/5115
Fixes: fc691d0246 ("Cygwin: pipe: Make sure to set read pipe non-blocking for cygwin apps.");
Reported-by: isaacag, Johannes Schindelin <Johannes.Schindelin@gmx.de>
Reviewed-by: Corinna Vinschen <corinna@vinschen.de>, Ken Brown <kbrown@cornell.edu>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
The expression computing the next-less-power of 2 for the next write
when the pipe buffer is getting filled up allows negative shift values.
This works on Intel CPUs because the shift expression only evaluates the
5 LSBs, but it's undefined behaviour per the C standard. Use the
correct expression to get a positive shift value.
Fixes: 170e6badb6 ("Cygwin: pipe: improve writing when pipe buffer is almost full")
Reported-by: Takashi Yano <takashi.yano@nifty.ne.jp>
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
There was a long-standing issue that pseudo console ownership could
not hand over from the process whose ctty is /dev/cons* rather than
/dev/pty*. This problem happens when a cygwin app starts non-cygwin
app in a pty, then the non-cygwin app starts multiple cygwin apps,
and the non-cygwin app ends before the second cygwin apps end.
In this case, the stub process of the non-cygwin app hands over the
ownership of pcon to one of the second cygwin apps, however, this
app does not hand over the ownership of pcon to another second
cygwin app. This is due to the fact that the hand-over feature is
implemented only in fhandler_pty_slave but not in fhandler_console.
With this patch, the second cygwin apps check if their console device
is inside a pseudo console, and if so, it tries to hand over the
ownership of the pseudo console to anther process that is attached
to the same pseudo console.
Addresses: https://cygwin.com/pipermail/cygwin/2024-February/255388.html
Fixes: 253352e796 ("Cygwin: pty: Allow multiple apps to enable pseudo console simultaneously.")
Reported-by: lmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>, Hossein Nourikhah <hossein@libreoffice.org>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
Previously, lockf() printed a warning message when the number of locks
per file exceeds the limit (MAX_LOCKF_CNT). This patch makes lockf()
return ENOLCK in that case rather than printing the warning message.
Addresses: https://cygwin.com/pipermail/cygwin/2024-October/256528.html
Fixes: 31390e4ca6 ("(inode_t::get_all_locks_list): Use pre-allocated buffer in i_all_lf instead of allocating every lock. Return pointer to start of linked list of locks.")
Reported-by: Christian Franke <Christian.Franke@t-online.de>
Reviewed-by: Corinna Vinschen <corinna@vinschen.de>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
Previously, adding a new lock by lockf() over multiple existing locks
failed. This is due to a bug that lf_setlock() tries to create a lock
that has already been created. This patch fixes the issue.
Addresses: https://cygwin.com/pipermail/cygwin/2024-October/256528.html
Fixes: a998dd7055 ("* flock.cc: Implement all advisory file locking here.")
Reported-by: Christian Franke <Christian.Franke@t-online.de>
Reviewed-by: Corinna Vinschen <corinna@vinschen.de>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
timer_delete() always returned failure. This issue has been
detected by 'stress-ng --hrtimers 1'.
Fixes: 229ea3f23c ("Cygwin: posix timers: reimplement using OS timer")
Signed-off-by: Christian Franke <christian.franke@t-online.de>
If the parent process has already used pread() or pwrite(), these
functions fail with EBADF if used on the inherited fd. Ensure that
fix_after_fork() is called to invalidate the prw_handle. This issue
has been detected by 'stress-ng --pseek 1'.
Fixes: c36cd56c54 ("* fhandler.cc (fhandler_base::open): Drop local create_options variable.")
Signed-off-by: Christian Franke <christian.franke@t-online.de>
After the commit 7f3c225325, writing to pipe extremely slows down.
This is because cygwait(select_sem, 10, cw_cancel) is called even
when write operation is already completed. With this patch, the
cygwait() is called only if the write operation is not completed.
Addresses: https://cygwin.com/pipermail/cygwin/2024-August/256398.html
Fixes: 7f3c225325 ("Cygwin: pipe: handle signals explicitely in raw_write")
Reported-by: Jim Reisert AD1C <jjreisert@alum.mit.edu>
Reviewed-by: Corinna Vinschen <corinna@vinschen.de>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
When win32-input-mode (which is supported by Windows Termainal) is
set by "\033[?9001h", cons_master_thread does not work properly and
consumes larger and larger memory space. This is because sending
event by WriteConsoleInput() is translated into the sequence that
is used by win32-input-mode. Due to this behaviour, write-back
of the INPUT_RECORDs does not work as expected. With this patch,
cons_master_thread is disabled on win32-input-mode where the signal
keys such as Ctrl-C, Ctrl-Z etc. never comes.
Addresses: https://cygwin.com/pipermail/cygwin/2024-August/256380.html
Fixes: ff4440fcf7 ("Cygwin: console: Introduce new thread which handles input signal.")
Reported-by: Adamyg Mob <adamyg.mob@gmail.com>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
If a nonblocking write requires short writes, just try it once
as in the blocking case. After all, we are nonblocking, so
don't loop unnecessarily.
Fixes: 170e6badb6 ("Cygwin: pipe: improve writing when pipe buffer is almost full")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
There's no reason to overwrite len1 with align if they are the same value.
Fixes: 170e6badb6 ("Cygwin: pipe: improve writing when pipe buffer is almost full")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
So far fhandler_pipe_fifo::raw_write always returns -1/EINTR
if a signal arrived. Linux does not do that if there's still
space left in the pipe buffer.
The Linux buffer handling can't be emulated by Cygwin, but we
can do something similar which makes it much more likely to still
write successfully even if the buffer is almost full.
Utilize pipe_data_available to return valid pipe buffer usage
to raw_write, allowing a more sophisticated way to fill the
buffer while maintaining comaptibility with non-Cygwin pipes.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Linux select(2) returns the pipe as writable if at least one
free page (4K onl most systems) is left in a page-oriented buffer
handling. This is the same as PIPE_BUF.
Emulate this behaviour by only returning the pipe as writable
if at least 4K space is left in the buffer.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
The simple cygwait call in fhandler_pipe_fifo::raw_write doesn't
take the SA_RESTART setting into account. Move handling the
signal into raw_write.
Fixes: 4b25687ea3 ("Cygwin: fhandler_pipe: add raw_read and raw_write")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Rewrite to avoid new use-after-free warnings about realloc(), seen with
gcc 12, e.g.:
> In function ‘void rebase_locale_buf(const void*, const void*, const char*, const char*, const char*)’,
> inlined from ‘int __set_lc_time_from_win(const char*, const lc_time_T*, lc_time_T*, char**, wctomb_p, const char*)’ at ../../../../src/winsup/cygwin/nlsfuncs.cc:705:25:
> ../../../../src/winsup/cygwin/nlsfuncs.cc:338:24: error: pointer ‘new_lc_time_buf’ may be used after ‘void* realloc(void*, size_t)’ [-Werror=use-after-free]
> 338 | *ptrs += newbase - oldbase;
> | ~~~~~~~~^~~~~~~~~
> ../../../../src/winsup/cygwin/nlsfuncs.cc: In function ‘int __set_lc_time_from_win(const char*, const lc_time_T*, lc_time_T*, char**, wctomb_p, const char*)’:
> ../../../../src/winsup/cygwin/nlsfuncs.cc:699:44: note: call to ‘void* realloc(void*, size_t)’ here
> 699 | char *tmp = (char *) realloc (new_lc_time_buf, len);
Technically, it's UB to later refer to the realloced pointer (even just
for offset computations, without deferencing it), so switch to using
malloc() to create the resized copy.
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Jeremy Drake
Christian Franke
Takashi Yano
Corinna Vinschen
Mark Geisert
Bernhard Übelacker
Shaobo Song
Lenard Mollenkopf
Jon Turney