More BIO docs.

doc/crypto/BIO_ctrl.pod

@@ -0,0 +1,93 @@
+=pod
+
+=head1 NAME
+
+	BIO_ctrl, BIO_callback_ctrl, BIO_ptr_ctrl, BIO_int_ctrl - BIO control operations
+
+=head1 SYNOPSIS
+
+ #include <openssl/bio.h>
+
+ long BIO_ctrl(BIO *bp,int cmd,long larg,void *parg);
+ long BIO_callback_ctrl(BIO *b, int cmd, void (*fp)(struct bio_st *, int, const char *, int, long, long));
+ char *	BIO_ptr_ctrl(BIO *bp,int cmd,long larg);
+ long BIO_int_ctrl(BIO *bp,int cmd,long larg,int iarg);
+
+ int BIO_reset(BIO *b);
+ int BIO_flush(BIO *b);
+ int BIO_eof(BIO *b);
+ int BIO_set_close(BIO *b,long flag);
+ int BIO_get_close(BIO *b);
+ int BIO_pending(BIO *b);
+ int BIO_wpending(BIO *b);
+ size_t BIO_ctrl_pending(BIO *b);
+ size_t BIO_ctrl_wpending(BIO *b);
+
+ int BIO_get_info_callback(BIO *b,bio_info_cb **cbp);
+ int BIO_set_info_callback(BIO *b,bio_info_cb *cb);
+
+ typedef void bio_info_cb(BIO *b, int oper, const char *ptr, int arg1, long arg2, long arg3);
+
+=head1 DESCRIPTION
+
+BIO_ctrl(), BIO_callback_ctrl(), BIO_ptr_ctrl() and BIO_int_ctrl()
+are BIO "control" operations taking arguments of various types.
+These functions are not normally called directly, various macros
+are used instead. The standard macros are described below, macros
+specific to a particular type of BIO are described in the specific
+BIOs manual page as well as any special features of the standard
+calls.
+
+BIO_reset() typically reset a BIO to some initial state, in the case
+of file related BIOs for example it rewinds the file pointer.
+
+BIO_flush() normally writes out any internally buffered data, in some
+cases it is used to signal EOF and that no more data will be written.
+
+BIO_eof() returns 1 if the BIO has read EOF, the precise meaning of
+"EOF" varies according to the BIO type.
+
+BIO_set_close() sets the BIO B<b> close flag to B<flag>. B<flag> can
+take the value BIO_CLOSE or BIO_NOCLOSE. Typically BIO_CLOSE is used
+in a source/sink BIO to indicate that the underlying I/O stream should
+be closed when the BIO is freed.
+
+BIO_get_close() returns the BIOs close flag.
+
+BIO_pending(), BIO_ctrl_pending(), BIO_wpending() and BIO_ctrl_wpending()
+return the number of pending characterers in the BIOs read and write buffers.
+Not all BIOs support these calls. BIO_ctrl_pending() and BIO_ctrl_wpending()
+return a size_t type and are functions, BIO_pending() and BIO_wpending() are
+macros which call BIO_ctrl().
+
+=head1 RETURN VALUES
+
+BIO_reset() returns 1 fo success and 0 for failure.
+
+BIO_flush() returns 1 for success and 0 or -1 for failure.
+
+BIO_eof() returns 1 if EOF has been reached 0 otherwise.
+
+BIO_set_close() always returns 1.
+
+BIO_get_close() returns the close flag value: BIO_CLOSE or BIO_NOCLOSE.
+
+BIO_pending(), BIO_ctrl_pending(), BIO_wpending() and BIO_ctrl_wpending()
+return the amount of pending data.
+
+=head1 NOTES
+
+BIO_flush(), because it can write data may return 0 or -1 indicating
+that the call should be retried later in a similar manner to BIO_write(). 
+The BIO_should_retry() call should be used and appropriate action taken
+is the call fails.
+
+The return values of BIO_pending() and BIO_wpending() may not reliably
+determine the amount of pending data in all cases. For example in the
+case of a file BIO some data may be available in the FILE structures
+internal buffers but it is not possible to determine this in a
+portably way. For other types of BIO they may not be supported.
+
+=head1 SEE ALSO
+
+TBA

doc/crypto/BIO_read.pod

@@ -32,11 +32,12 @@ BIO_puts() attempts to write a null terminated string B<buf> to BIO B<b>
 
 All these functions return either the amount of data successfully read or
 written (if the return value is positive) or that no data was successfully
-read or written (if the result is zero or negative).
+read or written if the result is 0 or -1. If the return value is -2 then
+the operation is not implemented in the specific BIO type.
 
 =head1 NOTES
 
-A negative or zero return is not necessarily an indication of an error. In
+A 0 or -1 return is not necessarily an indication of an error. In
 particular when the source/sink is non-blocking or of a certain type (for
 example an SSL BIO can retry even if the underlying connection is blocking)
 it may merely be an indication that no data is currently available and that

doc/crypto/BIO_set_callback.pod

@@ -0,0 +1,107 @@
+=pod
+
+=head1 NAME
+
+	BIO_set_callback, BIO_get_callback - BIO callback
+
+=head1 SYNOPSIS
+
+ #include <openssl/bio.h>
+
+ #define BIO_set_callback(b,cb)		((b)->callback=(cb))
+ #define BIO_get_callback(b)		((b)->callback)
+ #define BIO_set_callback_arg(b,arg)	((b)->cb_arg=(char *)(arg))
+ #define BIO_get_callback_arg(b)		((b)->cb_arg)
+
+ long BIO_debug_callback(BIO *bio,int cmd,const char *argp,int argi,
+	long argl,long ret);
+
+ typedef long callback(BIO *b, int oper, const char *argp,
+			int argi, long argl, long retvalue);
+
+=head1 DESCRIPTION
+
+BIO_set_callback() and BIO_get_callback() set and retrieve the BIO callback,
+they are both macros. The callback is called during most high level BIO
+operations. It can be used for debugging purposes to trace operations on
+a BIO or to modify its operation.
+
+BIO_set_callback_arg() and BIO_get_callback_arg() are macros which can be
+used to set and retrieve an argument for use in the callback.
+
+BIO_debug_callback() is a standard debugging callback which prints
+out information relating to each BIO operation. If the callback
+argument is set if is interpreted as a BIO to send the information
+to, otherwise stderr is used.
+
+callback() is the callback function itself. The meaning of each
+argument is described below.
+
+The BIO the callback is attached to is passed in B<b>.
+
+B<oper> is set to the operation being performed. For some operations
+the callback is called twice, once before and once after the actual
+operation, the latter case has B<oper> or'ed with BIO_CB_RETURN.
+
+The meaning of the arguments B<argp>, B<argi> and B<argl> depends on
+the value of B<oper>, that is the operation being performed.
+
+B<retvalue> is the return value that would be returned to the
+application if no callback were present. The actual value returned
+is the return value of the callback itself. In the case of callbacks
+called before the actual BIO operation 1 is placed in retvalue, if
+the return value is not positive it will be immediately returned to
+the application and the BIO operation will not be performed.
+
+The callback should normally simply return B<retvalue> when it has
+finished processing, unless if specifically wishes to modify the
+value returned to the application.
+
+=head1 CALLBACK OPERATIONS
+
+=over 4
+
+=item B<BIO_free(b)>
+
+callback(b, BIO_CB_FREE, NULL, 0L, 0L, 1L) is called before the
+free operation.
+
+=item B<BIO_read(b, out, outl)>
+
+callback(b, BIO_CB_READ, out, outl, 0L, 1L) is called before
+the read and callback(b, BIO_CB_READ|BIO_CB_RETURN, out, outl, 0L, retvalue)
+after.
+
+=item B<BIO_write(b, in, inl)>
+
+callback(b, BIO_CB_WRITE, in, inl, 0L, 1L) is called before
+the write and callback(b, BIO_CB_WRITE|BIO_CB_RETURN, in, inl, 0L, retvalue)
+after.
+
+=item B<BIO_gets(b, out, outl)>
+
+callback(b, BIO_CB_GETS, out, outl, 0L, 1L) is called before
+the operation and callback(b, BIO_CB_GETS|BIO_CB_RETURN, out, outl, 0L, retvalue)
+after.
+
+=item B<BIO_puts(b, in)>
+
+callback(b, BIO_CB_WRITE, in, 0, 0L, 1L) is called before
+the operation and callback(b, BIO_CB_WRITE|BIO_CB_RETURN, in, 0, 0L, retvalue)
+after.
+
+=item B<BIO_ctrl(BIO *b, int cmd, long larg, void *parg)>
+
+callback(b,BIO_CB_CTRL,parg,cmd,larg,1L) is called before the call and
+callback(b,BIO_CB_CTRL|BIO_CB_RETURN,parg,cmd, larg,ret) after.
+
+=back
+
+=head1 EXAMPLE
+
+The BIO_debug_callback() function is a good example, its source is
+in crypto/bio/bio_cb.c
+
+=head1 SEE ALSO
+
+TBA

doc/crypto/BIO_should_retry.pod

@@ -91,10 +91,10 @@ done:
  } while((len <= 0) && BIO_should_retry(bio));
 
 While an application may retry a failed non blocking call immediately
-this is likely to be very inefficient because the call is likely to
+this is likely to be very inefficient because the call will fail
-fail repeatedly until data can be processed. An application will normally
+repeatedly until data can be processed or is available. An application
-wait until the necessary condition is satisfied. How this is done depends
+will normally wait until the necessary condition is satisfied. How
-on the underlying I/O structure.
+this is done depends on the underlying I/O structure.
 
 For example if the cause is ultimately a socket and BIO_should_read()
 is true then a call to select() may be made to wait until data is
@@ -114,7 +114,7 @@ able to pass any data to the application until a complete block has
 been read.
 
 It is possible for a BIO to block indefinitely if the underlying I/O
-structure cannot process the data. This depends on the behaviour of
+structure cannot process or return any data. This depends on the behaviour of
 the platforms I/O functions. This is often not desirable: one solution
 is to use non blocking I/O and use a timeout on the select() (or
 equivalent) call.