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).

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.

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.

Would someone like to propose a documentation patch that clarifies this situation.

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?

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.

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.

> 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").