This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: OS X: Py_SetProgramName argument has type char*; should be wchar_t*
Type: Stage:
Components: macOS Versions: Python 3.0, Python 3.1
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: Nosy List: mark.dickinson, ned.deily, ronaldoussoren
Priority: normal Keywords:

Created on 2009-02-03 16:53 by mark.dickinson, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
patch-mbstowcs.txt ronaldoussoren, 2009-02-03 18:48
patch-remove-PYTHONEXECUTABLE.txt ronaldoussoren, 2009-02-03 18:48
patch-nad0013-py3k-30.txt ned.deily, 2009-02-10 03:51
patch-nad0013t-py3k-30.txt ned.deily, 2009-02-10 03:51
Messages (8)
msg81066 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-02-03 16:53
When building the py3k branch on OS X, I get the following warning:

gcc -c -fno-strict-aliasing -g -Wall -Wstrict-prototypes  -I. -IInclude -
I./Include   -DPy_BUILD_CORE -o Modules/main.o Modules/main.c
Modules/main.c: In function ‘Py_Main’:
Modules/main.c:491: warning: passing argument 1 of ‘Py_SetProgramName’ 
from incompatible pointer type

This *looks* like it might be a genuine problem. Lines 490-493 of main.c 
(which occur inside an #ifdef __APPLE__) look like this:

if ((p = Py_GETENV("PYTHONEXECUTABLE")) && *p != '\0')
	Py_SetProgramName(p);
else
	Py_SetProgramName(argv[0]);

The return from Py_GETENV (which calls the system getenv) has type char*, 
but Py_SetProgramName expects something of type wchar_t*.

However, I don't know enough about this part of Python to tell for sure 
whether there's really something wrong here.

Ronald, any ideas?
msg81075 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2009-02-03 17:32
I think it is a problem and it explains one of the problems with 
IDLE.app in 3.x.  The value of PYTHONEXECUTABLE should end up in 
sys.executable:

$ export PYTHONEXECUTABLE='/test'
@fimt:~$ python2.6
Python 2.6.1 (r261:67515, Dec 17 2008, 23:27:50) 
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
>>> import sys; sys.executable
'/test'
>>> 
$ python3.1
Python 3.1a0 (py3k, Feb  2 2009, 02:33:48) 
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
>>> import sys; sys.executable
'/Users/nad/'
>>>
msg81077 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2009-02-03 18:11
This is a bug, I'm working on a fix.
msg81082 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2009-02-03 18:48
The quick fix is to convert "p" to a wchar_t (using mbstowcs), see 
patch-mbstowcs.txt. 

However, I don't think this is the right fix. AFAIK this environment 
variable is only used by .app bundles created by bundlebuilder.py which 
is no longer part of the standard library. 

IDLE.app uses the same mechanism, but that's not needed there and can be 
removed without problems. The file patch-remove-PYTHONEXECUTABLE.txt 
removed the environment variable, and results in a working IDLE.app on 
my machine (IDLE launches with a working shell window and I can open 
python files).

I'd prefer to apply patch-remove-PYTHONEXECUTABLE.txt on the trunk, the 
more limited fix can be applied on the 3.0.x branch (although I have no 
idea if that branch even works correctly on OSX)
msg81083 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2009-02-03 18:50
Please let me know if second patch (patch-remove-PYTHONEXECUTABLE.txt) 
fixes the issue for you as well, if it does I'll commit it to the 3.x 
branch (and add an item to the NEWS file).
msg81088 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2009-02-03 19:09
Thanks for the patches, I'll report back on them.
msg81528 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2009-02-10 03:51
Here's the results of testing the two patches:
- patch-mbstowcs.txt should not do a free on the buffer since
  Py_SetProgramName is expecting to hold on to it (like with
  the result of a getenv(3)).
- patch-remove-PYTHONEXECUTABLE.txt works as is.

However, neither of these patches in and of themselves fix all
the issues with OS X IDLE menus on 3.x (most of the issues are
present in 2.x as well).  See Issue5194, Issue5195, and Issue5196.
In particular, the patches in 5194 and 5196 also eliminate the
dependence on PYTHONEXECUTABLE influencing sys.executable.

So, just looking at IDLE, it would not hurt to remove the
PYTHONEXECUTABLE magic. On the other hand, it is a documented
behavior of PYTHON:

http://docs.python.org/3.0/using/cmdline.html#envvar-PYTHONEXECUTABLE

and removing it *could* add extra problems for people porting
over bundlebuilder-based apps or for whatever other reason they
might be using it.

So my recommendation is to fix PYTHONEXECUTABLE.  Attached patch
patch-nad0013-py3k-30.txt does so.  It also includes a fix for 
another very similar OSX-only 2.x->3.x wchar_t conversion problem
which also causes an "incompatible pointer type" build warning,
something I noticed while investigating this.  The patch has been
tested on both py3k and 3.0.  patch-nad0013t-py3k-30.txt adds
a test case for PYTHONEXECUTABLE behavior.
msg81774 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2009-02-12 15:57
I've applied both the fix and tests in r69540 (3.1) and r69541 (3.0)
History
Date User Action Args
2022-04-11 14:56:45adminsetgithub: 49393
2009-02-12 15:57:06ronaldoussorensetstatus: open -> closed
messages: + msg81774
2009-02-10 03:51:20ned.deilysetfiles: + patch-nad0013t-py3k-30.txt
2009-02-10 03:51:03ned.deilysetfiles: + patch-nad0013-py3k-30.txt
messages: + msg81528
2009-02-03 19:09:46ned.deilysetmessages: + msg81088
2009-02-03 18:50:47ronaldoussorensetresolution: accepted
messages: + msg81083
2009-02-03 18:48:31ronaldoussorensetfiles: + patch-remove-PYTHONEXECUTABLE.txt
2009-02-03 18:48:16ronaldoussorensetfiles: + patch-mbstowcs.txt
messages: + msg81082
2009-02-03 18:11:02ronaldoussorensetmessages: + msg81077
2009-02-03 17:32:57ned.deilysetnosy: + ned.deily
messages: + msg81075
2009-02-03 16:53:08mark.dickinsoncreate