[pypy-dev] r55005 - in pypy/branch/win32port/pypy: lib lib/_ctypes module/_rawffi module/_rawffi/test rlib rlib/test

Maciej Fijalkowski fijall at gmail.com
Wed May 21 15:38:00 CEST 2008


> Even cooler that I can read from day to day how you reimplemented
> ctypes for pypy :-)
>
> "how to find c library" - is only a problem on windows (which I hope can
> now be solved better).  On linux (not sure about *nix) simply call
> LoadLibrary(None) [=> dlopen(NULL) in C], and you can get all functions
> from all loaded shared libs from that handle.

No. That does not sound to me like a robust solution. (We should
probably move this discussion to ctypes-users though). Because you can
have strange stuff in there and I really want to access libc, not
something else. I think that helper in ctypes that gives you *exactly*
libc, not only on windows is a good thing to have.

>
> "how to get errno" - the problem with this is that errno is only valid
> (in the calling thread) until another stdlib library function has been
> called in this thread.
>
> So, since arbitrary code can run (in CPython's ctypes, at least) between
> the time a function in a shared lib has been called and the time you access
> errno there is no guarantee that it is still valid.
> There has been some discussion on the ctypes-users list some months ago
> about that, and the only reliable way to get errno for the function call
> seems to be to get errno immediately after the function call.
> The question is how to make this value available to the calling Python code.
> Two ways were discussed: To attach the errno value in thread local storage
> to the function object itself, or to pass it to the '.errcheck' function.
> Nothing of this has yet been implemented in ctypes.
>

Ah! Good :) I think I should start reading ctypes mailing list. We
have support for such stuff already, as we need to get errno when
testing posix stuff (I can explain in details if you like :)

It sounds like vastly better solution that ours, please implement it,
we'll follow :)

Cheers,
fijal



More information about the Pypy-dev mailing list