home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.20 / text0140.txt < prev    next >
Encoding:
Internet Message Format  |  1990-08-02  |  1.6 KB
  1. From:  rfg@lupine.uucp (Ron Guilmette)
  2.  
  3.  
  4. Just a trivia question.
  5.  
  6. On very rare occasions, I have found the family of vprintf functions (i.e.
  7. vprintf, vfprintf, and vsprintf) quite useful.  In certain cases, there
  8. is simply no other way to accomplish quite the same thing (especially
  9. on the newer RISC machines where methods of passing variable numbers of
  10. parameters can get rather complicated).
  11.  
  12. Now I'm looking at a hunk of non-portable code (written by somebody else
  13. of course :-) that I have to port. and this code involves a call to execvp.
  14. It looks kinda like:
  15.  
  16. ------------------------------------------------------------------------------
  17. different_execvp (a, args)
  18. char    *a;
  19. va_list args;
  20. {
  21.     char **argv;
  22.  
  23.     argv = (char **) args;        /* YIKES!!! */
  24.     argv[0] = basename(argv[0]);
  25.     execvp(a, argv);
  26. }
  27. ------------------------------------------------------------------------------
  28.  
  29. The line with the comment /* YIKES!!! */ gets errors during compilation due
  30. to a severe type mishmash for the assignment.  That's due to the fact that
  31. (on the machine I am compiling on, the type used for `va_list' is most
  32. definitely *not* a type which can be legally typecast to a pointer.  (Hint:
  33. it is a struct on this type of RISC machine.)
  34.  
  35. What I appear to need here is either:
  36.  
  37.     a)  a standard way to convert a va_list into a list of pointers
  38.         (to argument values), or
  39.  
  40.     b)  a standard way to modify one element of a va_list *and* a
  41.         standard function like:
  42.  
  43.         int vexeclp (char *name, va_list vargs);
  44.  
  45. None of these things are a part of standard ANSI C (as far as I know).
  46. Are any of them a part of POSIX?  If not, why not?
  47.  
  48.  
  49.  
  50. Volume-Number: Volume 20, Number 138
  51.  
  52.