info/advices about python readline implementation
Hi, Lisandro Dalcin and me are working on a common version of our patches ([1232343],[955928]) that we plan to submit soon (this would close the two previously proposed patches, and we plan also to review 5 other patches to push this one before 2.5 ;-) ). We would like this new patch to be as clean and as safe as possible, but to do so we would need some infos/advices from the list, and in particular peoples having worked in the readline C implementation, i.e. in modules Modules/readline.c, Parser/myreadline.c (PyOS_StdioReadline, PyOS_StdioReadline, vms__StdioReadline), Python/bltinmodule.c (builtin_raw_input). First a general question about implementation guidelines for CPython: -is it ok to initialize a static pointer to a non-null value (the address of a predefined function) at compile time? ANSI-C (or even pre-ansi C afaik) accept this, we have tested it on various linux and unix, and there are occurrences of similar construct in the python C sources, but not so many and not for function pointers (or I did not found it ;) ). We wonder if this can cause problem on some platforms not correctly implementing C standard(s) but that python have to support nonetheless, or if there is a feeling against it...The idea is to initialize PyOS_ReadlineFunctionPointer this way. Then something about the VMS platform support: -readline seems to make uses of the extern function vms__StdioReadline() on VMS...Where can we find the source or doc about this function? In particular, we would like to know if this function call (or can call) PyOS_StdioReadline, which would cause infinite recursion in some version of our patch....without havind access to VMS for testing or info about vms__StdioReadline, this is impossible to know... Thanks for any info, Greg.
On 8/28/05, Gregory Lielens
-is it ok to initialize a static pointer to a non-null value (the address of a predefined function) at compile time?
Yes. All of Python's standard types and modules use this idiom.
We wonder if this can cause problem on some platforms not correctly implementing C standard(s) but that python have to support nonetheless,
If a platform doesn't have a working C89 compiler, we generally wait for the compiler to be fixed (or for GCC to be ported). We might compromise when a platform doesn't support full POSIX, but this seems purely a language issue and there can be no excuses -- C89 is older than Python!
Then something about the VMS platform support: -readline seems to make uses of the extern function vms__StdioReadline() on VMS...Where can we find the source or doc about this function? In particular, we would like to know if this function call (or can call) PyOS_StdioReadline, which would cause infinite recursion in some version of our patch....without havind access to VMS for testing or info about vms__StdioReadline, this is impossible to know...
I have no idea; Googling for it only showed up discussions of readline.c. You might write the authors of the patch that introduced it (the same Google query will find the info); if they don't respond, I'm not sure that it's worth worrying about. My personal guess is that it's probably a VMS internal function, which would reduce the probability of it calling back to PyOS_StdioReadline to zero. It can't be a Python specific thing, because it doesn't have a 'Py' prefix. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Then something about the VMS platform support: -readline seems to make uses of the extern function vms__StdioReadline() on VMS...Where can we find the source or doc about this function? In particular, we would like to know if this function call (or can call) PyOS_StdioReadline, which would cause infinite recursion in some version of our patch....without havind access to VMS for testing or info about vms__StdioReadline, this is impossible to know...
I have no idea; Googling for it only showed up discussions of readline.c. You might write the authors of the patch that introduced it (the same Google query will find the info); if they don't respond, I'm not sure that it's worth worrying about.
Googling only returned comments or queries by either Lisandro or me, but it was loewis (Martin v. Löwis ?) that comited this change in May 2003 with the comment Patch #708495: Port more stuff to OpenVMS. Tha patch was introduced by Jean-François Piéronne, who explained: myreadline.c Use of vms__StdioReadline
My personal guess is that it's probably a VMS internal function, which would reduce the probability of it calling back to PyOS_StdioReadline to zero. It can't be a Python specific thing, because it doesn't have a 'Py' prefix.
My guess too, especially as using PyOS_StdioReadline (which is not in the python API) would be asking for trouble...We will thus consider that there is no risk of infinite recursion, except if someone say otherwise... Thanks a lot for these fast and usefull informations! Greg.
participants (2)
-
Gregory Lielens
-
Guido van Rossum