[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #30323] No path in MAKE_COMMAND (with fix)

From: anonymous
Subject: [bug #30323] No path in MAKE_COMMAND (with fix)
Date: Fri, 02 Jul 2010 12:53:59 +0000
User-agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2)


                 Summary: No path in MAKE_COMMAND (with fix)
                 Project: make
            Submitted by: None
            Submitted on: Fri 02 Jul 2010 12:53:59 PM UTC
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
       Component Version: CVS
        Operating System: MS Windows
           Fixed Release: None
           Triage Status: None




The file main.c contains the following comment:

"Set the "MAKE_COMMAND" variable to the name we were invoked with. (If it is
a relative pathname with a slash, prepend our directory name so the result
will run the same program regardless of the current dir. If it is a name with
no slash, we can only hope that PATH did not find it in the current

However the last sentence isn't true for Windows. With
GetModuleFileName(NULL, ...) it is possible to reliably retrieve the absolute
pathname of the running program independently from the peculiarities of the
way it was called (aka the content of argv[0]).

The fix is to replace 

  if (strpbrk(argv[0], "/:\\") ||
      strstr(argv[0], "..") ||
      strneq(argv[0], "//", 2))
    argv[0] = xstrdup(w32ify(argv[0],1));


  argv[0] = xstrdup (w32ify (_pgmptr, 0));

This fix doesn't call GetModuleFileName() directly because that is documented
to require at least Windows 2000. Instead it uses _pgmptr which is documented
to be available since Windows 95 - and which is populated by the CRT nowadays
using GetModuleFileName().

Note that resolving to a full pathname in w32ify() is now turned off. It's
only called to convert '\' to '/'.

Oliver Schmidt - oliv.schmidt(at)sap.com


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]