classification
Title: [doc] ctypes: use_errno=True does not work
Type: enhancement Stage: needs patch
Components: ctypes, Documentation Versions: Python 3.11
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: theller Nosy List: Matt.Jones, amaury.forgeotdarc, belopolsky, eryksun, iritkatriel, marcin.bachry, meador.inge, nikratio
Priority: normal Keywords: easy

Created on 2010-01-23 00:18 by nikratio, last changed 2021-05-18 20:36 by eryksun.

Files
File name Uploaded Description Edit
test1.py nikratio, 2010-01-23 00:18 Test case
Messages (8)
msg98171 - (view) Author: Nikolaus Rath (nikratio) * Date: 2010-01-23 00:18
On my system (Ubuntu Karmic, Python 2.6.4 (r264:75706, Dec  7 2009, 18:45:15), Kernel 2.6.31-17-generic, libc6 2.10.1-0ubuntu16) the attached test script produces the following output:

Traceback (most recent call last):
  File "test1.py", line 27, in <module>
    raise OSError(err, os.strerror(err), path)
OSError: [Errno 0] Success: '/does/not/exist'

So the function call failed, but the errno provided by ctypes is zero.

(There are two variants of construction the getxattr() foreign function in the script and both produce the same result).
msg98188 - (view) Author: Marcin Bachry (marcin.bachry) Date: 2010-01-23 16:58
In the libc case you shouldn't give absolute path in CDLL: CDLL('libc.so.6') is better. You use "/lib/libc.so.6" path, but Python (and ctypes.so) actually uses something like "/lib/tls/i686/cmov/libc.so.6" - these are two separate libraries with separate "errno" variables, mapped to different memory regions. Your call to getxattr modifies errno in the former library, but ctypes get_errno() fetches value from the latter library.

If I fix CDLL() call, the test works ok for me.
msg98195 - (view) Author: Nikolaus Rath (nikratio) * Date: 2010-01-23 19:37
I can confirm that without the path it works for me too.

But I have to admit that I don't really understand your explanation. Should I generally not use full paths with CDLL? Or just in the case of libc?

In either case, I think the ctypes dokumentation could be more explicit about this.
msg189784 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2013-05-21 20:52
Would someone like to propose a documentation patch that clarifies this situation.
msg189807 - (view) Author: Matt Jones (Matt.Jones) Date: 2013-05-22 12:03
Is this really a documentation issue?  Is it not generally understood that using absolute paths to libraries is a bad idea due to the amount of PATH/symlink spaghetti that the average file system contains?
msg189886 - (view) Author: Nikolaus Rath (nikratio) * Date: 2013-05-24 00:05
Matt, I believe in that case it's still a documentation issue, because then the documentation probably should say that using absolute paths to libraries is a bad idea in general.
msg393894 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2021-05-18 18:15
The recommendation not to use absolute paths in CDLL is still not mentioned in the docs:
https://docs.python.org/3/library/ctypes.html#ctypes.CDLL

Adding the (active) ctypes experts to nosy.
msg393906 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2021-05-18 20:36
> The recommendation not to use absolute paths in CDLL is still 
> not mentioned in the docs:

It's not generally the case. Load just a base filename only if the shared library is in the loader's search path. Otherwise use a qualified path that contains at least one path separator (e.g. "./library.dll").
History
Date User Action Args
2021-05-18 20:36:39eryksunsetnosy: + eryksun
messages: + msg393906
2021-05-18 18:15:47iritkatrielsettype: behavior -> enhancement
title: ctypes: use_errno=True does not work -> [doc] ctypes: use_errno=True does not work
components: + Documentation

keywords: + easy
nosy: + iritkatriel, belopolsky, amaury.forgeotdarc, meador.inge, - theller
versions: + Python 3.11, - Python 2.6, Python 3.1
messages: + msg393894
2014-02-03 18:26:42BreamoreBoysetnosy: - BreamoreBoy
2013-05-25 15:53:27vstinnersettitle: use_errno=True does not work -> ctypes: use_errno=True does not work
2013-05-24 00:05:22nikratiosetmessages: + msg189886
2013-05-22 12:03:31Matt.Jonessetnosy: + Matt.Jones
messages: + msg189807
2013-05-21 20:52:15BreamoreBoysetnosy: + BreamoreBoy
messages: + msg189784
2010-01-23 19:37:51nikratiosetmessages: + msg98195
2010-01-23 16:59:00marcin.bachrysetnosy: + marcin.bachry
messages: + msg98188
2010-01-23 00:23:04brian.curtinsetpriority: normal
stage: needs patch
2010-01-23 00:18:56nikratiocreate