public inbox for cygwin-cvs@sourceware.org
help / color / mirror / Atom feed
From: Corinna Vinschen <corinna@sourceware.org>
To: cygwin-cvs@sourceware.org
Subject: [newlib-cygwin] Revert "Cygwin: Make sure newer apps get uname_x even when loading uname dynamically"
Date: Mon,  8 Mar 2021 09:34:19 +0000 (GMT)	[thread overview]
Message-ID: <20210308093419.9F34F3857C7B@sourceware.org> (raw)

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=582628d551e46754dedb53480ff05217409b55d2

commit 582628d551e46754dedb53480ff05217409b55d2
Author: Corinna Vinschen <corinna@vinschen.de>
Date:   Sun Mar 7 12:17:57 2021 +0100

    Revert "Cygwin: Make sure newer apps get uname_x even when loading uname dynamically"
    
    This reverts commit 532b91d24e9496c7988b2b1dda7fc0e8b161f782.
    
    It turned out that this patch has undesired side effects.  To wit, if a
    newer, post-uname_x executable was linked against or loading an older,
    pre-uname_x DLL, and this DLL called uname.  This call would jump into
    the old uname with the old struct utsname as parameter, but given the
    newer executable it would get redirected to uname_x.  uname_x in turn
    would overwrite stack memory it should leave well alone, given it
    expects the newer, larger struct utsname.
    
    For the entire discussion see the thread starting at
    https://cygwin.com/pipermail/cygwin/2021-February/247870.html
    and continuing in March at
    https://cygwin.com/pipermail/cygwin/2021-March/247930.html
    For a description where we're coming from, see
    https://cygwin.com/pipermail/cygwin/2021-March/247959.html
    
    While we *could* make the scenario in question work by patching dlsym,
    the problem would actually be the same, just for dynamic loading.  In
    the end, we're missing the information, which Cygwin version has been
    used when building DLLs.
    
    Signed-off-by: Corinna Vinschen <corinna@vinschen.de>

Diff:
---
 winsup/cygwin/include/cygwin/version.h | 3 ---
 winsup/cygwin/uname.cc                 | 7 -------
 2 files changed, 10 deletions(-)

diff --git a/winsup/cygwin/include/cygwin/version.h b/winsup/cygwin/include/cygwin/version.h
index b39d0dbe9..f21aba726 100644
--- a/winsup/cygwin/include/cygwin/version.h
+++ b/winsup/cygwin/include/cygwin/version.h
@@ -74,9 +74,6 @@ details. */
 #define CYGWIN_VERSION_CHECK_FOR_EXTRA_TM_MEMBERS \
   (CYGWIN_VERSION_USER_API_VERSION_COMBINED >= 272)
 
-#define CYGWIN_VERSION_CHECK_FOR_UNAME_X \
-  (CYGWIN_VERSION_USER_API_VERSION_COMBINED >= 335)
-
 #define CYGWIN_VERSION_CYGWIN_CONV 181
 
 /* API_MAJOR 0.0: Initial version.  API_MINOR changes:
diff --git a/winsup/cygwin/uname.cc b/winsup/cygwin/uname.cc
index 48f7dda60..350216681 100644
--- a/winsup/cygwin/uname.cc
+++ b/winsup/cygwin/uname.cc
@@ -92,14 +92,7 @@ struct old_utsname
 extern "C" int
 uname (struct utsname *in_name)
 {
-  /* This occurs if the application fetches the uname symbol dynamically.
-     We must call uname_x for newer API versions, otherwise the idea of
-     struct utsname doesn't match. */
-  if (CYGWIN_VERSION_CHECK_FOR_UNAME_X)
-    return uname_x (in_name);
-
   struct old_utsname *name = (struct old_utsname *) in_name;
-
   __try
     {
       char *snp = strstr  (cygwin_version.dll_build_date, "SNP");


                 reply	other threads:[~2021-03-08  9:34 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210308093419.9F34F3857C7B@sourceware.org \
    --to=corinna@sourceware.org \
    --cc=cygwin-cvs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).