ANSI C /K&R 2nd edition questions,...

[Chris Torek]

In article <1991Apr11.234342.6190 at milton.u.washington.edu>
rburgess at milton.u.washington.edu (Rick Burgess) writes:
>are the "Symbolic constants" (VAX/VMSpeak) EPERM, ENOENT, ESRCH,... which are
>defined in errno.h in VMS, and apparently also under the standard dynix 
>compiler on a machine we have here, are these ANSI standard?

No.  They do, however, appear in various POSIX standards.

>Neither can I find "access(char *file_spec, int mode);", which is supposed to
>be a more elegant way to check the existance and protection on files.

Do not use access().  At best, access() will tell you whether you could
have done something some time ago.  On any multiprocessing system, this
creates instant race conditions.  If you want to see if some operation
will work, do the operation and see if it worked.  (Indeed, on Unix
systems access() was intended to tell whether the `real user' had
permission to do something.  It fails badly since the whole purpose of
this is to provide security, yet one can foil this security by winning
the race.  Older Unix systems have no clean way to avoid this; newer
ones let you change user and group IDs temporarily so that you can do
some work as the real user, and some as the effective user.  This is a
topic for a Unix-specific newsgroup.)

>If there should be a general or common opinion that the 2nd edition of K&R is
>not adequate for knowing the ANSI standard, can anyone recommend something
>readable/usable?

The only thing that is `as good' as the ANSI standard when you need to
know if something is standard is the standard itself (as K&R themselves
observe in K&R-2) (and how many times can I use the word `standard' in
one sentence? :-) ).  There are plenty of books that purport to `boil
down' the standard into nice, easy, bite-sized bits, but none of them
will give you the Ultimate Answer to any question.  (Sometimes even
the standard will not answer a question, and you may have to ask for
rulings about fine points.  Watch comp.std.c for a month, for instance.)
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek at ee.lbl.gov