Is there a standard prototype for `execvp'?
Donn Terry
donn at hpfcrn.fc.hp.com
Sat Feb 2 04:45:53 AEST 1991
Submitted-by: donn at hpfcrn.fc.hp.com (Donn Terry)
>Submitted-by: rfg at 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
More information about the Comp.std.unix
mailing list