[issue19283] Need support to avoid Windows CRT compatibility issue.

2014-07-10 Thread Mark Lawrence

Mark Lawrence added the comment:

Is there a specific Python question here?

--
nosy: +BreamoreBoy

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19283
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue19283] Need support to avoid Windows CRT compatibility issue.

2014-07-10 Thread Martin v . Löwis

Martin v. Löwis added the comment:

In any case, this issue has too little information to be able to reproduce it 
in a meaningful way. Closing as out-of-date.

--
resolution:  - out of date
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19283
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue19283] Need support to avoid Windows CRT compatibility issue.

2013-10-18 Thread Debarshi Goswami

New submission from Debarshi Goswami:

Some support is needed to avoid compatibility issues in different version of 
CRT in Windows.
I have an application which embeds Python interpreter and the application is 
build on MSVC11, whereas I am using Python 3.3.2 which is build on MSVC10. I 
know there are some compatibility issues which are addressed in Issue10082 and 
Issue1003535. But even other Python APIs which uses FILE pointer inside are 
failing too. I tried the following things – 
1.  PyRun_FileExFlags with MSVC11 FILE*. It crashes as expected.
2.  PyRun_FileExFlags with MSVC10 FILE* using _Py_fopen() directly passing 
to it. It is also crashing whereas _Py_fopen() returns FILE* of MSVC10 type.
3.  Py_CompileString() also crashes. I don’t know the reason, but here my 
application is not providing FILE* from outside. It uses FILE* of Python 
library which is of MSVC10 type.
I did some investigation and found if I provide FILE* of MSVC10 type from my 
application in PyRun_File() or if I call Py_CompileString(), it crashes after 
parsing the file (I am not totally sure, but it seems to me). Here is the call 
stack – 
python33.dll!PyUnicode_InternInPlace(_object * * p) Line 14220 C
python33.dll!new_identifier(const char * n, compiling * c) Line 570 C
python33.dll!alias_for_import_name(compiling * c, const _node * n, int store) 
Line 2808 C
python33.dll!ast_for_import_stmt(compiling * c, const _node * n) Line 2892  C
python33.dll!PyAST_FromNode(const _node * n, PyCompilerFlags * flags, const 
char * filename, _arena * arena) Line 724   C
python33.dll!PyParser_ASTFromFile(_iobuf * fp, const char * filename, const 
char * enc, int start, char * ps1, char * ps2, PyCompilerFlags * flags, int * 
errcode, _arena * arena) Line 2124C
python33.dll!PyRun_FileExFlags(_iobuf * fp, const char * filename, int start, 
_object * globals, _object * locals, int closeit, PyCompilerFlags * flags) Line 
1931  C

It fails in PyDict_GetItem() call in PyUnicode_InternInPlace() function. Here 
is the snippet - 

/* It might be that the GetItem call fails even
   though the key is present in the dictionary,
   namely when this happens during a stack overflow. */
Py_ALLOW_RECURSION
t = PyDict_GetItem(interned, s);
Py_END_ALLOW_RECURSION

I am not sure why PyDict_GetItem() is failing because of FILE*. It seems to me 
that Python is able to parse file provided successfully.

I am initializing interpreter successfully and PyRun_String() API works fine. 
But I dont want to use PyRun_String() as it performs everything virtually and 
provide no debug support.

--
components: Interpreter Core, Windows
messages: 200238
nosy: debarshig
priority: normal
severity: normal
status: open
title: Need support to avoid Windows CRT compatibility issue.
versions: Python 3.3

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19283
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue19283] Need support to avoid Windows CRT compatibility issue.

2013-10-18 Thread Debarshi Goswami

Debarshi Goswami added the comment:

If any workaround is available. It is also fine.

--
type:  - crash

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19283
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue19283] Need support to avoid Windows CRT compatibility issue.

2013-10-18 Thread Antoine Pitrou

Antoine Pitrou added the comment:

The easy answer is: don't execute a script, import a module instead (and either 
do something at that module's top-level, or execute a function inside the 
module).

Also, as for ABI issues, take a look at:
http://docs.python.org/3.3/c-api/stable.html

--
nosy: +loewis, pitrou

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19283
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue19283] Need support to avoid Windows CRT compatibility issue.

2013-10-18 Thread Debarshi Goswami

Debarshi Goswami added the comment:

My question is, even a FILE* of MSVC10 type is provided, why these APIs are 
crashing, after all it expects MSVC10 type.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19283
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com