Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #105787
| From | BartC <bc@freeuk.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Return statement: anything goes? |
| Date | 2017-03-11 12:11 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <oa0pct$9ll$1@dont-email.me> (permalink) |
| References | <o9utno$5tn$1@dont-email.me> <87o9x8yjgp.fsf@bsb.me.uk> <e06a31f8-6c98-4fe3-a87f-aaddbef8d138@googlegroups.com> <87inngy57x.fsf@bsb.me.uk> |
On 11/03/2017 01:25, Ben Bacarisse wrote:
> bart4858@gmail.com writes:
>> My problem (and this is one example) is that if I'm too strict, then I
>> may not be able to compile existing code that might have passed the
>> lower standards of other compilers.
>
> It's more a matter of matched the language standard. That's why
> rejecting correct programs like:
>
> #include <stdio.h>
> int f(void) { puts("OK"); }
> int main(void) { f(); }
>
> would create a new dialect.
It would be a better, safer dialect then.
Suppose f() was defined in one module, and called from another which
makes use of its return value. Then the value returned is undefined.
The handful of tests I've done show that f generally returns either 0,
or whatever the last contents of the main return register were.
When f() returns a float, then it might return 0.0, -Nan, -1#IND00, or
again, whatever the last calculation was.
That's not the sort of behaviour I want in my programs.
The problem is that someone may have forgotten to put in a return statement.
(BTW the chart in the OP shows DMC with an 'entry' E against B2; it
should have been B3. So both DMC and Tiny C ignore the missing return
above.)
Another issue is when f() has one return type in one module, but a
different one in another (or even a completely different set of parameters).
That doesn't seem to be picked up at the minute by any C compilers, even
when all modules are compiled at the same time (unless the latest gcc
has some new option for it).
(My compiler however could detect that with little trouble, when sources
are available (obviously it can't detect it inside an already compiled
library!). But that's because all sources must be submitted and there
will be a global, shared symbol table for all modules.)
> Some compilers on your list may not support
> modern C (especially by default), so a void function might be impossible
> to define making code like
>
> f() { puts("OK"); }
>
> very common.
I've decided not to support functions declared with with () parameters,
nor old-style parameter declarations, nor implicit int. At some point
it's necessary to draw the line.
--
Bartc
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Return statement: anything goes? BartC <bc@freeuk.com> - 2017-03-10 19:13 +0000
Re: Return statement: anything goes? John Bode <jfbode1029@gmail.com> - 2017-03-10 11:59 -0800
Re: Return statement: anything goes? Keith Thompson <kst-u@mib.org> - 2017-03-10 12:34 -0800
Re: Return statement: anything goes? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-10 20:17 +0000
Re: Return statement: anything goes? bart4858@gmail.com - 2017-03-10 13:17 -0800
Re: Return statement: anything goes? Ian Collins <ian-news@hotmail.com> - 2017-03-11 10:30 +1300
Re: Return statement: anything goes? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-11 01:25 +0000
Re: Return statement: anything goes? BartC <bc@freeuk.com> - 2017-03-11 12:11 +0000
Re: Return statement: anything goes? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-11 14:57 +0000
Re: Return statement: anything goes? BartC <bc@freeuk.com> - 2017-03-11 16:31 +0000
Re: Return statement: anything goes? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-11 17:47 +0000
Re: Return statement: anything goes? BartC <bc@freeuk.com> - 2017-03-11 17:57 +0000
Re: Return statement: anything goes? jameskuyper@verizon.net - 2017-03-11 10:59 -0800
Re: Return statement: anything goes? BartC <bc@freeuk.com> - 2017-03-11 19:34 +0000
Re: Return statement: anything goes? jameskuyper@verizon.net - 2017-03-11 11:59 -0800
Re: Return statement: anything goes? supercat@casperkitty.com - 2017-03-11 12:26 -0800
Re: Return statement: anything goes? supercat@casperkitty.com - 2017-03-11 12:22 -0800
Re: Return statement: anything goes? jameskuyper@verizon.net - 2017-03-11 12:42 -0800
Re: Return statement: anything goes? supercat@casperkitty.com - 2017-03-11 13:01 -0800
Re: Return statement: anything goes? Gordon Burditt <gordon@hammy.burditt.org> - 2017-03-13 16:25 -0500
Re: Return statement: anything goes? Gareth Owen <gwowen@gmail.com> - 2017-03-11 16:43 +0000
Re: Return statement: anything goes? BartC <bc@freeuk.com> - 2017-03-11 18:13 +0000
Re: Return statement: anything goes? BartC <bc@freeuk.com> - 2017-03-11 18:27 +0000
Re: Return statement: anything goes? gordonb.rlpr3@burditt.org (Gordon Burditt) - 2017-03-13 16:18 -0500
Re: Return statement: anything goes? supercat@casperkitty.com - 2017-03-11 12:44 -0800
Re: Return statement: anything goes? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-11 07:43 -0800
Re: Return statement: anything goes? BartC <bc@freeuk.com> - 2017-03-11 18:34 +0000
Re: Return statement: anything goes? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-11 10:43 -0800
Re: Return statement: anything goes? Keith Thompson <kst-u@mib.org> - 2017-03-10 12:27 -0800
Re: Return statement: anything goes? Noob <root@127.0.0.1> - 2017-03-10 22:06 +0100
Re: Return statement: anything goes? bart4858@gmail.com - 2017-03-10 13:26 -0800
Re: Return statement: anything goes? antispam@math.uni.wroc.pl - 2017-03-12 05:29 +0000
Re: Return statement: anything goes? BartC <bc@freeuk.com> - 2017-03-12 10:52 +0000
Re: Return statement: anything goes? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-12 12:19 +0000
Re: Return statement: anything goes? BartC <bc@freeuk.com> - 2017-03-12 12:51 +0000
csiph-web