rburgess@milton.u.washington.edu (Rick Burgess) (04/12/91)
Anybody know: 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? The reason I ask is I cannot find them in my copy of the 2nd edition to the K&R C book. 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. Also: 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? Also: Should there be recommendations against using access(), is there some kind of standard convolution with fopen() or something that is recognized as a good and clear and/or "the way" to do what access would do?
torek@elf.ee.lbl.gov (Chris Torek) (04/12/91)
In article <1991Apr11.234342.6190@milton.u.washington.edu> rburgess@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@ee.lbl.gov
gwyn@smoke.brl.mil (Doug Gwyn) (04/13/91)
In article <1991Apr11.234342.6190@milton.u.washington.edu> rburgess@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, of course not. The only errno values in the C standard are EDOM and ERANGE. >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. The whole idea of protection modes, file owner, etc. is highly operating system specific. access() originated in UNIX, where it seldom does the thing that the application is trying to use it for (just a design botch for the access() semantics, in my opinion). >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? Yes, you should have a copy of the actual standard for reference purposes. There is also a little book out by Brodie and Plauger (if I recall correctly) entitled something like "Standard C", that is pretty good for detailed tutorial purposes. >Should there be recommendations against using access(), is there some kind of >standard convolution with fopen() or something that is recognized as a good >and clear and/or "the way" to do what access would do? Usually you can just try the particular form of access you intend, and take measures based on whether or not it reports an error.
cschmidt@lynx.northeastern.edu (04/17/91)
> 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? For advice on the new ANSI C, I like the book "Standard C" by Plauger and Brodie, copyright 1989. The authors were members of the committee that developed the new ANSI standard for the C programming language, and their book is meant to present the work of that committee. Plauger was the Secretary and Brodie the "Chair" of that committee. This book is one of the Microsoft Press "Programmer's Quick Reference Series". The list price is about 8 dollars (USA). I know of no other reference book of equal authority on the new standard. The book is concise, well-written, and reasonably priced. I am interested in knowing what you think about this book, in particular whether you agree that is the best reference for writing portable programs using the new standard. > 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. Really? Consider a common example: The book "Standard C" includes a list of standard header files. If you want to know whether one of the header files provided with your compiler can be counted on when you port your program to another ANSI C compiler, this book provides an answer. Metaphysics aside, is it true or not that the answer is reliable? If we cannot get reliable answers to simple questions like this, then the ANSI C committee has failed. Christopher Schmidt cschmidt@lynx.northeastern.edu
gregory@ritcsh.csh.rit.edu (Greg Conway) (04/18/91)
In article <memo.928061@lynx.northeastern.edu> cschmidt@lynx.northeastern.edu writes: >I know of no other reference book of equal authority on the new standard. I do. The standard itself.
torek@elf.ee.lbl.gov (Chris Torek) (04/19/91)
>>>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? In an article whose referent was deleted (not by me), I wrote: >>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. In article <memo.928061@lynx.northeastern.edu> cschmidt@lynx.northeastern.edu writes: >[Plauger and Brodie recommendation] >Consider a common example: The book "Standard C" includes a >list of standard header files. If you want to know whether one of the >header files provided with your compiler can be counted on when you >port your program to another ANSI C compiler, this book provides an >answer. Surely, and it is almost certainly correct as well. I am not saying that the books that `boil down' the standard are not useful, nor even that they are not `all you need if you want to write ANSI C'. But look at the original question again: `What should I read so that I know the ANSI standard?' The ONLY thing you can read that contains the ANSI C standard *is* the ANSI standard, X3.159-1989. If you want the Ultimate Answer to `what does printf("%d %d\n", (v++, 0), (v++, 1)); do?' (see comp.std.c), you have to look at the standard---any reasonable book will just say `avoid this' (which is right). The standard will tell you, in very many words, whether you have violated a constraint, invoked implementation-defined or undefined behavior, and so on. Perhaps I am simply being overly literal with the original question, but it seems *very* clear to me that the desire was `to know the ANSI standard' rather than `to be able to use ANSI C portably, efficiently, etc.'. -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov