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: absence of max Date: Sat, 10 Dec 2016 14:20:03 -0800 Organization: None to speak of Lines: 100 Message-ID: References: <0e1db67d-0ab8-4971-a319-8aa66a40b873@googlegroups.com> <71c8962e-b06e-44a5-8bda-a79d8cda48e5@googlegroups.com> <71b11aaa-478e-4b1a-9411-e27093a58ab8@googlegroups.com> <87mvgagff0.fsf@bsb.me.uk> <874m2gh2u7.fsf@bsb.me.uk> <9c45c97c-5a79-4671-90e5-757d5fb40347@googlegroups.com> <87fuly9hz5.fsf@bsb.me.uk> <0992e89f-7296-4a69-9cb3-47e305f05af3@googlegroups.com> <87inqu7y4s.fsf@bsb.me.uk> <3946bed7-8930-45e5-8274-d64f8c72b6f5@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="d3e5cee4cb06db8dd070f0b5a238435d"; logging-data="28874"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18+5OYfVk9jtuRpCCijegQ7" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:YqFUnOi3mA2vvJapZdq8tZIbzLE= sha1:1IoI64HIOg8+JqsnwlE1cC5GNj4= Xref: csiph.com comp.lang.c:98740 Tim Rentsch writes: > Keith Thompson writes: >> [does clang adjust the types of arguments based on a previous >> K&R style function definition?] >> >> Since I'm unwilling to dig through an assembly listing, I'll provide an >> example whose run-time output demonstrates the issue. (I encourage you >> to do likewise when presenting similar examples.) >> >> #include >> >> double func(param) >> double param; >> { >> return param; >> } >> >> int main(void) { >> double result = func(42); >> printf("result = %g\n", result); >> } >> >> The results on my system: >> >> $ gcc --version | head -1 >> gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005 >> $ gcc c.c -o c && ./c >> result = 3.22526e-319 >> $ clang --version | head -1 >> clang version 3.8.1-12ubuntu1 (tags/RELEASE_381/final) >> $ clang c.c -o c && ./c >> result = 42 >> $ >> >> That's very interesting: clang *does* convert arguments to the >> parameter type when a non-prototype definition is visible, while >> gcc doesn't. Based on minimal testing, this seems to be consistent >> across versions of clang and optimization levels. I get the same >> behavior, and no diagnostics, with "-std=c11 -pedantic". [...] > > I think you have jumped to a wrong conclusion here. You're right. > If we do > another test with a call before func() is defined: > > #include > > double func(); > > double fbefore(){ > return func( 42 ); > } > > double func(param) > double param; > { > return param; > } > > int main(void) { > double result = func(42); > double r2 = fbefore(); > printf("result = %g\n", result); > printf("r2 = %g\n", r2); > } > > both 'result' and 'r2' are 42. (All outputs reported come from > compiling with clang.) [...] Yes, this is interesting. I think this just is a result of compile-time optimization interacting with function calls whose behavior is undefined. There is no consistent behavior for calls to unprototyped functions with visible definitions. Your first program, quoted above, has this output when compiled by clang on my system: result = 42 r2 = 42 If I change the body of main from this: double result = func(42); double r2 = fbefore(); printf("result = %g\n", result); printf("r2 = %g\n", r2); to this (just swapping the 2nd and 3rd lines): double result = func(42); printf("result = %g\n", result); double r2 = fbefore(); printf("r2 = %g\n", r2); the output becomes: result = 42 r2 = 3.22526e-319 -- 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"