Add cygwin_internal CW_GET_MODULE_PATH_FOR_ADDR

Corinna Vinschen
Fri Oct 14 09:19:00 GMT 2011

On Oct 14 02:09, Charles Wilson wrote:
> On 10/13/2011 10:42 AM, Corinna Vinschen wrote:
> > On Oct 13 10:20, Charles Wilson wrote:
> >>>   - It would be useful to have a Cygwin API that gives me the file
> >>>     file name behind one particular address in the current process.
> >>>     This should not be that slow.
> >>
> >> This patch is a proof of concept for the latter.  Naturally, it needs
> >> additional work -- updating version.h, real changelog entries,
> >> documentation somewhere, etc. it worth the effort?  Is
> >> something like this likely to be accepted?
> > 
> > The first and foremost question is, what is the relocation support
> > in libintl trying to accomplish?  Why does a internationalization
> > library has to know the path of a module based on an address?
> > Is that a functionality required on other POSIX systems?
> > 
> > Can we discuss this on cygwin-developers first, please?  So far I doubt
> > that this makes any sense on Cygwin.
> [...]
> [[ SIDE NOTE: even though our official libintl is built without
> --enable-relocate, its Makefile is *hardcoded* to define
> ENABLE_RELOCATABLE.  Therefore the libintl_relocate() function IS
> present, and IS called -- but because the compile-time prefix (/usr) was
> the same as the installed prefix, it very expensively did a no-op.  With
> Bruno's recent change, it will do a cheap -- but not entirely free --
> no-op. ]]
> [...]

First of all, the blatant bug which sets the locale depending on the
Windows settings is much more important and *pressing* IMHO.  This is
what's really necessary, the relocation stuff not so much.

I had a look into gettext-runtime/intl/setlocale.c and it drives me
nuts.  I told Bruno back in January already not to use Windowisms on
Cygwin.  Cygwin's setlocale and nl_langinfo functions do everything
libintl needs.  And it's especially annoying to use an encoding which
doesn't match the rest of the system, because libintl fetches
"ISO-8859-1" from Windows (strange enough), rather than using UTF-8 as
requested by $LANG.

Therefore, can we get an intermediate libintl8 which fixes this bug and
just disables ENABLE_RELOCATABLE in the Makefile, until the relocation
problem is settled?

> But the key bit is that the libfoo_relocate() function needs to be able
> to determine the current runtime path of
> the-module-which-contains-'libfoo_relocate()' (well, technically, the
> module which contains a specific static (private) copy of
> find_shared_library_fullname).

Well, if that's really necessary, then, for heaven's sake, let them use
the code in gettext-runtime/gnulib-lib/relocatable.c, but with a good

- Call GetModuleFileNameW instead of GetModuleFileName.
- Call cygwin_create_path instead of cygwin_conv_to_posix_path.

The reason is not so much the longer filenames, rather than the conversion
of the path into the correct current encoding.  Here's an untested patch
relative to the original sources from gettext-

--- gettext-runtime/gnulib-lib/relocatable.c.ORIG	2011-10-14 11:08:19.869624102 +0200
+++ gettext-runtime/gnulib-lib/relocatable.c	2011-10-14 11:10:17.052504493 +0200
@@ -302,6 +302,20 @@ DllMain (HINSTANCE module_handle, DWORD 
   if (event == DLL_PROCESS_ATTACH)
       /* The DLL is being loaded into an application's address range.  */
+#if defined __CYGWIN__
+	static wchar_t location[PATH_MAX];
+      if (!GetModuleFileNameW (module_handle, location, sizeof (location)))
+        /* Shouldn't happen.  */
+        return FALSE;
+      if (!IS_PATH_WITH_DIR (location))
+        /* Shouldn't happen.  */
+        return FALSE;
+      shared_library_fullname = (char *) cygwin_create_path (CCP_WIN_W_TO_POSIX,
+							     location);
       static char location[MAX_PATH];
       if (!GetModuleFileName (module_handle, location, sizeof (location)))
@@ -312,25 +326,8 @@ DllMain (HINSTANCE module_handle, DWORD 
         /* Shouldn't happen.  */
         return FALSE;
-      {
-#if defined __CYGWIN__
-        /* On Cygwin, we need to convert paths coming from Win32 system calls
-           to the Unix-like slashified notation.  */
-        static char location_as_posix_path[2 * MAX_PATH];
-        /* There's no error return defined for cygwin_conv_to_posix_path.
-           See cygwin-api/func-cygwin-conv-to-posix-path.html.
-           Does it overflow the buffer of expected size MAX_PATH or does it
-           truncate the path?  I don't know.  Let's catch both.  */
-        cygwin_conv_to_posix_path (location, location_as_posix_path);
-        location_as_posix_path[MAX_PATH - 1] = '\0';
-        if (strlen (location_as_posix_path) >= MAX_PATH - 1)
-          /* A sign of buffer overflow or path truncation.  */
-          return FALSE;
-        shared_library_fullname = strdup (location_as_posix_path);
-        shared_library_fullname = strdup (location);
+      shared_library_fullname = strdup (location);
-      }
   return TRUE;


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-developers mailing list