homepage

The explanation is quite simple: in Py_Main, the arguments are converted
from wide to byte strings, but the required length of the byte string is
assumed equal to that of the wide string.
Which gives:
$ ./python -c "print('à')"
Fatal Python error: not enough memory to copy -c argument
Erreur de segmentation (core dumped)
$ ./python -m à
Fatal Python error: not enough memory to copy -m argument
Erreur de segmentation (core dumped)

Here is a patch which works under Linux. Under Windows it doesn't choke
when converting arguments anymore, but it fails later in the process (in
the parser for '-c', in the importing logic for '-m').
Here is an example:
$ ./python -c "print(ord('ሀ'))"
4608
$ cat > ሀ.py
print(__file__)
$ ./python -m ሀ
/home/antoine/py3k/mbstowcs/ሀ.py
$ ./python ሀ.py 
ሀ.py

Hmm. I suppose anything is better than segfaulting. I think the patch is
fine for now, though.

Committed in r66269.

This patch corrects the "-m" case on windows: the path has to be
decoded/recoded using the filesystem encoding, and not the default utf-8.
Review is needed, of course.

Looks good and works under Linux.
One small nit, you could just as well use "NN(ssi)" for the
Py_BuildValue and remove Py_DECREF(fob), so as to be more consistent.

Updated patch.

./python -c "print('à')"
does not work on my Linux machine with latest py3k (r66303), certainly
because my terminal uses a latin-1 encoding: wcstombs will convert the
argument back to the terminal encoding, whereas PyRun_SimpleString
expects a UTF-8 string.
I join another patch, which propagates the wchar_t as far as possible,
and encodes it as utf-8; with test.
This also corrects the Windows case.

I think the patch good; go ahead.

Applied both patches as r66331.

Unfortunately, my patch does not work: see the compile warnings in "main.c":
http://www.python.org/dev/buildbot/3.0/x86%20osx.5%203.0/builds/344/step-compile/0
I reverted the change, and will try something else...

Today I learned something: wchar_t can be 2 or 4 bytes, PyUNICODE can be 
2 or 4 bytes, and all combinations are possible.
My error was to use PyUnicode_FromUnicode on a wchar_t*; PyUnicode_FromWideChar is the obvious function to use.
Attached a new patch (command_unicode_2.patch) for review.

Raising to release blocker, just to trigger another review...

Go ahead.

Fixed as r67190. Thanks for the review.