Path: csiph.com!news.swapon.de!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: C++ forcing unnecessary changes to C? Date: Fri, 18 Nov 2016 09:32:12 -0800 Organization: None to speak of Lines: 49 Message-ID: References: <1ee74e1e-cba5-45c8-bcd0-953074d96769@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="04a1531e1c4deccd6dbe268f8206796d"; logging-data="839"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19rUxCm+iFc/0gl4Yz8XUcD" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:H2p1ynKYS3XHGuTAgW4L2ogXqFE= sha1:DOt+Ts0IRuEw8fvc0B7yJmcwZKY= Xref: csiph.com comp.lang.c:96868 supercat@casperkitty.com writes: [...] > A difficulty I think is that the C Standard has no way to define what should > and should not be guaranteed if a function with a declared return type runs > off the end. In some application fields, it's common to have a function > like > > int doSomething(int action, void *parameters); > > where some values of action will result in the function having something > meaningful to return and other actions won't. The authors of the Standard > didn't want to force the called function to include code to set the return > value in situations where the caller is never going to use it, so they > allow valueless returns. [...] I don't believe that's the rationale. Do you have a citation to support your claim? Pre-ANSI C did not have the "void" type and keyword. It was not possible to define a function that did not return a value. To write a function that doesn't return a *meaningful* value, the convention was to define it with no explicit return type: func() { do_something; } Of course func() implicitly returned int, but if the value was never used it was acceptable not to return a value. Later versions of C had to avoid breaking old code, so they permit a function to fail to explicitly return a result as long as the caller doesn't use that result. If C had had "void" from the beginning, it would have made more sense to make falling off the end of a non-void function undefined behavior. The *only* reason to support non-void functions that don't return results is to support old code. In well-written modern C, if an int function doesn't always return a meaningful result, it can simply return 0, and if a function never returns a meaningful result it can have a return type of void. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"