[issue38258] ctypes ignores when a DLL function is called with too many arguments
New submission from Sebastian Ernst :
A c-function with the following signature ...
```C
int16_t __stdcall __declspec(dllimport) square_int(
int16_t a
);
```
... is being called with ctypes:
```python
def test_error_callargs_unconfigured_too_many_args():
dll = ctypes.windll.LoadLibrary('tests/demo_dll.dll')
square_int = dll.square_int
with pytest.raises(ValueError):
a = square_int(1, 2, 3)
```
Expected result: If the function is called with too many (positional) arguments
(in the example 3 instead of 1), a `ValueError` should be raised. This is the
case for at least CPython 3.4 to 3.7.
Actual result: "Nothing", i.e. no exception. The described test "fails". The
function is called without an error - with CPython 3.8.0b4.
If this behavior is intended, is has not been (as far as I can tell) documented.
--
components: ctypes
messages: 353021
nosy: smernst
priority: normal
severity: normal
status: open
title: ctypes ignores when a DLL function is called with too many arguments
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue38258>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38258] ctypes ignores when a DLL function is called with too many arguments
Sebastian Ernst added the comment:
Thanks a lot for the clarification, Eryk. I did not notice that it was
deprecated behavior.
For the "too many arguments" case I guess this is not an issue. However, just
for the symmetry of things, I also looked at calling a function with TOO FEW
arguments.
```C
int16_t __stdcall __declspec(dllimport) mul_ints(
int16_t a,
int16_t b
)
{
return a * b;
}
```
```python
def test_error_callargs_unconfigured_too_few_args():
dll = ctypes.windll.LoadLibrary('tests/demo_dll.dll')
mul_ints = dll.mul_ints
with pytest.raises(ValueError):
a = mul_ints(7)
```
As expected after your explanation, also no error in CPython 3.8 (i.e. the test
fails, while is passes on CPython <= 3.7). If I run this manually, I even get a
"result":
```python
>>> dll = ctypes.windll.LoadLibrary('tests/demo_dll.dll')
>>> mul_ints = dll.mul_ints
>>> a = mul_ints(7)
>>> a
445564 # !
>>> 445564/7 # Just looking at where this result is coming from ...
63652.0
```
Re-starting Python (3.8) and (intentionally) misconfiguring the function
interestingly also does not change the result:
```python
>>> dll = ctypes.windll.LoadLibrary('tests/demo_dll.dll')
>>> mul_ints = dll.mul_ints
>>> mul_ints.argtypes = (ctypes.c_int16,)
>>> a = mul_ints(7)
>>> a
445564 # Apparently, this is deterministic?!?
```
Just out of curiosity, where is this data coming from?
This ONLY way to prevent things like this to happen is to actually correctly
configure the function:
```python
>>> dll = ctypes.windll.LoadLibrary('tests/demo_dll.dll')
>>> mul_ints = dll.mul_ints
>>> mul_ints.argtypes = (ctypes.c_int16, ctypes.c_int16)
>>> mul_ints(7)
Traceback (most recent call last):
File "", line 1, in
TypeError: this function takes 2 arguments (1 given)
```
This should very CLEARLY be mentioned in the documentation ...
--
___
Python tracker
<https://bugs.python.org/issue38258>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30186] Python interpreter calling "PathCchCombineEx" on startup, Windows 8 and above only
New submission from Sebastian Ernst: I am investigating a bug in Wine: https://bugs.winehq.org/show_bug.cgi?id=42474 The Python 3.6(.1) interpreter fails to start on Wine because of an unimplemented function in Wine: "api-ms-win-core-path-l1-1-0.dll.PathCchCombineEx". While the missing function is clearly a problem in Wine, the fact that PathCchCombineEx is called in the first place is somewhat odd. The call was added to Python 3.6 on 09 Sep 2016 by Steve Dower of Microsoft: https://hg.python.org/cpython/rev/03517dd54977 Logically, Python 3.5.x and prior do not require this call and work flawlessly under Wine. Digging deeper into this, I found that PathCchCombineEx was introduced in Windows 8: https://msdn.microsoft.com/en-us/library/windows/desktop/hh707086(v=vs.85).aspx However, the following page states, that the current version of Python (3.6) should support Windows Vista and 7: https://docs.python.org/3/using/windows.html I am seeking clarification on why PathCchCombineEx is called during the Python interpreter startup although Wine pretends to be Windows 7 and although Python should support Windows Vista & 7. My thinking is that this call might also happen on an actual Windows 7 system under some circumstances and break Python there as well, which would make it a bug in Python. -- components: Interpreter Core, Windows messages: 292430 nosy: paul.moore, smernst, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Python interpreter calling "PathCchCombineEx" on startup, Windows 8 and above only type: behavior versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue30186> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30186] Python interpreter calling "PathCchCombineEx" on startup, Windows 8 and above only
Sebastian Ernst added the comment: Relaying this on behalf of Gijs Vermeulen from Wine: "In my patch I tried returning E_NOTIMPL and I got the error: Fatal Python error: buffer overflow in getpathp.c's join()" -- ___ Python tracker <http://bugs.python.org/issue30186> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
