🚀 go-pugleaf

In article <3598@lupine.NCD.COM>, rfg@lupine.ncd.com (Ron Guilmette) writes:
> If you use and/or sell System V Release 4 you may want to fix up your
> <sys/unistd.h> file.
> 
> It probably contains:
> 
> extern int execv(const char *, char *const *);
> extern int execve(const char *, char *const *, char *const *);
> extern int execvp(const char *, char *const *);
> 

These prototypes come right out of 1003.1-1990.  That
is why they are in SVR4.

> I'm fairly sure that these declarations should be changed to:
> 
> extern int execv(const char *, const char *const *);
> extern int execve(const char *, const char *const *, const char *const *);
> extern int execvp(const char *, const char *const *);
> 
> If your company sells V.4 ports to the general public (either on your
> company's own hardware or on somebody else's) I encourage you to fix
> this annoying little problem in the systems that your company distributes
> to its customers.
> 
> Please don't make us all suffer with this annoying glitch.

I personally wouldn't change unistd.h in this case.  It will
break your POSIX compliance.

	Seth Rosenthal


Disclaimer: All opinions are my own not my employers'.

(but in this case they may actually be the same)

In article <3598@lupine.NCD.COM> rfg@lupine.ncd.com (Ron Guilmette) writes:
>I'm fairly sure that these declarations should be changed to:
>extern int execv(const char *, const char *const *);
>extern int execve(const char *, const char *const *, const char *const *);
>extern int execvp(const char *, const char *const *);

Unfortunately there is no "right" way to do this.  Pointer-to-const has
special meaning in function parameter declarations, not quite in line
with the meaning in other forms of declaration.  In particular, type
compatibility checking will approve of passing a pointer to non-const
at the "first" level, but not at the second level of referencing.  Thus
the common usage
	char *args[] = { "prog", "arg1", NULL };
	execv( args[0], args );
would cause an "incompatible types for second argument" diagnostic,
were <unistd.h> (what is this "sys/" prefix?) to provide the additional
"const"s that you suggest.  You can legitimately consider this a
technical deficiency in the C standard if you wish; we simply couldn't
figure out an acceptable way to specify what one would really want for
this and therefore just fixed up the spec for the top level of
referencing.

In article <1991Jan31.174039.17973@cbnewsl.att.com> sethr@cbnewsl.att.com (seth.r.rosenthal) writes:
+In article <3598@lupine.NCD.COM>, rfg@lupine.ncd.com (Ron Guilmette) writes:
+> If you use and/or sell System V Release 4 you may want to fix up your
+> <sys/unistd.h> file.
+> 
+> It probably contains:
+> 
+> extern int execv(const char *, char *const *);
+> extern int execve(const char *, char *const *, char *const *);
+> extern int execvp(const char *, char *const *);
+> 
+
+These prototypes come right out of 1003.1-1990.  That
+is why they are in SVR4.

I stand corrected.  Apparently there *is* some POSIX document that says
that those prototypes are correct.

Now if somebody would just tell me where I can get a copy of this mythical
document...

Is it a draft or an approved document?  What's its ISBN #?

-- 

// Ron Guilmette  -  C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.