rfg@lupine.uucp (Ron Guilmette) (01/30/91)
Submitted-by: rfg@lupine.uucp (Ron Guilmette) It is somewhat dated now, but the only book I have about POSIX is copyright 1988. Reading that book, it seems that the POSIX committee didn't want to use ANSI C function prototypes for their specification of the C language binding because prototypes were too "new-fangled". Specifically, they apparently choose not to express the binding in terms of prototypes because: "... the Working Group was aware that some vendors would wish to implement POSIX in terms of a binding to an historical variant of the C language..." So in effect, it seems that the bindings given in the book I'm looking at are for "traditional C" (rather than ANSI C). In addition to avoiding prototypes, the POSIX folks also (apparently) decided to avoid the use of ANSI C type qualifiers (i.e. "const" and "volatile") in the C binding. Now even thought I don't really keep up on such things, I assume that some progress has been made since 1988. Is there now also an ANSI C binding for POSIX? If so, please tell me the exact name of *that* document so that I can go buy a copy. The thing that I most want to know at the moment is the "correct" (or "standard") prototype for the `execvp' function. The POSIX book I have here doesn't use any ANSI C type qualifiers at all, and so I have no idea what (if any) type qualifiers should be used to declare the types of the formal parameters for execvp. For example, my intuition tells me that a "proper" prototype for `execvp' should look like: extern int execvp (const char *, const char *const *); But somebody else disagrees with me. It seems that this sort of thing could be an important "standards" issue because many variants of UN*X operating systems are now shipping with fully prototyped system include files. Are they "POSIX-conformant" with respect to the qualifiers used to declare the types of their formals? How would one be able know one way or the other? Please excuse me if this has all been resolved long ago (and if my nearly total ignorance is showing). Volume-Number: Volume 22, Number 87
gwyn@smoke.brl.mil (Doug Gwyn) (02/01/91)
Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn) In article <17501@cs.utexas.edu> rfg@lupine.uucp (Ron Guilmette) writes: >Are they "POSIX-conformant" with respect to the qualifiers used to >declare the types of their formals? Since "POSIX" did not specify the qualifiers, a conforming implementation need not provide them in any prototypes in the standard/POSIX headers. If the implementor wants to be "helpful", he could through judicious use of "const*" improve the compile-time error checking, but that is not required. In a related note in another newsgroup I observe that "const*const*" is not only not helpful, it is actually harmful and should not be used in place of "**" in such prototypes. Basically P1003 didn't have enough qualified people-time to revise the 1003.1 draft to convert it to give genuine prototypes. However, I would recommends that all future C bindings do so; it's much cleaner than the hybrid "UNIX man page SYNOPSIS" format that has been traditionally used. Volume-Number: Volume 22, Number 94
willcox@urbana.mcd.mot.com (David A Willcox) (02/01/91)
Submitted-by: willcox@urbana.mcd.mot.com (David A Willcox) rfg@lupine.uucp (Ron Guilmette) writes: >It is somewhat dated now, but the only book I have about POSIX is >copyright 1988. The new version of POSIX.1, IEEE Std 1003.1-1990, came out last December. You can get it from the IEEE; their number is 1-800-678-IEEE, and I think that the order number is SH13680. It uses ANSI C prototypes. execvp(), for example, is: int execvp(const char *file, char *const argv[]); It also has quite a number of other "bug fixes". >Reading that book, it seems that the POSIX committee didn't want to >use ANSI C function prototypes for their specification of the C language >binding because prototypes were too "new-fangled". Specifically, they >apparently choose not to express the binding in terms of prototypes because: ANSI C "wasn't" when the 1988 version of POSIX was written. There were drafts of the C standard around, but it wasn't approved, and there was no guarantee that it wouldn't change. That was the main reason for staying with the traditional syntax. Volume-Number: Volume 22, Number 97
donn@hpfcrn.fc.hp.com (Donn Terry) (02/02/91)
Submitted-by: donn@hpfcrn.fc.hp.com (Donn Terry) >Submitted-by: rfg@lupine.uucp (Ron Guilmette) >Reading that book, it seems that the POSIX committee didn't want to >use ANSI C function prototypes for their specification of the C language >binding because prototypes were too "new-fangled". Specifically, they >apparently choose not to express the binding in terms of prototypes because: > "... the Working Group was aware that some vendors would wish > to implement POSIX in terms of a binding to an historical > variant of the C language..." That was appropriate at the time. The -1990 version uses ANSI C prototypes (now that ANSI C is approved, and implementations are available). >In addition to avoiding prototypes, the POSIX folks also (apparently) >decided to avoid the use of ANSI C type qualifiers (i.e. "const" and >"volatile") in the C binding. Avoided for the same reasons. >Now even thought I don't really keep up on such things, I assume that >some progress has been made since 1988. Is there now also an ANSI C >binding for POSIX? If so, please tell me the exact name of *that* >document so that I can go buy a copy. Specifically IEEE Std. 1003.1-1990 a.k.a. ISO/IEC JTC-1 IS 9945-1:1990 (Available from IEEE at the same place you got your -1988 version.) >For example, my intuition tells me that a "proper" prototype for `execvp' >should look like: > extern int execvp (const char *, const char *const *); The new standard has the declaration as: int execvp (const char *file, char *const argv[]); It was generally agreed during balloting that what really was wanted was "const char * const argv[]". However, ANSI C disagrees: that's a syntax error! (There's a bunch of rationale about why the specific declaration was chosen, I won't repeat it here, but the bottom line is that given that you can't have both const's, this is the best choice remaining.) Donn Terry Speaking only for myself. Volume-Number: Volume 22, Number 98
henry@zoo.toronto.edu (Henry Spencer) (02/05/91)
Submitted-by: henry@zoo.toronto.edu (Henry Spencer) In article <17574@cs.utexas.edu> donn@hpfcrn.fc.hp.com (Donn Terry) writes: > int execvp (const char *file, char *const argv[]); > >It was generally agreed during balloting that what really was wanted >was "const char * const argv[]". However, ANSI C disagrees: that's >a syntax error! This puzzled me a bit, since that is *not* a syntax error, but a bit of private correspondence with Donn cleared it up. The problem is not that the declaration is illegal, but that `char *[]' and `const char *const []' are not assignment-compatible -- the "inner" const does not magically get ignored like the "outer" one -- so this would break backward compatibility. -- "Maybe we should tell the truth?" | Henry Spencer at U of Toronto Zoology "Surely we aren't that desperate yet." | henry@zoo.toronto.edu utzoo!henry Volume-Number: Volume 22, Number 106