Path: csiph.com!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: Thu, 08 Dec 2016 15:46:20 -0800 Organization: None to speak of Lines: 55 Message-ID: References: <0e1db67d-0ab8-4971-a319-8aa66a40b873@googlegroups.com> <2bba48cd-e2c6-44f1-bce9-eff26acbba50@googlegroups.com> <37a4c69f-07eb-4e03-b548-7348629e6b3c@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> <55af72f5-4abd-4ded-b88a-3a05a6f77675@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="2ad4785427d430f26583540ef5e88668"; logging-data="10769"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+CgVcXJyJumdqWKh7xQLGB" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:A2n9DtNrLkGMe7yVBf6Wwhe6Gew= sha1:6CxvrjACJd6SGC3sY3/GZ3rRjNE= Xref: csiph.com comp.lang.c:98432 supercat@casperkitty.com writes: > On Thursday, December 8, 2016 at 4:25:08 PM UTC-6, Ben Bacarisse wrote: >> supercat@casperkitty.com writes: >> > True. But until compilers supported prototypes that would often be >> > just as true when a function definition was visible as when it >> > wasn't. There may have been some compilers in the mid-1980s which >> > would keep track of function parameter types and use them to adjust >> > arguments, but that was not a commonplace situation, >> >> I am surprised you even consider it a possibility. For one thing it >> goes against the explicit wording of the only language standard around >> at the time (K&R) but, worse, it would produce very fragile code. Just >> taking a function out into a separate translation unit and placing a >> corresponding declaration into a suitable header file would change the >> semantics of some (but all) calls to it. > > I have seen a variety of compilers over the years--some good, some bad, > and have come to the conclusion that it would be far more useful to have > a standard describe things compilers should do *when practical*, and > require that compilers document and provide macros to test for cases where > they can't behave in the preferred fashion, than to have a standard which > eschews optional features in favor of saying that the only programmers > should expect are those which are mandatory in all implementations. > > There are many embedded applications which don't need recursion and don't > need ten-digit floating-point support, and I see no reason why it shouldn't > be possible to have the Standard describe the behavior of low-end platforms > which can't support all applications but could support many applications > usefully. A floating-point type with about 9.5 digits of accuracy (32-bit > mantissa) would on many platforms be a lot cheaper than one with 10, but > the Standard wouldn't consider such a thing acceptable as a "double". If > an application could get by with slightly looser precision, which would be > more useful--a conforming compiler upon which floating-point math is twice > as slow, or a compiler which doesn't conform to the Standard but does math > twice as fast (bearing in mind that applications which absolutely need > 10-digit precision could #if-test DBL_DIG and invoke #error if it's doesn't > meet requirements). Are you under the impression that those two long paragraphs are in any way responsive to what Ben wrote? The topic under discussion was one very specific thing: whether pre-ANSI C compilers might pass arguments differently depending on whether or not the function's definition is visible. (As far as I can tell, the answer is most likely no.) What does telling us, yet again, how you think the Standard should be written have to do with a discussion of the behavior of pre-Standard compilers? -- 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"