rfg@lupine.ncd.com (Ron Guilmette) (01/31/91)
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 *); 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.
sethr@cbnewsl.att.com (seth.r.rosenthal) (02/01/91)
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)
gwyn@smoke.brl.mil (Doug Gwyn) (02/01/91)
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.
rfg@NCD.COM (Ron Guilmette) (02/03/91)
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.