date:20161209

[Mingw-w64-public] [PATCH v10] crt: Recognize cygwin ptys in isatty

2016-12-09 Thread Mihail Konev

Signed-off-by: Mihail Konev 
Moved-from: https://github.com/Alexpux/mingw-w64/pull/3
Reference: https://cygwin.com/ml/cygwin-developers/2016-11/msg2.html
---
v8-v10:
  Change comment-outs in def files.
  Error-check GetModuleHandle.
  Edit description.

 mingw-w64-crt/Makefile.am  |   1 +
 mingw-w64-crt/def-include/msvcrt-common.def.in |   2 +-
 mingw-w64-crt/lib64/moldname-msvcrt.def|   2 +-
 mingw-w64-crt/stdio/isatty.c   | 111 +
 mingw-w64-headers/crt/io.h |   1 +
 5 files changed, 115 insertions(+), 2 deletions(-)
 create mode 100644 mingw-w64-crt/stdio/isatty.c

diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 581af0cc5811..49f7f58289c7 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -211,6 +211,7 @@ src_msvcrt=\
   secapi/vsprintf_s.c \
   secapi/wmemcpy_s.c \
   secapi/wmemmove_s.c \
+  stdio/isatty.c \
   stdio/mingw_lock.c
 
 src_msvcrt32=\
diff --git a/mingw-w64-crt/def-include/msvcrt-common.def.in 
b/mingw-w64-crt/def-include/msvcrt-common.def.in
index 76e1fa37e8b2..00c0467b5437 100644
--- a/mingw-w64-crt/def-include/msvcrt-common.def.in
+++ b/mingw-w64-crt/def-include/msvcrt-common.def.in
@@ -47,7 +47,7 @@ ADD_UNDERSCORE(getcwd)
 ADD_UNDERSCORE(getpid)
 ADD_UNDERSCORE(getw)
 ADD_UNDERSCORE(heapwalk)
-ADD_UNDERSCORE(isatty)
+;isatty
 ADD_UNDERSCORE(itoa)
 ADD_UNDERSCORE(kbhit)
 ADD_UNDERSCORE(lfind)
diff --git a/mingw-w64-crt/lib64/moldname-msvcrt.def 
b/mingw-w64-crt/lib64/moldname-msvcrt.def
index 6f31518d5c82..3a15de703762 100644
--- a/mingw-w64-crt/lib64/moldname-msvcrt.def
+++ b/mingw-w64-crt/lib64/moldname-msvcrt.def
@@ -64,7 +64,7 @@ getcwd
 getpid
 getw
 heapwalk
-isatty
+;isatty
 itoa
 kbhit
 lfind
diff --git a/mingw-w64-crt/stdio/isatty.c b/mingw-w64-crt/stdio/isatty.c
new file mode 100644
index ..bf940d6f225f
--- /dev/null
+++ b/mingw-w64-crt/stdio/isatty.c
@@ -0,0 +1,111 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int __cdecl (*__MINGW_IMP_SYMBOL(isatty))(int) = isatty;
+
+/* Cygwin-compatible isatty.
+ *
+ * Cygwin pty is a specially-named named pipe.
+ * Fetch [absolute] fd's NT object path (if any),
+ * and check it for the following pattern:
+ *
+ *   
\Device\NamedPipe\cygwin-[a-fA-F0-9]{16}-pty[0-9]{1,4}-(from-master|to-master|to-master-cyg)
+ *
+ * [a-fA-F0-9] is the cygwin installation key, 16 characters long.
+ * pty[0-9] is the pty name. Its index is of type int, but is safe to be 
limited to 4 characters.
+ *
+ * */
+
+int __cdecl isatty(int fd) {
+  wchar_t const expect_dev[] = L"\\Device\\NamedPipe\\cygwin-";
+  wchar_t const expect_pty[] = L"-pty";
+
+  typedef NTSTATUS (NTAPI proc_NtQueryObject) (HANDLE, 
OBJECT_INFORMATION_CLASS, PVOID, ULONG, PULONG);
+  proc_NtQueryObject *pNtQueryObject;
+
+  HANDLE h_fd, h_ntdll;
+
+  /* NtQueryObject needs space for OBJECT_NAME_INFORMATION.Name->Buffer also. 
*/
+  char ntfn_bytes[sizeof(OBJECT_NAME_INFORMATION) + MAX_PATH * sizeof(WCHAR)];
+
+  OBJECT_NAME_INFORMATION *ntfn = (OBJECT_NAME_INFORMATION*) ntfn_bytes;
+  NTSTATUS status;
+  ULONG ntfn_size = sizeof(ntfn_bytes);
+
+  wchar_t *s;
+  int l;
+
+  h_fd = (HANDLE) _get_osfhandle(fd);
+  if (!h_fd || h_fd == INVALID_HANDLE_VALUE) {
+errno = EBADF;
+return 0;
+  }
+
+  h_ntdll = GetModuleHandle("ntdll.dll");
+  if (!h_ntdll || h_ntdll == INVALID_HANDLE_VALUE) {
+errno = EBADF;
+return 0;
+  }
+
+  pNtQueryObject = (proc_NtQueryObject*) GetProcAddress(h_ntdll, 
"NtQueryObject");
+  if (!pNtQueryObject) {
+goto no_tty;
+  }
+
+  memset(ntfn, 0, ntfn_size);
+  status = pNtQueryObject((HANDLE)h_fd, ObjectNameInformation,
+  ntfn, ntfn_size, _size);
+
+  if (!NT_SUCCESS(status)) {
+/* If it is not NUL (i.e. \Device\Null, which would succeed),
+ * then normal isatty() could be consulted.
+ * */
+if (_isatty(fd)) {
+  return 1;
+}
+goto no_tty;
+  }
+
+  s = ntfn->Name.Buffer;
+  s[ntfn->Name.Length / sizeof(WCHAR)] = 0;
+
+  l = wcslen(expect_dev);
+  if (wcsncmp(s, expect_dev, l) != 0) {
+goto no_tty;
+  }
+  s += l;
+
+  l = wcsspn(s, L"0123456789abcdefABCDEF");
+  if (l != 16) {
+goto no_tty;
+  }
+  s += l;
+
+  l = wcslen(expect_pty);
+  if (wcsncmp(s, expect_pty, l) != 0) {
+goto no_tty;
+  }
+  s += l;
+
+  l = wcsspn(s, L"0123456789");
+  if (l < 1 || l > 4) {
+goto no_tty;
+  }
+  s += l;
+
+  if (wcscmp(s, L"-from-master") != 0 &&
+wcscmp(s, L"-to-master") != 0 &&
+wcscmp(s, L"-to-master-cyg") != 0)
+  {
+goto no_tty;
+  }
+
+  return 1;
+
+no_tty:
+  errno = EINVAL;
+  return 0;
+}
diff --git a/mingw-w64-headers/crt/io.h b/mingw-w64-headers/crt/io.h
index c61e94ab8743..97b26762f831 100644
--- a/mingw-w64-headers/crt/io.h
+++ b/mingw-w64-headers/crt/io.h
@@ -191,6 +191,7 @@ _CRTIMP char* __cdecl _getcwd (char*, int);
   _CRTIMP int __cdecl _findnext32(intptr_t _FindHandle,struct _finddata32_t

Re: [Mingw-w64-public] [Project News|New Builds]

2016-12-09 Thread Stephen Kitt

Hi niXman,

On Tue, 20 Sep 2016 21:32:02 +0300, niXman  wrote:
> Zouzou 2016-09-18 17:28:
> > One note: The source is missing from
> > .
> 
> The uploading of the builds and sources is performed by scripts. It 
> looks like something went wrong with the scripts... I'll check...

I tried to find the source but failed; any news on the scripts? I'm curious
to see how you enabled filesystem TS support (I'm getting build failures
because dir.cc expects DIR* but MinGW-w64 _wopendir returns WDIR*).

Regards,

Stephen

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Question about fixing the (wrong?) location of libcc1 when packaging MinGW

2016-12-09 Thread Mojca Miklavec

Hello,

I created packages for MinGW-w64 for MacPorts, but there's one more
issue that I need to solve before I could publish the packages.

Both i686-w64-mingw32-gcc and x86_64-w64-mingw32-gcc (created with
"make && make install" from GCC) contain the same three files:

/opt/local/lib/x86_64/libcc1.0.so
/opt/local/lib/x86_64/libcc1.la
/opt/local/lib/x86_64/libcc1.so

I checked the configure flags for the (native) gcc6 package and that one uses
--libdir=${prefix}/lib/gcc6
to avoid the clash between different versions of gcc. But if I do the
same for MinGW, the files end up under
${prefix}l/lib/x86_64-w64-mingw32/gcc/x86_64-w64-mingw32/
which is somewhat suboptimal.

How could I move those three files somewhere else?

See also
https://gcc.gnu.org/ml/gcc/2015-01/msg00190.html
without a satisfactory answer.

Another problem is the location of
${prefix}/share/info/gfortran.info
which should have been
${prefix}/share/info/x86_64-w64-mingw32-gfortran.info
but that one is at least easy to fix (it should nevertheless be
reported upstream).

Thank you,
   Mojca

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH v10] crt: Recognize cygwin ptys in isatty

Re: [Mingw-w64-public] [Project News|New Builds]

[Mingw-w64-public] Question about fixing the (wrong?) location of libcc1 when packaging MinGW

3 matches

Site Navigation

Mail list logo

Footer information