From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ce0900b60ca3f616 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-11-22 00:06:29 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!newsfeed.direct.ca!look.ca!wn1feed!worldnet.att.net!135.173.83.71!wnfilter1!worldnet-localpost!bgtnsc06-news.ops.worldnet.att.net.POSTED!not-for-mail From: "David Thompson" Newsgroups: comp.lang.ada References: <20011105134531.P817-100000@shell5.ba.best.com> Subject: Re: Side-Effects in Functions [Rosen Trick] X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: Date: Thu, 22 Nov 2001 06:22:46 GMT NNTP-Posting-Host: 12.89.147.15 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc06-news.ops.worldnet.att.net 1006410166 12.89.147.15 (Thu, 22 Nov 2001 06:22:46 GMT) NNTP-Posting-Date: Thu, 22 Nov 2001 06:22:46 GMT Organization: AT&T Worldnet Xref: archiver1.google.com comp.lang.ada:16825 Date: 2001-11-22T06:22:46+00:00 List-Id: Brian Rogoff wrote : > On Tue, 6 Nov 2001, Alexandre E. Kopilovitch wrote: ... > .... However, it is more likely that monkeys will suddenly fly out my > butt than it is that we'll have an incompatible new version of Ada. > I realize we're talking about negligible probabilities here, but just to be on the safe side, remind me not to stand behind you :-} > > We may easily follow the C view, on this subject, and have the > > functions only, permitting 'null' for the return type. > > It's called void, not null. The problem with C is that it ignores returned > value types so even though it has void it doesn't really use it. I imagine > a reworked Ada would only allow void returning function/procedure values > to be ignores, and so wouldn't lose type safety. > I'm not sure what you were trying to say there. C certainly does use the declared return type of a function. If you try to assign the result of a function call to a variable (or pass it to a prototyped parameter) of a type to which it cannot be converted, it's a diagnosed error, just as for any other expression yielding that type; also if you try to assign or pass the "value" of a void function at all. Also, if you write a return statement with a value of a type that cannot be converted to the function's return type, or any (real) value in a void function, it's diagnosed; or in C99 (but not originally) to have a return without value in a function with a non-void return type. What you may be after is that the value of any non-void expression in C, whether it is the return from a function or not, is discarded if that expression constitutes an entire statment. Thus sin(3.1415926); 2+3; are both legal though useless statements: the former would be useful if the function called were one with (desired) side effects, the latter could never be. This treatment is necessary partly because in C the assignment operators (simple = and also the "compound" assignments like *= ++ etc.) _have a value_ namely the value assigned, so you can write e.g. a = b = x; which is the same as { b = x; a = b; } except for volatile variables or non-idempotent lvalues, and without this discarding you would have to always write (void)(a=3); and so on which is obviously Stupid(tm). In addition you can explicitly ignore any value by casting to void, but because of the above it is never really needed. Except some compilers and most(?) lints give a _warning_ about implicitly discarding the value of a non-assignment, so if you use those tools you do need to cast to void to avoid (ha, ha) the warning. Similarly you can often get a warning for writing if(a=3) (which always yields a nonzero, and hence true in C, value) when you meant if(a==3), but the former is not an error and cannot be rejected. I agree Ada, which treats assignment as a statement not an expression, could and should be more "type"safe here. FWLIW if unifying valued and nonvalued subprograms were going to be done, I would prefer the PL/1 approach: include the RETURNS clause with a real type, or omit it for a nonvalued procedure, rather than making void a type. It is also true that C implementations are not required to, and normally don't, check that the declared (return and argument if any) types in a referencing "unit" (source file) agree with those in a definition=body in a different one, unless you (redundantly) repeat the declaration, which is often done by the .c #include'ing the .h for precisely this reason. (Even then to ensure parameter types are checked you must use the "new" in C++ and C89 -- and more Pascal/Ada-like -- "prototype" syntax rather than the original K&R1 syntax.) But that is true for all types, not just void. -- - David.Thompson 1 now at worldnet.att.net