PERLAPIO(1perl)
π PERLAPIO π
okay bestie, welcome to perlapio β perl's IO abstraction interface, straight out of the Perl Programmers Reference Guide. yes it's a C API page, no it's not boring, come sit with me π«Ά
β¨ SYNOPSIS β¨
#define PERLIO_NOT_STDIO 0 /* For co-existence with stdio only */
#include <perlio.h> /* Usually via #include <perl.h> */
PerlIO *PerlIO_stdin(void);
PerlIO *PerlIO_stdout(void);
PerlIO *PerlIO_stderr(void);
PerlIO *PerlIO_open(const char *path,const char *mode);
PerlIO *PerlIO_fdopen(int fd, const char *mode);
PerlIO *PerlIO_reopen(const char *path, /* deprecated */
const char *mode, PerlIO *old);
int PerlIO_close(PerlIO *f);
int PerlIO_stdoutf(const char *fmt,...)
int PerlIO_puts(PerlIO *f,const char *string);
int PerlIO_putc(PerlIO *f,int ch);
SSize_t PerlIO_write(PerlIO *f,const void *buf,size_t numbytes);
int PerlIO_printf(PerlIO *f, const char *fmt,...);
int PerlIO_vprintf(PerlIO *f, const char *fmt, va_list args);
int PerlIO_flush(PerlIO *f);
int PerlIO_fill(PerlIO *f);
int PerlIO_eof(PerlIO *f);
int PerlIO_error(PerlIO *f);
void PerlIO_clearerr(PerlIO *f);
int PerlIO_getc(PerlIO *d);
int PerlIO_ungetc(PerlIO *f,int ch);
SSize_t PerlIO_read(PerlIO *f, void *buf, size_t numbytes);
Size_t PerlIO_unread(PerlIO *f,const void *vbuf, size_t count
int PerlIO_fileno(PerlIO *f);
void PerlIO_setlinebuf(PerlIO *f);
Off_t PerlIO_tell(PerlIO *f);
int PerlIO_seek(PerlIO *f, Off_t offset, int whence);
void PerlIO_rewind(PerlIO *f);
int PerlIO_getpos(PerlIO *f, SV *save); /* prototype changed */
int PerlIO_setpos(PerlIO *f, SV *saved); /* prototype changed */
int PerlIO_fast_gets(PerlIO *f);
int PerlIO_has_cntptr(PerlIO *f);
SSize_t PerlIO_get_cnt(PerlIO *f);
char *PerlIO_get_ptr(PerlIO *f);
void PerlIO_set_ptrcnt(PerlIO *f, char *ptr, SSize_t count);
int PerlIO_canset_cnt(PerlIO *f); /* deprecated */
void PerlIO_set_cnt(PerlIO *f, int count); /* deprecated */
int PerlIO_has_base(PerlIO *f);
char *PerlIO_get_base(PerlIO *f);
SSize_t PerlIO_get_bufsiz(PerlIO *f);
PerlIO *PerlIO_importFILE(FILE *stdio, const char *mode);
FILE *PerlIO_exportFILE(PerlIO *f, const char *mode);
FILE *PerlIO_findFILE(PerlIO *f);
void PerlIO_releaseFILE(PerlIO *f,FILE *stdio);
int PerlIO_apply_layers(pTHX_ PerlIO *f, const char *mode,
const char *layers);
int PerlIO_binmode(pTHX_ PerlIO *f, int ptype, int imode,
const char *layers);
void PerlIO_debug(const char *fmt,...);
also the manual name is literallyperlapio(the<italic>1perl</italic>bit is just the section, iykyk) β folding that in right here so you're never lost π
πΈ DESCRIPTION πΈ
So here's the tea, bestie: perl's own source code β and any extension that wants maximum portability β should use the functions above instead of the ones sitting in ANSI C's stdio.h. The perl headers (especially perlio.h) #define them all properly for you. no cap.
The functions are modeled on the ones in stdio.h, but the parameter order has been "tidied up a little" β¨ (we love a glow-up).
PerlIO * takes the place of FILE *. And just like FILE *, you should treat it as opaque β it is probably safe to assume it is a pointer to something, and that's all you get, mwah π.
There is one implementation extant, USE_PERLIO. This lets perl have way more control over how IO is done than plain stdio ever would, because it decouples IO from the way the operating system and C library choose to do things. Iconic behaviour honestly.
PerlIO has an extra layer of indirection compared to FILE β it's a pointer-to-a-pointer</badge>. That's what lets the PerlIO * keep a known value while the implementation gets swapped around underneath it at run time π. Which means all those calls up there are true functions (super simple ones, but real functions, not macros) that call the underlying implementation.
This implementation was introduced just after perl5.7.0, and it's described over in perliol. go read that one next, bestie π.
Before 5.16.0, a different implementation was also available: USE_STDIO. In that one, all the functions above were #define'd to stdio functions, or were trivial little wrapper functions that just call stdio. And in that case, PerlIO * was actually FILE *. wild.
That implementation has not been available since 5.16.0. It had been the default implementation before that, ever since it was introduced in perl5.003_02. rip to a real one π.
Because perlio.h is a thin layer (for efficiency, ofc π
), the semantics of these functions are somewhat dependent on the underlying implementation. Where those variations are understood, they're noted below. Periodt.
Heads up: unless otherwise noted, functions return0on success, or a negative value (usuallyEOF, which is usually-1) and seterrnoon error.
π« PerlIO_stdin(), PerlIO_stdout(), PerlIO_stderr()
Use these cuties rather than stdin, stdout, stderr. They're written to look like "function calls" rather than variables on purpose β because that makes it easier to make them function calls if a platform can't export data to loaded modules, or if (say) different threads might have different values. main character design energy honestly π
π« PerlIO_open(path, mode), PerlIO_fdopen(fd,mode)
These correspond to fopen() / fdopen(), and the arguments are the same. They return NULL and set errno if there's an error.
careful bestie: there may be an implementation limit on the number of open handles, and that limit may be lower than the limit on the number of open files β anderrnomay not be set whenNULLis returned if that handle limit is the thing you tripped over. so don't trusterrnoblindly here π
π« PerlIO_reopen(path,mode,f)
While this currently exists in both implementations, perl itself does not use it. And because perl doesn't use it, it is not well tested π.
Perl prefers to dup the new low-level descriptor to the descriptor used by the existing PerlIO. That may become the behaviour of this function in the future. so like, watch this space β¨
π« PerlIO_printf(f,fmt,...), PerlIO_vprintf(f,fmt,a)
These are the fprintf() / vfprintf() equivalents π
π« PerlIO_stdoutf(fmt,...)
This is the printf() equivalent. printf is #defined to this function, so it is (currently) legal to use printf(fmt,...) in perl sources. slay.
π« PerlIO_read(f,buf,count), PerlIO_write(f,buf,count)
These correspond functionally to fread() and fwrite() β but the arguments and return values are different, bestie, don't get it twisted.
The PerlIO_read() and PerlIO_write() signatures have been modeled on the more sane low level read() and write() functions instead:
- the
"file"argument is passed first π₯ - there is only one
"count" - and the return value can distinguish between error and
EOF
Returns a byte count if successful (which may be zero or positive), and returns a negative value and sets errno on error. Depending on implementation, errno may be EINTR if the operation was interrupted by a signal. rude of it tbh.
π« PerlIO_fill(f)
Fills the buffer associated with f with data from the layer below. PerlIO_read calls this as part of its normal operation. Returns 0 upon success; -1 on failure. simple as π
π« PerlIO_close(f)
Depending on implementation, errno may be EINTR if the operation was interrupted by a signal. yes this again, it's a whole thing.
π« PerlIO_puts(f,s), PerlIO_putc(f,c)
These correspond to fputs() and fputc(). Note that the arguments have been revised so "file" comes first β¨
π« PerlIO_ungetc(f,c)
This corresponds to ungetc(). Note that the arguments have been revised so "file" comes first.
It arranges that the next read operation will return the byte c. And despite the implied "character" in the name, only values in the range 0..0xFF are defined. Returns the byte c on success, or -1 (EOF) on error.
the fine print: the number of bytes that can be "pushed back" may vary. Only 1 character is certain β and then only if it is the last character that was read from the handle. choose wisely bestie π€
π« PerlIO_unread(f,buf,count)
This lets you unget more than a single byte π. It effectively unshifts count bytes onto the beginning of the buffer buf, so that the next read operation(s) will return them before anything else that was in the buffer.
Returns the number of unread bytes.
π« PerlIO_getc(f)
This corresponds to getc(). Despite the c in the name, only byte range 0..0xFF is supported. Returns the character read, or -1 (EOF) on error.
π« PerlIO_eof(f)
This corresponds to feof(). Returns a true/false indication of whether the handle is at end of file.
For terminal devices this may or may not be "sticky" depending on the implementation π. The flag is cleared by PerlIO_seek(), or PerlIO_rewind().
π« PerlIO_error(f)
This corresponds to ferror(). Returns a true/false indication of whether there has been an IO error on the handle. it's giving "are you okay bestie" energy π
π« PerlIO_fileno(f)
This corresponds to fileno(). Note that on some platforms, the meaning of "fileno" may not match Unix. Returns -1 if the handle has no open descriptor associated with it.
π« PerlIO_clearerr(f)
This corresponds to clearerr() β i.e., it clears the 'error' and (usually) 'eof' flags for the "stream". Does not return a value. a queen who gives nothing back π
π« PerlIO_flush(f)
This corresponds to fflush(). It sends any buffered write data to the underlying file.
If called with NULL this may flush all open streams (or core dump with some USE_STDIO implementations π±π).
danger zone: calling on a handle open for read only, or on which the last operation was a read of some kind, may lead to undefined behaviour on some USE_STDIO implementations. this is not a drill.
The USE_PERLIO (layers) implementation tries to behave better π: it flushes all open streams when passed NULL, and attempts to retain data on read streams either in the buffer or by seeking the handle to the current logical position.
π« PerlIO_seek(f,offset,whence)
This corresponds to fseek(). It sends buffered write data to the underlying file, or discards any buffered read data, then positions the file descriptor as specified by "offset" and "whence" (sic).
This is the correct thing to do when switching between read and write on the same handle (see the issues with PerlIO_flush() above π).
Offset is of type Off_t, which is a perl Configure value and may not be the same as stdio's off_t. don't mix them up bestie, that's how you get haunted π¦
π« PerlIO_tell(f)
This corresponds to ftell(). Returns the current file position, or (Off_t) -1 on error.
It may just return the value the system "knows" without making a system call or checking the underlying file descriptor β so use on shared file descriptors is not safe without a PerlIO_seek() β οΈ.
Return value is of type Off_t, which is a perl Configure value which may not be same as stdio's off_t.
more parts coming, bestie β we are not done yet π«Άβ¨
PerlIO_getpos(f,p),PerlIO_setpos(f,p)β these two loosely correspond tofgetpos()andfsetpos(). The plot twist: instead of stdio'sFpos_t, they expect a "Perl Scalar Value" to get passed in. What actually gets stored in there? Consider it opaque, bestie β do not go snooping. The layout of that data can literally vary from handle to handle. And if you're not on stdio, or your platform simply doesn't have those stdio calls, they get implemented in terms ofPerlIO_tell()andPerlIO_seek()instead.PerlIO_rewind(f)β therewind()of the group. It's usually defined as exactly this:
PerlIO_seek(f,(Off_t)0L, SEEK_SET);
PerlIO_clearerr(f);
PerlIO_tmpfile()β corresponds totmpfile(), i.e. it returns an anonymous PerlIO orNULLon error. The system will attempt to automatically delete the file once it's closed. On Unix the file is usually"unlink"-ed right after it gets created, so honestly it does not matter how it gets closed. On other systems though, the file may only be deleted if it's closed viaPerlIO_close()and/or the program exits via"exit". Depending on the implementation there may be "race conditions" letting other processes access the file β though in general it will be safer in this regard than ad. hoc. schemes. πPerlIO_setlinebuf(f)β corresponds tosetlinebuf(). It does not return a value, she's giving nothing back. What constitutes a "line" is implementation dependent, but it usually means that writing"\n"flushes the buffer. What happens with things like"this\nthat"is uncertain. (Perl core uses it only when"dumping"; it has nothing to do with$|auto-flush.)
π Co-existence with stdio π
There's outline support for PerlIO and stdio vibing together in the same room. Obviously if PerlIO is implemented in terms of stdio there is no problem at all. But in other cases, mechanisms must exist to create a FILE * that can be passed to library code which is going to use stdio calls.
Step one, bestie, is adding this line:
#define PERLIO_NOT_STDIO 0
...before including any perl header files. (This will probably become the default at some point. π) That prevents perlio.h from attempting to #define stdio functions onto PerlIO functions.
XS code is probably better off using "typemap" if it expects FILE * arguments. The standard typemap will be adjusted to comprehend any changes in this area.
PerlIO_importFILE(f,mode)β used to get aPerlIO *out of aFILE *.
The mode argument should be a string, exactly like what you'd pass to fopen/PerlIO_open. If it's NULL then β for legacy support β the code will (depending upon the platform and the implementation) either try to empirically determine the mode in which "f" is open, or just use "r+" to indicate a read/write stream.
Once called, the FILE * should ONLY be closed by calling PerlIO_close() on the returned PerlIO *. Periodt.
The PerlIO is set to textmode. Use PerlIO_binmode if that's not the mode you wanted.
This is not the reverse of PerlIO_exportFILE().
PerlIO_exportFILE(f,mode)β given aPerlIO *, it creates a 'native'FILE *suitable for passing to code that expects to be compiled and linked with ANSI Cstdio.h. The mode argument should be a string as would be passed tofopen/PerlIO_open. If it'sNULLthen β for legacy support β theFILE *is opened in the same mode as thePerlIO *.
The fact that such a FILE * has been 'exported' gets recorded (normally by pushing a new :stdio "layer" onto the PerlIO *), which may affect future PerlIO operations on the original PerlIO *. You should not call fclose() on the file unless you call PerlIO_releaseFILE() to disassociate it from the PerlIO *. (And no, do not use PerlIO_importFILE() for doing the disassociation. π«)
Calling this function repeatedly will create a FILE * on each call (and will push an :stdio layer each time as well). She's generous like that.
PerlIO_releaseFILE(p,f)β callingPerlIO_releaseFILEinforms PerlIO that all use of theFILE *is complete. It gets removed from the list of 'exported'FILE *s, and the associatedPerlIO *should revert to its original behaviour.
Use this to disassociate a file from a PerlIO * that was associated using PerlIO_exportFILE().
PerlIO_findFILE(f)β returns a nativeFILE *used by a stdio layer. If there isn't one, it will create one withPerlIO_exportFILE. Either way, thatFILE *should be considered as belonging to the PerlIO subsystem and should only be closed by callingPerlIO_close().
β¨ "Fast gets" Functions β¨
On top of all the standard-like API defined up above, there's an "implementation" interface which lets perl get at the internals of PerlIO. The following calls correspond to the various FILE_xxx macros determined by Configure β or their equivalent in other implementations. This section is really only of interest to the people concerned with detailed perl-core behaviour, implementing a PerlIO mapping, or writing code which can make use of the "read ahead" that has been done by the IO system in the same way perl does. Heads up: any code that uses these interfaces must be prepared to do things the traditional way if a handle doesn't support them.
PerlIO_fast_gets(f)β returns true if the implementation has all the interfaces required to allow perl's"sv_gets"to"bypass"the normal IO mechanism. This can vary from handle to handle, iykyk.
PerlIO_fast_gets(f) = PerlIO_has_cntptr(f) && \
PerlIO_canset_cnt(f) && \
'Can set pointer into buffer'
PerlIO_has_cntptr(f)β the implementation can return a pointer to the current position in the"buffer"and a count of bytes available in the buffer. Do not use this β usePerlIO_fast_gets.PerlIO_get_cnt(f)β return the count of readable bytes in the buffer. A zero or negative return means no more bytes are available.PerlIO_get_ptr(f)β return a pointer to the next readable byte in the buffer. Accessing via that pointer (dereferencing) is only safe ifPerlIO_get_cnt()has returned a positive value. Only positive offsets up to the value returned byPerlIO_get_cnt()are allowed.PerlIO_set_ptrcnt(f,p,c)β set the pointer into the buffer, plus a count of bytes still in the buffer. Should be used only to set the pointer to within the range implied by previous calls to"PerlIO_get_ptr"and"PerlIO_get_cnt". The two values must be consistent with each other (the implementation may only use one or the other, or may require both).PerlIO_canset_cnt(f)β the implementation can adjust its idea of the number of bytes in the buffer. Do not use this β usePerlIO_fast_gets.PerlIO_set_cnt(f,c)β obscure, sets the count of bytes in the buffer. Deprecated. Only usable ifPerlIO_canset_cnt()returns true. Currently used in onlydoio.cto force a count less than-1to-1. Perhaps should bePerlIO_set_emptyor similar. This call may actually do nothing if"count"is deduced from a pointer and a"limit". Do not use this β usePerlIO_set_ptrcnt().PerlIO_has_base(f)β returns true if the implementation has a buffer, and can return a pointer to the whole buffer and its size. Used by perl for the-T/-Btests. Other uses would be very obscure... πPerlIO_get_base(f)β return the start of the buffer. Access only positive offsets in the buffer, up to the value returned byPerlIO_get_bufsiz().PerlIO_get_bufsiz(f)β return the total number of bytes in the buffer. This is neither the number that can be read, nor the amount of memory allocated to the buffer. Rather, it is what the operating system and/or implementation happened toread()(or whatever) the last time IO was requested.
π«Ά Other Functions π«Ά
PerlIO_apply_layers(aTHX_ f,mode,layers)β the new interface to the USE_PERLIO implementation. The layers":crlf"and":raw"are the only ones allowed for other implementations, and those are silently ignored. (As of perl5.8":raw"is deprecated.) UsePerlIO_binmode()below for the portable case.PerlIO_binmode(aTHX_ f,ptype,imode,layers)β the hook used by perl's"binmode"operator."ptype"is perl's character for the kind of IO:<read>write+read/write
"imode" is "O_BINARY" or "O_TEXT".
"layers" is a string of layers to apply; only ":crlf" makes sense in the non-USE_PERLIO case. (As of perl5.8 ":raw" is deprecated in favour of passing NULL.)
The portable cases are:
PerlIO_binmode(aTHX_ f,ptype,O_BINARY,NULL);
and
PerlIO_binmode(aTHX_ f,ptype,O_TEXT,":crlf");
On Unix these calls probably have no effect whatsoever. Elsewhere they alter "\n" to CR,LF translation and possibly cause a special text "end of file" indicator to be written or honoured on read. The effect of making the call after doing any IO to the handle depends on the implementation. (It may be ignored, it may affect any data which is already buffered as well, or it may only apply to subsequent data. π€·)
PerlIO_debug(fmt,...)βPerlIO_debugis aprintf()-like function that can be used for debugging. No return value. Its main use is inside PerlIO, where using realprintf,warn()etc. would recursively call PerlIO and be a problem.
PerlIO_debug writes to the file named by $ENV{'PERLIO_DEBUG'} or defaults to stderr if the environment variable isn't defined. Typical use might be:
Bourne shells (sh, ksh, bash, zsh, ash, ...):
PERLIO_DEBUG=/tmp/perliodebug.log ./perl -Di somescript some args
Csh/Tcsh:
setenv PERLIO_DEBUG /tmp/perliodebug.log
./perl -Di somescript some args
If you have the "env" utility:
env PERLIO_DEBUG=/tmp/perliodebug.log ./perl -Di somescript args
Win32:
set PERLIO_DEBUG=perliodebug.log
perl -Di somescript some args
On a Perl built without "-DDEBUGGING", or when the "-Di" command-line switch isn't specified, or under taint, PerlIO_debug() is a no-op. Cute, harmless, does nothing. π
and that's the whole page, bestie π this was PERLAPIO(1perl) β perl v5.44.0, dated 2026-10-17. go forth, inline your IO, and slay β¨π¦π
π¦ where this page comes from
- arch rolling: perl 5.44.0-1 Β· Artistic-1.0-Perl AND GPL-1.0-or-later
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms