Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!ucsd!ames!amdahl!nsc!pyramid!markhall From: markhall@pyrps5.pyramid.com (Mark Hall) Newsgroups: comp.std.c Subject: Re: stdarg: va_list pass by value? Message-ID: <136434@pyramid.pyramid.com> Date: 3 Dec 90 21:52:21 GMT Sender: daemon@pyramid.pyramid.com Reply-To: markhall@pyrps5.pyramid.com (Mark Hall) Organization: Pyramid Technology Corp., Mountain View, CA Lines: 33 In article <14628@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >In article <136196@pyramid.pyramid.com> markhall@pyrps5.pyramid.com (Mark Hall) writes: >>Since the standard explicitly calls out the indeterminacy >>of passing AP objects as arguments, shouldn't it also call out the >>indeterminacy of assigning AP objects? > >It doesn't have to; since va_list may be an array type, a strictly- >conforming program must not attempt to copy by in an assignment >expression. This leaves open the question whether or not one could >memcpy() it, but my advice is to not try such elaborate hackery. Aha! That same argument could be applied to the indeterminacy of passing the va_list as an argument. From what you say, the user should also have known that the va_list type could have been an array, and so the state of the va_list object on return from the function call would be indeterminate by direct implication. Therefore it is redundant for the standard to specifically call out the indeterminacy of passing a va_list object as an argument. So much for language-lawering the issue. My personal objection is that, in the big scheme of things, there isn't anything available to assist the poor programmer in writing a "maximally portable program". Had the standard called out a constraint on the operations allowable on a va_list object (my tiny little case in point), then I wouldn't (already!) be seeing so many non-conforming 3rd party programs which were not "caught" by the compiler on which they were developed. Man, customers look at you funny when you tell them their program isn't "conforming". They tend to suspect that XYZ's compiler is "better", even though your's did the harder job. You don't win marketing points by having the strictest compiler around. -Mark Hall (smart mailer): markhall@pyrps5.pyramid.com (uucp paths): {ames|decwrl|sun|seismo}!pyramid!markhall