Anatomy of 'perl', the interpreter

John M. Dlugosz has asked for the wisdom of the Perl Monks concerning the following question:

I found that under win32 the CPerlHost class contains a IPerlStdIO interface which contains, among other things, an fopen (const char *filename, const char *mode) implementation.

I see that the implementation of this function, under Win32, when Wide API is enabled, when the "use bytes" pragma is not in effect, will treat the parameters as being UTF-8.

But, Perl treats strings as byte or utf8 on a string-by-string basis, and is lazy about switching to the utf8 representation.

So my question is: does the interpreter force the string to be promoted when making some internal function calls? Where does the opcode generated by the open command actually call the native code?

—John

Comment on Anatomy of 'perl', the interpreter Download Code

Replies are listed 'Best First'.
Re: Anatomy of 'perl', the interpreter by hv (Prior) on Feb 10, 2005 at 14:36 UTC
Each perl opcode is implemented by a `pp_*` routine, in this case `pp_open()` (in pp_sys.c). In the latest sources, that eventually calls `do_openn()` in doio.c. That does a lot of preparatory work, and may hand off to one of various calls (eg, we may be opening a pipe, or duping an existing file handle), but in the simple case it hands off to `PerlIO_openn()` in perlio.c. What happens next depends on the defines with which your perl was compiled. If you are using PERLIO, I think it then interrogates the layer stack for a layer that knows how to handle open, and then calls it. The layers consist of a table of function pointers, defined in perliol.h (and documented in pod/perliol.pod). I'm not sure where these tables are initialised. I think in your case you are talking about the IPerlSys abstraction, mostly defined in iperlsys.h where I see `PerlSIO_fopen()` being defined in terms of the `fopen()` implementation you mention; that appears to be used only in `PerlIOStdio_open()` in perlio.c. However the 'IPerlStdIO' structure definition looks very similar to a PerlIO vector table, so I may be missing a point where it is used as one and its entry for `pOpen` being called directly. I'm afraid I don't know enough about this area to give chapter and verse, but I hope I've given you enough information to help track down what you're actually looking for. Hugo	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re: Anatomy of 'perl', the interpreter
by hv (Prior) on Feb 10, 2005 at 14:36 UTC

Each perl opcode is implemented by a pp_* routine, in this case pp_open() (in pp_sys.c).

In the latest sources, that eventually calls do_openn() in doio.c. That does a lot of preparatory work, and may hand off to one of various calls (eg, we may be opening a pipe, or duping an existing file handle), but in the simple case it hands off to PerlIO_openn() in perlio.c. What happens next depends on the defines with which your perl was compiled.

If you are using PERLIO, I think it then interrogates the layer stack for a layer that knows how to handle open, and then calls it. The layers consist of a table of function pointers, defined in perliol.h (and documented in pod/perliol.pod). I'm not sure where these tables are initialised.

I think in your case you are talking about the IPerlSys abstraction, mostly defined in iperlsys.h where I see PerlSIO_fopen() being defined in terms of the fopen() implementation you mention; that appears to be used only in PerlIOStdio_open() in perlio.c. However the 'IPerlStdIO' structure definition looks very similar to a PerlIO vector table, so I may be missing a point where it is used as one and its entry for pOpen being called directly.

I'm afraid I don't know enough about this area to give chapter and verse, but I hope I've given you enough information to help track down what you're actually looking for.

Hugo

[reply]
[d/l]
[select]