Mercurial > hg > Members > kono > nitros9-code
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 +"<stdio.h>" so their names cannot be redeclared. </para> </refsect1>