Welcome to Linux Knowledge Base and Tutorial
"The place where you learn linux"
International Rescue Committe

 Create an AccountHome | Submit News | Your Account  

Tutorial Menu
Linux Tutorial Home
Table of Contents

· Introduction to Operating Systems
· Linux Basics
· Working with the System
· Shells and Utilities
· Editing Files
· Basic Administration
· The Operating System
· The X Windowing System
· The Computer Itself
· Networking
· System Monitoring
· Solving Problems
· Security
· Installing and Upgrading
· Linux and Windows

Man Pages
Linux Topics
Test Your Knowledge

Site Menu
Site Map
Copyright Info
Terms of Use
Privacy Info
Masthead / Impressum
Your Account

Private Messages

News Archive
Submit News
User Articles
Web Links


The Web

Who's Online
There are currently, 68 guest(s) and 0 member(s) that are online.

You are an Anonymous user. You can register for free by clicking here




           /* Defining a layer ... */
           #include <perliol.h>


       This document describes the behavior and implementation of
       the PerlIO abstraction described in perlapio when
       "USE_PERLIO" is defined (and "USE_SFIO" is not).

       History and Background

       The PerlIO abstraction was introduced in perl5.003_02 but
       languished as just an abstraction until perl5.7.0. However
       during that time a number of perl extensions switched to
       using it, so the API is mostly fixed to maintain (source)

       The aim of the implementation is to provide the PerlIO API
       in a flexible and platform neutral manner. It is also a
       trial of an "Object Oriented C, with vtables" approach
       which may be applied to perl6.

       Basic Structure

       PerlIO is as a stack of layers.

       The low levels of the stack work with the low-level oper­
       ating system calls (file descriptors in C) getting bytes
       in and out, the higher layers of the stack buffer, filter,
       and otherwise manipulate the I/O.  Terms above and below
       are used to refer to the relative positioning of the stack

       A layer contains a "vtable", the table of I/O operations
       (at C level a table of function pointers), and status
       flags.  The functions in the vtable implement operations
       like "open", "read", and "write".

       When I/O, for example "read", is requested, the request
       goes from Perl first down the stack using "read" functions
       of each layer, then at the bottom the input is requested
       from the operating system services, then the result is
       returned up the stack, finally being interpreted as Perl

       When you do an open() and specify extra PerlIO layers to
       be deployed, the layers you specify are "pushed" on top of
       the already existing default stack.  What exact layers are
       in this default stack depends on a lot of things: your
       operating system, Perl version, Perl compile time configu­
       ration, and Perl runtime configuration.  See PerlIO, "PER­
       LIO" in perlrun, and open for more information.
       sysopen() operates (unsurprisingly) at a lower level in
       the stack than open().  For example in UNIX or UNIX-like
       systems sysopen() operates directly at the level of file
       descriptors: in the terms of PerlIO layers, it uses only
       the "unix" layer, which is a rather thin wrapper on top of
       the UNIX file descriptors.

       Layers vs Disciplines

       Initial discussion of the ability to modify IO streams
       behaviour used the term "discipline" for the entities
       which were added. This came (I believe) from the use of
       the term in "sfio", which in turn borrowed it from "line
       disciplines" on Unix terminals. However, this document
       (and the C code) uses the term "layer".

       This is, I hope, a natural term given the implementation,
       and should avoid connotations that are inherent in earlier
       uses of "discipline" for things which are rather differ­

       Data Structures

       The basic data structure is a PerlIOl:

               typedef struct _PerlIO PerlIOl;
               typedef struct _PerlIO_funcs PerlIO_funcs;
               typedef PerlIOl *PerlIO;

               struct _PerlIO
                PerlIOl *      next;       /* Lower layer */
                PerlIO_funcs * tab;        /* Functions for this layer */
                IV             flags;      /* Various flags for state */

       A "PerlIOl *" is a pointer to the struct, and the applica­
       tion level "PerlIO *" is a pointer to a "PerlIOl *" - i.e.
       a pointer to a pointer to the struct. This allows the
       application level "PerlIO *" to remain constant while the
       actual "PerlIOl *" underneath changes. (Compare perl's "SV
       *" which remains constant while its "sv_any" field changes
       as the scalar's type changes.) An IO stream is then in
       general represented as a pointer to this linked-list of

       It should be noted that because of the double indirection
       in a "PerlIO *", a "&(perlio->next)" "is" a "PerlIO *",
       and so to some degree at least one layer can use the
       "standard" API on the next layer down.

       A "layer" is composed of two parts:
       "PerlIO_xxxxx" functions:

         struct _PerlIO_funcs
          Size_t               fsize;
          char *               name;
          Size_t               size;
          IV           kind;
          IV           (*Pushed)(pTHX_ PerlIO *f,const char *mode,SV *arg, PerlIO_funcs *tab);
          IV           (*Popped)(pTHX_ PerlIO *f);
          PerlIO *     (*Open)(pTHX_ PerlIO_funcs *tab,
                               AV *layers, IV n,
                               const char *mode,
                               int fd, int imode, int perm,
                               PerlIO *old,
                               int narg, SV **args);
          IV           (*Binmode)(pTHX_ PerlIO *f);
          SV *         (*Getarg)(pTHX_ PerlIO *f, CLONE_PARAMS *param, int flags)
          IV           (*Fileno)(pTHX_ PerlIO *f);
          PerlIO *     (*Dup)(pTHX_ PerlIO *f, PerlIO *o, CLONE_PARAMS *param, int flags)
          /* Unix-like functions - cf sfio line disciplines */
          SSize_t      (*Read)(pTHX_ PerlIO *f, void *vbuf, Size_t count);
          SSize_t      (*Unread)(pTHX_ PerlIO *f, const void *vbuf, Size_t count);
          SSize_t      (*Write)(pTHX_ PerlIO *f, const void *vbuf, Size_t count);
          IV           (*Seek)(pTHX_ PerlIO *f, Off_t offset, int whence);
          Off_t        (*Tell)(pTHX_ PerlIO *f);
          IV           (*Close)(pTHX_ PerlIO *f);
          /* Stdio-like buffered IO functions */
          IV           (*Flush)(pTHX_ PerlIO *f);
          IV           (*Fill)(pTHX_ PerlIO *f);
          IV           (*Eof)(pTHX_ PerlIO *f);
          IV           (*Error)(pTHX_ PerlIO *f);
          void         (*Clearerr)(pTHX_ PerlIO *f);
          void         (*Setlinebuf)(pTHX_ PerlIO *f);
          /* Perl's snooping functions */
          STDCHAR *    (*Get_base)(pTHX_ PerlIO *f);
          Size_t       (*Get_bufsiz)(pTHX_ PerlIO *f);
          STDCHAR *    (*Get_ptr)(pTHX_ PerlIO *f);
          SSize_t      (*Get_cnt)(pTHX_ PerlIO *f);
          void         (*Set_ptrcnt)(pTHX_ PerlIO *f,STDCHAR *ptr,SSize_t cnt);

       The first few members of the struct give a function table
       size for compatibility check "name" for the layer, the
       size to "malloc" for the per-instance data, and some flags
       which are attributes of the class as whole (such as
       whether it is a buffering layer), then follow the func­
       tions which fall into four basic groups:

       1.  Opening and setup functions

       2.  Basic IO operations

       Per-instance Data

       The per-instance data are held in memory beyond the basic
       PerlIOl struct, by making a PerlIOl the first member of
       the layer's struct thus:

               typedef struct
                struct _PerlIO base;       /* Base "class" info */
                STDCHAR *      buf;        /* Start of buffer */
                STDCHAR *      end;        /* End of valid part of buffer */
                STDCHAR *      ptr;        /* Current position in buffer */
                Off_t          posn;       /* Offset of buf into the file */
                Size_t         bufsiz;     /* Real size of buffer */
                IV             oneword;    /* Emergency buffer */
               } PerlIOBuf;

       In this way (as for perl's scalars) a pointer to a Per­
       lIOBuf can be treated as a pointer to a PerlIOl.

       Layers in action.

                       table           perlio          unix
                   |           |
                   +-----------+    +----------+    +--------+
          PerlIO ->|           |--->|  next    |--->|  NULL  |
                   +-----------+    +----------+    +--------+
                   |           |    |  buffer  |    |   fd   |
                   +-----------+    |          |    +--------+
                   |           |    +----------+

       The above attempts to show how the layer scheme works in a
       simple case.  The application's "PerlIO *" points to an
       entry in the table(s) representing open (allocated) han­
       dles. For example the first three slots in the table cor­
       respond to "stdin","stdout" and "stderr". The table in
       turn points to the current "top" layer for the handle - in
       this case an instance of the generic buffering layer "per­
       lio". That layer in turn points to the next layer down -
       in this case the lowlevel "unix" layer.

       The above is roughly equivalent to a "stdio" buffered
       stream, but with much more flexibility:

       ·   If Unix level "read"/"write"/"lseek" is not appropri­
           ate for (say) sockets then the "unix" layer can be
           replaced (at open time or even dynamically) with a
           "socket" layer.

       ·   Different handles can have different buffering
           schemes. The "top" layer could be the "mmap" layer if
           tion. This layer can be used on any platform, not just
           those that normally do such things.

       Per-instance flag bits

       The generic flag bits are a hybrid of "O_XXXXX" style
       flags deduced from the mode string passed to "Per­
       lIO_open()", and state bits for typical buffer layers.

           End of file.

           Writes are permitted, i.e. opened as "w" or "r+" or
           "a", etc.

           Reads are permitted i.e. opened "r" or "w+" (or even
           "a+" - ick).

           An error has occurred (for "PerlIO_error()").

           Truncate file suggested by open mode.

           All writes should be appends.

           Layer is performing Win32-like "\n" mapped to CR,LF
           for output and CR,LF mapped to "\n" for input. Nor­
           mally the provided "crlf" layer is the only layer that
           need bother about this. "PerlIO_binmode()" will mess
           with this flag rather than add/remove layers if the
           "PERLIO_K_CANCRLF" bit is set for the layers class.

           Data written to this layer should be UTF-8 encoded;
           data provided by this layer should be considered UTF-8
           encoded. Can be set on any layer by ":utf8" dummy
           layer. Also set on ":encoding" layer.

           Layer is unbuffered - i.e. write to next layer down
           should occur for each write to this layer.

           The buffer for this layer currently holds data written
           to it but not sent to next layer.


           This instance of this layer supports the "fast "gets""
           interface.  Normally set based on "PERLIO_K_FASTGETS"
           for the class and by the existence of the function(s)
           in the table. However a class that normally provides
           that interface may need to avoid it on a particular
           instance. The "pending" layer needs to do this when it
           is pushed above a layer which does not support the
           interface.  (Perl's "sv_gets()" does not expect the
           streams fast "gets" behaviour to change during one

       Methods in Detail

                   Size_t fsize;

           Size of the function table. This is compared against
           the value PerlIO code "knows" as a compatibility
           check. Future versions may be able to tolerate layers
           compiled against an old version of the headers.

                   char * name;

           The name of the layer whose open() method Perl should
           invoke on open().  For example if the layer is called
           APR, you will call:

             open $fh, ">:APR", ...

           and Perl knows that it has to invoke the Per­
           lIOAPR_open() method implemented by the APR layer.

                   Size_t size;

           The size of the per-instance data structure, e.g.:


           If this field is zero then "PerlIO_pushed" does not
           malloc anything and assumes layer's Pushed function
           will do any required layer stack manipulation - used
           to avoid malloc/free overhead for dummy layers.  If
           the field is non-zero it must be at least the size of
           "PerlIOl", "PerlIO_pushed" will allocate memory for
           the layer's data structures and link new layer onto
           the stream's stack. (If the layer's Pushed method
           returns an error indication the layer is popped
               Layer can translate between "\n" and CRLF line

           * PERLIO_K_FASTGETS
               Layer allows buffer snooping.

           * PERLIO_K_MULTIARG
               Used when the layer's open() accepts more argu­
               ments than usual. The extra arguments should come
               not before the "MODE" argument. When this flag is
               used it's up to the layer to validate the args.

                   IV      (*Pushed)(pTHX_ PerlIO *f,const char *mode, SV *arg);

           The only absolutely mandatory method. Called when the
           layer is pushed onto the stack.  The "mode" argument
           may be NULL if this occurs post-open. The "arg" will
           be non-"NULL" if an argument string was passed. In
           most cases this should call "PerlIOBase_pushed()" to
           convert "mode" into the appropriate "PERLIO_F_XXXXX"
           flags in addition to any actions the layer itself
           takes.  If a layer is not expecting an argument it
           need neither save the one passed to it, nor provide
           "Getarg()" (it could perhaps "Perl_warn" that the
           argument was un-expected).

           Returns 0 on success. On failure returns -1 and should
           set errno.

                   IV      (*Popped)(pTHX_ PerlIO *f);

           Called when the layer is popped from the stack. A
           layer will normally be popped after "Close()" is
           called. But a layer can be popped without being closed
           if the program is dynamically managing layers on the
           stream. In such cases "Popped()" should free any
           resources (buffers, translation tables, ...) not held
           directly in the layer's struct.  It should also
           "Unread()" any unconsumed data that has been read and
           buffered from the layer below back to that layer, so
           that it can be re-provided to what ever is now above.

           Returns 0 on success and failure.  If "Popped()"
           returns true then perlio.c assumes that either the
           layer has popped itself, or the layer is super special
           and needs to be retained for other reasons.  In most
           cases it should return false.

                   PerlIO *        (*Open)(...);

           Open should (perhaps indirectly) call "PerlIO_allo­
           cate()" to allocate a slot in the table and associate
           it with the layers information for the opened file, by
           calling "PerlIO_push".  The layers AV is an array of
           all the layers destined for the "PerlIO *", and any
           arguments passed to them, n is the index into that
           array of the layer being called. The macro "PerlIOArg"
           will return a (possibly "NULL") SV * for the argument
           passed to the layer.

           The mode string is an ""fopen()"-like" string which
           would match the regular expression

           The 'I' prefix is used during creation of
           "stdin".."stderr" via special "PerlIO_fdopen" calls;
           the '#' prefix means that this is "sysopen" and that
           imode and perm should be passed to "PerlLIO_open3";
           'r' means read, 'w' means write and 'a' means append.
           The '+' suffix means that both reading and writ­
           ing/appending are permitted.  The 'b' suffix means
           file should be binary, and 't' means it is text.
           (Almost all layers should do the IO in binary mode,
           and ignore the b/t bits. The ":crlf" layer should be
           pushed to handle the distinction.)

           If old is not "NULL" then this is a "PerlIO_reopen".
           Perl itself does not use this (yet?) and semantics are
           a little vague.

           If fd not negative then it is the numeric file
           descriptor fd, which will be open in a manner compati­
           ble with the supplied mode string, the call is thus
           equivalent to "PerlIO_fdopen". In this case nargs will
           be zero.

           If nargs is greater than zero then it gives the number
           of arguments passed to "open", otherwise it will be 1
           if for example "PerlIO_open" was called.  In simple
           cases SvPV_nolen(*args) is the pathname to open.

           Having said all that translation-only layers do not
           need to provide "Open()" at all, but rather leave the
           opening to a lower level layer and wait to be
           "pushed".  If a layer does provide "Open()" it should
           normally call the "Open()" method of next layer down
           (if any) and then push itself on top if that succeeds.

           If "PerlIO_push" was performed and open has failed, it
           must "PerlIO_pop" itself, since if it's not, the layer
           won't be removed and may cause bad problems.

                                       CLONE_PARAMS *param, int flags);

           Optional. If present should return an SV * represent­
           ing the string argument passed to the layer when it
           was pushed. e.g. ":encoding(ascii)" would return an
           SvPV with value "ascii". (param and flags arguments
           can be ignored in most cases)

                   IV        (*Fileno)(pTHX_ PerlIO *f);

           Returns the Unix/Posix numeric file descriptor for the
           handle. Normally "PerlIOBase_fileno()" (which just
           asks next layer down) will suffice for this.

           Returns -1 on error, which is considered to include
           the case where the layer cannot provide such a file

                   PerlIO * (*Dup)(pTHX_ PerlIO *f, PerlIO *o,
                                   CLONE_PARAMS *param, int flags);

           XXX: Needs more docs.

           Used as part of the "clone" process when a thread is
           spawned (in which case param will be non-NULL) and
           when a stream is being duplicated via '&' in the

           Similar to "Open", returns PerlIO* on success, "NULL"
           on failure.

                   SSize_t (*Read)(pTHX_ PerlIO *f, void *vbuf, Size_t count);

           Basic read operation.

           Typically will call "Fill" and manipulate pointers
           (possibly via the API).  "PerlIOBuf_read()" may be
           suitable for derived classes which provide "fast gets"

           Returns actual bytes read, or -1 on an error.

                   SSize_t (*Unread)(pTHX_ PerlIO *f,
                                     const void *vbuf, Size_t count);

           A superset of stdio's "ungetc()". Should arrange for
           future reads to see the bytes in "vbuf". If there is
           no obviously better implementation then "Per­

           Position the file pointer. Should normally call its
           own "Flush" method and then the "Seek" method of next
           layer down.

           Returns 0 on success, -1 on failure.

                   Off_t   (*Tell)(pTHX_ PerlIO *f);

           Return the file pointer. May be based on layers cached
           concept of position to avoid overhead.

           Returns -1 on failure to get the file pointer.

                   IV      (*Close)(pTHX_ PerlIO *f);

           Close the stream. Should normally call "Per­
           lIOBase_close()" to flush itself and close layers
           below, and then deallocate any data structures
           (buffers, translation tables, ...) not  held directly
           in the data structure.

           Returns 0 on success, -1 on failure.

                   IV      (*Flush)(pTHX_ PerlIO *f);

           Should make stream's state consistent with layers
           below. That is, any buffered write data should be
           written, and file position of lower layers adjusted
           for data read from below but not actually consumed.
           (Should perhaps "Unread()" such data to the lower

           Returns 0 on success, -1 on failure.

                   IV      (*Fill)(pTHX_ PerlIO *f);

           The buffer for this layer should be filled (for read)
           from layer below.  When you "subclass" PerlIOBuf
           layer, you want to use its _read method and to supply
           your own fill method, which fills the PerlIOBuf's

           Returns 0 on success, -1 on failure.

                   IV      (*Eof)(pTHX_ PerlIO *f);

                   void    (*Clearerr)(pTHX_ PerlIO *f);

           Clear end-of-file and error indicators. Should call
           "PerlIOBase_clearerr()" to set the "PERLIO_F_XXXXX"
           flags, which may suffice.

                   void    (*Setlinebuf)(pTHX_ PerlIO *f);

           Mark the stream as line buffered. "PerlIOBase_set­
           linebuf()" sets the PERLIO_F_LINEBUF flag and is nor­
           mally sufficient.

                   STDCHAR *       (*Get_base)(pTHX_ PerlIO *f);

           Allocate (if not already done so) the read buffer for
           this layer and return pointer to it. Return NULL on

                   Size_t  (*Get_bufsiz)(pTHX_ PerlIO *f);

           Return the number of bytes that last "Fill()" put in
           the buffer.

                   STDCHAR *       (*Get_ptr)(pTHX_ PerlIO *f);

           Return the current read pointer relative to this
           layer's buffer.

                   SSize_t (*Get_cnt)(pTHX_ PerlIO *f);

           Return the number of bytes left to be read in the cur­
           rent buffer.

                   void    (*Set_ptrcnt)(pTHX_ PerlIO *f,
                                         STDCHAR *ptr, SSize_t cnt);

           Adjust the read pointer and count of bytes to match
           "ptr" and/or "cnt".  The application (or layer above)
           must ensure they are consistent.  (Checking is allowed
           by the paranoid.)

       Implementing PerlIO Layers

       If you find the implementation document unclear or not

           PerlIO::gzip and APR::PerlIO (mod_perl 2.0) on CPAN.

       * Perl implementations
           PerlIO::via::QuotedPrint in the Perl core and Per­
           lIO::via::* on CPAN.

       If you are creating a PerlIO layer, you may want to be
       lazy, in other words, implement only the methods that
       interest you.  The other methods you can either replace
       with the "blank" methods


       (which do nothing, and return zero and -1, respectively)
       or for certain methods you may assume a default behaviour
       by using a NULL method.  The Open method looks for help in
       the 'parent' layer.  The following table summarizes the

           method      behaviour with NULL

           Clearerr    PerlIOBase_clearerr
           Close       PerlIOBase_close
           Dup         PerlIOBase_dup
           Eof         PerlIOBase_eof
           Error       PerlIOBase_error
           Fileno      PerlIOBase_fileno
           Fill        FAILURE
           Flush       SUCCESS
           Getarg      SUCCESS
           Get_base    FAILURE
           Get_bufsiz  FAILURE
           Get_cnt     FAILURE
           Get_ptr     FAILURE
           Open        INHERITED
           Popped      SUCCESS
           Pushed      SUCCESS
           Read        PerlIOBase_read
           Seek        FAILURE
           Set_cnt     FAILURE
           Set_ptrcnt  FAILURE
           Setlinebuf  PerlIOBase_setlinebuf
           Tell        FAILURE
           Unread      PerlIOBase_unread
           Write       FAILURE

        FAILURE        Set errno (to EINVAL in UNIXish, to LIB$_INVARG in VMS) and
                       return -1 (for numeric return values) or NULL (for pointers)
        INHERITED      Inherited from the layer below
        SUCCESS        Return 0 (for numeric return values) or a pointer
           used as a "base class" for other layers. (For example
           its "Read()" method is implemented in terms of the
           "Get_cnt()"/"Get_ptr()"/"Set_ptrcnt()" methods).

           "perlio" over "unix" provides a complete replacement
           for stdio as seen via PerlIO API. This is the default
           for USE_PERLIO when system's stdio does not permit
           perl's "fast gets" access, and which do not distin­
           guish between "O_TEXT" and "O_BINARY".

           A layer which provides the PerlIO API via the layer
           scheme, but implements it by calling system's stdio.
           This is (currently) the default if system's stdio pro­
           vides sufficient access to allow perl's "fast gets"
           access and which do not distinguish between "O_TEXT"
           and "O_BINARY".

           A layer derived using "perlio" as a base class. It
           provides Win32-like "\n" to CR,LF translation. Can
           either be applied above "perlio" or serve as the
           buffer layer itself. "crlf" over "unix" is the default
           if system distinguishes between "O_TEXT" and
           "O_BINARY" opens. (At some point "unix" will be
           replaced by a "native" Win32 IO layer on that plat­
           form, as Win32's read/write layer has various draw­
           backs.) The "crlf" layer is a reasonable model for a
           layer which transforms data in some way.

           If Configure detects "mmap()" functions this layer is
           provided (with "perlio" as a "base") which does "read"
           operations by mmap()ing the file. Performance improve­
           ment is marginal on modern systems, so it is mainly
           there as a proof of concept. It is likely to be unbun­
           dled from the core at some point. The "mmap" layer is
           a reasonable model for a minimalist "derived" layer.

           An "internal" derivative of "perlio" which can be used
           to provide Unread() function for layers which have no
           buffer or cannot be bothered.  (Basically this layer's
           "Fill()" pops itself off the stack and so resumes
           reading from layer below.)

           A dummy layer which never exists on the layer stack.
           Instead when "pushed" it actually pops the stack
           removing itself, it then calls Binmode function table
           entry on all the layers in the stack - normally this
           (via PerlIOBase_binmode) removes any layers which do

       Layers can made available by extension modules. When an
       unknown layer is encountered the PerlIO code will perform
       the equivalent of :

          use PerlIO 'layer';

       Where layer is the unknown layer. PerlIO.pm will then
       attempt to:

          require PerlIO::layer;

       If after that process the layer is still not defined then
       the "open" will fail.

       The following extension layers are bundled with perl:

              use Encoding;

           makes this layer available, although PerlIO.pm "knows"
           where to find it.  It is an example of a layer which
           takes an argument as it is called thus:

              open( $fh, "<:encoding(iso-8859-7)", $pathname );

           Provides support for reading data from and writing
           data to a scalar.

              open( $fh, "+<:scalar", \$scalar );

           When a handle is so opened, then reads get bytes from
           the string value of $scalar, and writes change the
           value. In both cases the position in $scalar starts as
           zero but can be altered via "seek", and determined via

           Please note that this layer is implied when calling
           open() thus:

              open( $fh, "+<", \$scalar );

           Provided to allow layers to be implemented as Perl
           code.  For instance:

              use PerlIO::via::StripHTML;
              open( my $fh, "<:via(StripHTML)", "index.html" );

           See PerlIO::via for details.

                 char *mode; /* "w", "r", etc */
                 const char *layers = ":APR"; /* the layer name */
                 PerlIO *f = PerlIO_allocate(aTHX);
                 if (!f) {
                     return NULL;

                 PerlIO_apply_layers(aTHX_ f, mode, layers);

                 if (f) {
                     PerlIOAPR *st = PerlIOSelf(f, PerlIOAPR);
                     /* fill in the st struct, as in _open() */
                     st->file = file;
                     PerlIOBase(f)->flags |= PERLIO_F_OPEN;

                     return f;
                 return NULL;

       ·   fix/add the documentation in places marked as XXX.

       ·   The handling of errors by the layer is not specified.
           e.g. when $!  should be set explicitly, when the error
           handling should be just delegated to the top layer.

           Probably give some hints on using SETERRNO() or point­
           ers to where they can be found.

       ·   I think it would help to give some concrete examples
           to make it easier to understand the API. Of course I
           agree that the API has to be concise, but since there
           is no second document that is more of a guide, I think
           that it'd make it easier to start with the doc which
           is an API, but has examples in it in places where
           things are unclear, to a person who is not a PerlIO
           guru (yet).

perl v5.8.1                 2003-09-02                 PERLIOL(1)

There are several different ways to navigate the tutorial.



Security Code
Security Code
Type Security Code

Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Help if you can!

Amazon Wish List

Did You Know?
The Linux Tutorial welcomes your suggestions and ideas.


Tell a Friend About Us

Bookmark and Share

Web site powered by PHP-Nuke

Is this information useful? At the very least you can help by spreading the word to your favorite newsgroups, mailing lists and forums.
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters. Articles are the property of their respective owners. Unless otherwise stated in the body of the article, article content (C) 1994-2013 by James Mohr. All rights reserved. The stylized page/paper, as well as the terms "The Linux Tutorial", "The Linux Server Tutorial", "The Linux Knowledge Base and Tutorial" and "The place where you learn Linux" are service marks of James Mohr. All rights reserved.
The Linux Knowledge Base and Tutorial may contain links to sites on the Internet, which are owned and operated by third parties. The Linux Tutorial is not responsible for the content of any such third-party site. By viewing/utilizing this web site, you have agreed to our disclaimer, terms of use and privacy policy. Use of automated download software ("harvesters") such as wget, httrack, etc. causes the site to quickly exceed its bandwidth limitation and are therefore expressly prohibited. For more details on this, take a look here

PHP-Nuke Copyright © 2004 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 0.08 Seconds