changeset 594:c0da1728ed5b

All refentries finished.
author roug
date Fri, 15 Nov 2002 21:49:51 +0000
parents 0fda6c7fe48e
children e50380625be6
files docs/ccguide/access.refentry docs/ccguide/chain.refentry docs/ccguide/chmod.refentry docs/ccguide/chown.refentry docs/ccguide/crc.refentry docs/ccguide/creat.refentry docs/ccguide/exit.refentry docs/ccguide/fclose.refentry docs/ccguide/feof.refentry
diffstat 9 files changed, 164 insertions(+), 10 deletions(-) [+]
line wrap: on
line diff
--- a/docs/ccguide/access.refentry	Thu Nov 14 03:55:12 2002 +0000
+++ b/docs/ccguide/access.refentry	Fri Nov 15 21:49:51 2002 +0000
@@ -8,7 +8,7 @@
 <funcsynopsis>
 <funcprototype>
   <funcdef><function>access</function></funcdef>
-  <paramdef>char *<parameter>name</parameter></paramdef>
+  <paramdef>char *<parameter>fname</parameter></paramdef>
   <paramdef>int <parameter>perm</parameter></paramdef>
 </funcprototype>
 </funcsynopsis>
@@ -17,7 +17,20 @@
 
 <refsect1><title>Description</title>
 <para>
-Placeholder
+Access returns 0 if the access modes specified in "perm" are
+correct for the user to access "fname". -1 is returned if the
+file cannot be accessed.
+</para>
+<para>
+The value for "perm" may be any legal OS-9 mode as used for
+"open()" or "creat()", it may be zero, which tests whether the
+file exists, or the path to it may be searched.
+</para>
+</refsect1>
+<refsect1><title>Caveats</title>
+<para>
+NOTE that the "perm" value is <emphasis>not</emphasis> compatible with other
+systems.
 </para>
 </refsect1>
 <refsect1><title>Diagnostics</title>
--- a/docs/ccguide/chain.refentry	Thu Nov 14 03:55:12 2002 +0000
+++ b/docs/ccguide/chain.refentry	Fri Nov 15 21:49:51 2002 +0000
@@ -27,7 +27,25 @@
 
 <refsect1><title>Description</title>
 <para>
-Placeholder
+The action of F$CHAIN is described fully in the OS-9
+documentation. Chain implements the service request as
+described with one important exception: chain will NEVER return
+to the caller. If there is an error, the process will abort
+and return to its parent process. It might be wise, therefore,
+for the programs to check the existence and access permissions
+of the module before calling chain. Permissions may be checked
+by using "modlink()" or "modload()" followed by an "munlink()".
+</para>
+<para>
+"Modname" should point to the name of the desired module.
+"Paramsize is the length of the parameter string (which should
+normally be terminated with a "\n"), and "paramptr" points to
+the parameter string. "Type" is the module type as found in
+the module header (normally 1: program), and "lang" should
+match the language nibble in the module header (C programs
+have 1 for 6809 machine code here). "Datasize" may be zero, or
+it may contain the number of 256 byte pages to give to the new
+process as initial allocation of data memory.
 </para>
 </refsect1>
 </refentry>
--- a/docs/ccguide/chmod.refentry	Thu Nov 14 03:55:12 2002 +0000
+++ b/docs/ccguide/chmod.refentry	Fri Nov 15 21:49:51 2002 +0000
@@ -20,9 +20,30 @@
 
 <refsect1><title>Description</title>
 <para>
-Placeholder
+Chmod changes the permission bits associated with a file.
+"Fname" must be a pointer to a file name, and "perm" should
+contain the desired bit pattern,
+</para>
+<para>
+The allowable bit patterns are defined in the include file as follows:
+</para>
+<programlisting>
+/* permissions */
+#define  S_IREAD   0x01     /* owner read */
+#define  S_IWRITE  0x02     /* owner write */
+#define  S_IEXEC   0x04     /* owner execute */
+#define  S_IOREAD  0x08     /* public read */
+#define  S_IOWRITE 0x10     /* public write */
+#define  S_IOEXEC  0x20     /* public execute */
+#define  S_ISHARE  0x40     /* sharable */
+#define  S_IFDIR   0x80     /* directory */
+</programlisting>
+<para>
+Only the owner or the super user may change the permissions of
+a file.
 </para>
 </refsect1>
+
 <refsect1><title>Diagnostics</title>
 <para>
 A successful call returns 0. A -1 is returned if the
@@ -31,4 +52,10 @@
 </para>
 </refsect1>
 
+<refsect1><title>See Also</title>
+<para>
+OS-9 command "attr"
+</para>
+</refsect1>
+
 </refentry>
--- a/docs/ccguide/chown.refentry	Thu Nov 14 03:55:12 2002 +0000
+++ b/docs/ccguide/chown.refentry	Fri Nov 15 21:49:51 2002 +0000
@@ -17,7 +17,8 @@
 
 <refsect1><title>Description</title>
 <para>
-Placeholder
+This call is available only to the super user. "Fname" is a
+pointer to a file name, and "ownerid" is the new user-id.
 </para>
 </refsect1>
 <refsect1><title>Diagnostics</title>
--- a/docs/ccguide/crc.refentry	Thu Nov 14 03:55:12 2002 +0000
+++ b/docs/ccguide/crc.refentry	Fri Nov 15 21:49:51 2002 +0000
@@ -24,7 +24,13 @@
 
 <refsect1><title>Description</title>
 <para>
-Placeholder
+This call accumulates a crc into a three byte array at "accum"
+for "count" bytes starting at "start". All three bytes of
+"accum" should be initialized to 0xff before the first call to
+"crc()". However, repeated calls can be subsequently made to
+cover an entire module. If the result is to be used as an OS-9
+module crc, it should have its bytes complemented before
+insertion at the end of the module.
 </para>
 </refsect1>
 </refentry>
--- a/docs/ccguide/creat.refentry	Thu Nov 14 03:55:12 2002 +0000
+++ b/docs/ccguide/creat.refentry	Fri Nov 15 21:49:51 2002 +0000
@@ -26,7 +26,37 @@
 
 <refsect1><title>Description</title>
 <para>
-Placeholder
+Creat returns a path number to a new file available for
+writing, giving it the permissions specified in "perm" and
+making the task user the owner. If, however, "fname" is the
+name of an existing file, the file is truncated to zero length,
+and the ownership and permissions remain unchanged. NOTE,
+that unlike the OS-9 assembler service request, creat does
+not return an error if the file already exists. "Access()"
+should be used to establish the existence of a file if it is
+important that a file should not be overwritten.
+</para>
+<para>
+It is unnecessary to specify writing permissions in "perm" in
+order to write to the file in the current task.
+</para>
+<para>
+The permissions allowed are defined in the include file as
+follows:
+</para>
+<programlisting>
+#define  S_IPRM    0xff     /* mask for permission bits */
+#define  S_IREAD   0x01     /* owner read */
+#define  S_IWRITE  0x02     /* owner write */
+#define  S_IEXEC   0x04     /* owner execute */
+#define  S_IOREAD  0x08     /* public read */
+#define  S_IOWRITE 0x10     /* public write */
+#define  S_IOEXEC  0x20     /* public execute */
+#define  S_ISHARE  0x40     /* sharable */
+</programlisting>
+<para>
+Directories may not be created with this call; use "mknod()"
+instead.
 </para>
 </refsect1>
 
--- a/docs/ccguide/exit.refentry	Thu Nov 14 03:55:12 2002 +0000
+++ b/docs/ccguide/exit.refentry	Fri Nov 15 21:49:51 2002 +0000
@@ -28,7 +28,18 @@
 
 <refsect1><title>Description</title>
 <para>
-Placeholder
+Exit is the normal means of terminating a task. Exit does any
+cleaning up operations required before terminating, such as
+flushing out any file buffers (see Standard i/o), but _exit
+does not.
+</para>
+<para>
+A task finishing normally, that is returning from "main()",
+is equivalent to a call - "exit(0)".
+</para>
+<para>
+The status passed to exit is available to the parent task if it
+is executing a "wait".
 </para>
 </refsect1>
 
--- a/docs/ccguide/fclose.refentry	Thu Nov 14 03:55:12 2002 +0000
+++ b/docs/ccguide/fclose.refentry	Fri Nov 15 21:49:51 2002 +0000
@@ -27,9 +27,36 @@
 
 <refsect1><title>Description</title>
 <para>
-Placeholder
+Fflush causes a buffer associated with the file pointer "fp"
+to be cleared by writing out to the file; of course, only if
+the file was opened for write or update. It is not normally
+ncesasary to call fflush, but it can be useful when, for
+example, normal output is to "stdout", and it is wished to
+send something to "stderr" which is unbuffered. If fflush
+were not used and "stdout" referred to the terminal, the
+"stderr" message will appear before large chunks of the
+"stdout" message even though the latter was written first.
+</para>
+<para>
+Fclose call fflush to clear out the buffer associated with
+"fp", closes the file, and frees the buffer for use by another
+fopen call.
+</para>
+<para>
+The exit() system call and normal termination of a program
+causes fclose to be called for each open file.
 </para>
 </refsect1>
+
+<refsect1><title>See Also</title>
+<para>
+System call
+<link linkend="close">close()</link>,
+<link linkend="fopen">fopen()</link>,
+<link linkend="setbuf">setbuf()</link>.
+</para>
+</refsect1>
+
 <refsect1><title>Diagnostics</title>
 <para>
 EOF is returned if "fp" does not refer to an output file or
--- a/docs/ccguide/feof.refentry	Thu Nov 14 03:55:12 2002 +0000
+++ b/docs/ccguide/feof.refentry	Fri Nov 15 21:49:51 2002 +0000
@@ -37,7 +37,28 @@
 
 <refsect1><title>Description</title>
 <para>
-Placeholder
+Feof returns non-zero if the file associated with "fp" has
+reached its end. Zero is returned on error.
+</para>
+<para>
+Ferror returns non-zero if an error condition occurs on access
+to the file "fp"; zero is returned otherwise. The error
+condition persists, preventing further access to the file by
+other Standard Library functions, until the file is closed,
+or it is cleared by clearerr.
+</para>
+<para>
+Clearerr resets the error condition on the file "fp". This
+does NOT "fix" the file or prevent the error from occurring
+again; it merely allows Standard Library functions at least to
+try.
+</para>
+</refsect1>
+
+<refsect1><title>Caveats</title>
+<para>
+These functions are actually macros that are defined in
+"&lt;stdio.h&gt;" so their names cannot be redeclared.
 </para>
 </refsect1>