On Sat, 3 Feb 2024 at 19:25, Corinna Vinschen wrote:
> > Sorry to say that, but SetThreadErrorMode/CreateProcess don't do what we
> > want them to do. I just tested this myself with a modified Cygwin DLL
> > (code below) and it turns out that the child process error mode is
> > the same as the
On Feb 3 13:39, Corinna Vinschen via Cygwin wrote:
> On Feb 2 19:51, Corinna Vinschen via Cygwin wrote:
> > On Feb 2 18:22, Corinna Vinschen via Cygwin wrote:
> > > On Feb 2 14:56, David Allsopp via Cygwin wrote:
> > > > On Fri, 2 Feb 2024 at 14:18, Corinna Vinschen via Cygwin wrote:
> > > > >
On Fri, 2 Feb 2024, Corinna Vinschen wrote:
> On Feb 2 09:43, David Allsopp via Cygwin wrote:
> > However, this patch came from MSYS2, and subsequently they seem to
> > have found it problematic for the same reason as me
> > (https://github.com/msys2/msys2-runtime/pull/18#issuecomment-810897624)
On Feb 2 19:51, Corinna Vinschen via Cygwin wrote:
> On Feb 2 18:22, Corinna Vinschen via Cygwin wrote:
> > On Feb 2 14:56, David Allsopp via Cygwin wrote:
> > > On Fri, 2 Feb 2024 at 14:18, Corinna Vinschen via Cygwin wrote:
> > > > Is it actually a safe bet that the error mode set by
On Feb 2 18:22, Corinna Vinschen via Cygwin wrote:
> On Feb 2 14:56, David Allsopp via Cygwin wrote:
> > On Fri, 2 Feb 2024 at 14:18, Corinna Vinschen via Cygwin wrote:
> > > On Feb 2 13:35, David Allsopp via Cygwin wrote:
> > > > Not really suggesting it be done this way (it feels more
On Feb 2 14:56, David Allsopp via Cygwin wrote:
> On Fri, 2 Feb 2024 at 14:18, Corinna Vinschen via Cygwin wrote:
> > On Feb 2 13:35, David Allsopp via Cygwin wrote:
> > > Not really suggesting it be done this way (it feels more complicated
> > > than just reverting the change), but in some ways
On Fri, 2 Feb 2024 at 14:18, Corinna Vinschen via Cygwin wrote:
>
> On Feb 2 13:35, David Allsopp via Cygwin wrote:
> > Jon Turney via Cygwin wrote:
> >
> > > > I'm sympathetic, and personally I would prefer to revert the patch and
> > > > stick to SEM_FAILCRITICALERRORS by default.
> > > >
> > >
On Feb 2 13:35, David Allsopp via Cygwin wrote:
> Jon Turney via Cygwin wrote:
>
> > > I'm sympathetic, and personally I would prefer to revert the patch and
> > > stick to SEM_FAILCRITICALERRORS by default.
> > >
> > > The question is this: Why does, apparently, everybody expect Cygwin to
> > >
Jon Turney via Cygwin wrote:
> > I'm sympathetic, and personally I would prefer to revert the patch and
> > stick to SEM_FAILCRITICALERRORS by default.
> >
> > The question is this: Why does, apparently, everybody expect Cygwin to
> > do the "right thing", with different definitions of "right",
On Fri, 2 Feb 2024 at 12:55, Corinna Vinschen via Cygwin wrote:
> On Feb 2 09:43, David Allsopp via Cygwin wrote:
> > On Thu, 1 Feb 2024 at 10:02, Corinna Vinschen via Cygwin
> > wrote:
> > >
> > > The behaviour changed in 2020
> > >
> > >
On 02/02/2024 12:55, Corinna Vinschen via Cygwin wrote:
On Feb 2 09:43, David Allsopp via Cygwin wrote:
On Thu, 1 Feb 2024 at 10:02, Corinna Vinschen via Cygwin
wrote:
The behaviour changed in 2020
https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=21ec498d7f912
not without a
On Feb 2 09:43, David Allsopp via Cygwin wrote:
> On Thu, 1 Feb 2024 at 10:02, Corinna Vinschen via Cygwin
> wrote:
> >
> > The behaviour changed in 2020
> >
> > https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=21ec498d7f912
> >
> > not without a discussion
> >
> >
On Thu, 1 Feb 2024 at 10:02, Corinna Vinschen via Cygwin
wrote:
>
> The behaviour changed in 2020
>
> https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=21ec498d7f912
>
> not without a discussion
>
> https://cygwin.com/pipermail/cygwin-patches/2020q4/010870.html
Aha, thank you! (congrats
On 2024-02-01 01:18, David Allsopp via Cygwin wrote:
On Wed, 31 Jan 2024 at 22:27, Brian Inglis via Cygwin wrote:
On 2024-01-31 06:40, David Allsopp via Cygwin wrote:
Starting with this very trivial C program:
#include
#include
int main(void) {
printf("Zstandard v%d\n",
On Feb 1 08:22, David Allsopp via Cygwin wrote:
> > x86_64-w64-mingw32-gcc produces a Windows program, why Cygwin should
> > be involved in the execution ?
>
> I perhaps should have made that crystal clear - in running "./test",
> I'm invoking that excecutable _from_ a Cygwin program (in this
> x86_64-w64-mingw32-gcc produces a Windows program, why Cygwin should
> be involved in the execution ?
I perhaps should have made that crystal clear - in running "./test",
I'm invoking that excecutable _from_ a Cygwin program (in this case
mintty / bash / sh), so Cygwin is very much involved -
On Wed, 31 Jan 2024 at 22:27, Brian Inglis via Cygwin wrote:
>
> On 2024-01-31 06:40, David Allsopp via Cygwin wrote:
> > Starting with this very trivial C program:
> >
> > #include
> > #include
> >
> > int main(void) {
> >printf("Zstandard v%d\n", ZSTD_versionNumber());
> > }
> >
> > and
On 2024-01-31 06:40, David Allsopp via Cygwin wrote:
Starting with this very trivial C program:
#include
#include
int main(void) {
printf("Zstandard v%d\n", ZSTD_versionNumber());
}
and compiling with
x86_64-w64-mingw32-gcc -o test.exe test.c -lzstd
when I then run ./test.exe, I get
On Wed, Jan 31, 2024 at 2:41 PM David Allsopp via Cygwin wrote:
>
> Starting with this very trivial C program:
>
> #include
> #include
>
> int main(void) {
> printf("Zstandard v%d\n", ZSTD_versionNumber());
> }
>
> and compiling with
>
> x86_64-w64-mingw32-gcc -o test.exe test.c -lzstd
>
>
On 1/31/2024 7:40 AM, David Allsopp via Cygwin wrote:
Starting with this very trivial C program:
#include
#include
int main(void) {
printf("Zstandard v%d\n", ZSTD_versionNumber());
}
and compiling with
x86_64-w64-mingw32-gcc -o test.exe test.c -lzstd
when I then run ./test.exe, I get
Starting with this very trivial C program:
#include
#include
int main(void) {
printf("Zstandard v%d\n", ZSTD_versionNumber());
}
and compiling with
x86_64-w64-mingw32-gcc -o test.exe test.c -lzstd
when I then run ./test.exe, I get the Windows critical-error-handler
dialog stating "The
21 matches
Mail list logo
