Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #104028
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: How to find the problem in the object file |
| Date | 2017-02-16 20:03 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <o84sui$ere$1@dont-email.me> (permalink) |
| References | (9 earlier) <kfna8a193yb.fsf@x-alumni2.alumni.caltech.edu> <lnshnt38oz.fsf@kst-u.example.com> <kfnfujo6ib1.fsf@x-alumni2.alumni.caltech.edu> <ln60kjz4ah.fsf@kst-u.example.com> <kfn4lzu18qk.fsf@x-alumni2.alumni.caltech.edu> |
On 16/02/17 16:00, Tim Rentsch wrote: > Keith Thompson <kst-u@mib.org> writes: > >> Tim Rentsch <txr@alumni.caltech.edu> writes: >>> Keith Thompson <kst-u@mib.org> writes: >>>> Tim Rentsch <txr@alumni.caltech.edu> writes: >>>> [...] >>>> >>>> (Context: Removing non-prototype function declarations and definitions >>>> from the language.) >>>> >>>>> My question here is a little different. Knowing that other >>>>> people consider them worth keeping, what explains the reaction >>>>> of wanting to exclude them anyway? Is it just a "my opinions >>>>> count, and other people's don't" sort of attitude, or is it >>>>> something else? >>>> >>>> I didn't say that other people's opinions don't count. I have >>>> my opinion, which I've already expressed, that old-style function >>>> declarations and definitions should be removed from the language. >>> >>> I understand these comments. You are expressing a personal value >>> judgment. Fine so far. >>> >>>> In C99, the committee removed implicit int from the language, and it >>>> hadn't even been marked as obsolescent. I agree with that decision, >>>> and similar reasons apply to non-prototype function declarations >>>> and definitions. Removing them would make C a better language. >>> >>> These comments are what I don't understand. Essentially everyone >>> agreed that implicit int could be removed without any serious >>> loss, especially since there was something to replace it (eg, >>> either 'int' or 'void', depending). Not everyone agrees that >>> non-prototype function declarations can be removed without any >>> serious loss, and IIUC what you're suggesting is that they be >>> removed without any sort of replacement for the capability. The >>> two cases don't seem that analogous. So I don't see how you get >>> to your conclusion, unless it is something like discounting of >>> other people's opinions. >> >> In my opinion, non-prototype function declarations are essentially >> useless, and they exist only for compatibility with code that >> was written before prototypes were available. I have never seen >> a convincing use for them that would not be met at least as well >> by prototypes. > > Yes, you have stated these views before, and I accept them > as your personal assessments. > >> Note that C++ gets along just fine without them. > > I accept that this statement reflects your beliefs in the > matter. Do you mean it as anything more than a statement of > personal opinion or purely subjective value judgment? I am not speaking for Keith here, but I can tell you that I agree with his comment here, and I /don't/ mean it as merely personal opinion. C++ does not support non-prototype function declarations. The language has gone through many revisions, and has a much lower barrier to change than C. If it were seriously felt that non-prototype function declarations were a missing feature, it is likely that they would have been added to the language, or that an alternative would have been added. I cannot claim to have read /all/ the proposals for changes to the C++ language, but I have never seen anything to suggest that this is a feature people feel is missing from the language. I think it is fair to conclude that C++ "gets along just fine without them". > >> The ANSI C committee marked them as obsolescent in 1989. I agree >> with that decision; I take it you do not. > > That depends on what meaning you think was intended. I read this > statement as saying, roughly, "Be advised that something may > change or be removed in a future version of the standard." Not > that it will be removed, or should be removed, or is likely to be > removed, but only that a change may be considered and if so that > may lead to removal. According to the C99 Rationale: >> 6.11.6 Function declarators >> The characterization as obsolecent of the use of the "old style" >> function declarations and definitions, that is, the traditional >> style not using prototypes, signals the Committee's intent that >> the new prototype style should eventually replace the old style. >> >> The case for the prototype style is presented in §6.5.2.2 and >> §6.7.5.3. The gist of this case is that the new syntax addresses >> some of the most glaring weaknesses of the language defined in >> K&R, that the new style is superior to the old style on every count. >> >> It was obviously out of the question to remove syntax used in the >> overwhelming majority of extant C code, so the Standard specifies two >> ways of writing function declarations and function definitions. >> Characterizing the old style as obsolescent is meant to discourage >> its use and to serve as a strong endorsement by the Committee of the >> new style. It confidently expects that approval and adoption of the >> prototype style will make it feasible for some future C Standard to >> remove the old style syntax. Seems pretty clear-cut to me. The old style is still accepted for backwards compatibility, but the Committee considers prototypes to be "superior on every count" and hopes that they can eventually be removed entirely - it is only the existence of pre-C89 code that keeps the old-style declarations legal. Of course that does not stop some people using them, or feeling that their code is better or their development process faster because non-prototype function declarations are allowed. But it /does/ mean that saying "non-prototype functions are a relic of the past, and the language would be better without them" is the /standard/ position. It is the position of the C Standards Committee, and has been for 30 years. Wanting to have them available for use in new code (as distinct from as support for legacy code) is an unusual and rare position.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
How to find the problem in the object file Alla _ <modelling.data@gmail.com> - 2017-01-26 05:14 -0800
Re: How to find the problem in the object file BartC <bc@freeuk.com> - 2017-01-26 13:22 +0000
Re: How to find the problem in the object file BartC <bc@freeuk.com> - 2017-01-26 13:37 +0000
Re: How to find the problem in the object file Richard Heathfield <rjh@cpax.org.uk> - 2017-01-26 13:53 +0000
Re: How to find the problem in the object file Alla _ <modelling.data@gmail.com> - 2017-01-26 06:20 -0800
Re: How to find the problem in the object file BartC <bc@freeuk.com> - 2017-01-26 14:28 +0000
Re: How to find the problem in the object file Alla _ <modelling.data@gmail.com> - 2017-01-26 06:48 -0800
Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-01-26 08:29 -0800
Re: How to find the problem in the object file BartC <bc@freeuk.com> - 2017-01-26 16:54 +0000
Re: How to find the problem in the object file luser droog <luser.droog@gmail.com> - 2017-01-26 09:01 -0800
Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-01-26 11:20 -0800
Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-01-26 23:12 +0100
Re: How to find the problem in the object file BartC <bc@freeuk.com> - 2017-01-27 01:32 +0000
Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-01-27 09:50 +0100
Re: How to find the problem in the object file supercat@casperkitty.com - 2017-01-26 09:19 -0800
Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-01-26 11:21 -0800
Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-02 02:39 -0800
Re: How to find the problem in the object file fir <profesor.fir@gmail.com> - 2017-02-02 04:08 -0800
Re: How to find the problem in the object file fir <profesor.fir@gmail.com> - 2017-02-02 04:31 -0800
Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 10:48 -0800
Re: How to find the problem in the object file fir <profesor.fir@gmail.com> - 2017-02-04 11:07 -0800
Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-02 10:22 -0800
Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 11:00 -0800
Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-04 14:14 -0800
Re: How to find the problem in the object file Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-04 20:02 -0800
Re: How to find the problem in the object file supercat@casperkitty.com - 2017-02-05 13:39 -0800
Re: How to find the problem in the object file Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-05 13:44 -0800
Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-05 13:56 -0800
Re: How to find the problem in the object file Ian Collins <ian-news@hotmail.com> - 2017-02-06 13:07 +1300
Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-05 16:14 -0800
Re: How to find the problem in the object file Ian Collins <ian-news@hotmail.com> - 2017-02-06 13:24 +1300
Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-02-06 01:59 +0100
Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-08 21:32 -0800
Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-05 13:54 -0800
Re: How to find the problem in the object file Ian Collins <ian-news@hotmail.com> - 2017-02-06 11:18 +1300
Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-08 21:32 -0800
Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-02-09 10:33 +0100
Re: How to find the problem in the object file supercat@casperkitty.com - 2017-02-09 09:10 -0800
Re: How to find the problem in the object file Ian Collins <ian-news@hotmail.com> - 2017-02-10 08:01 +1300
Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-09 09:01 -0800
Re: How to find the problem in the object file supercat@casperkitty.com - 2017-02-09 09:35 -0800
Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-09 09:57 -0800
Re: How to find the problem in the object file Jean-Marc Bourguet <jm@bourguet.org> - 2017-02-09 20:45 +0100
Re: How to find the problem in the object file supercat@casperkitty.com - 2017-02-09 14:59 -0800
Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-09 15:20 -0800
Re: How to find the problem in the object file supercat@casperkitty.com - 2017-02-09 16:12 -0800
Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-02-13 10:21 +0100
Re: How to find the problem in the object file supercat@casperkitty.com - 2017-02-13 07:20 -0800
Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-13 09:28 -0800
Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-02-13 09:55 +0100
Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-16 03:36 -0800
Re: How to find the problem in the object file Jean-Marc Bourguet <jm@bourguet.org> - 2017-02-09 20:56 +0100
Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-16 07:00 -0800
Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-02-16 20:03 +0100
Re: How to find the problem in the object file Ian Collins <ian-news@hotmail.com> - 2017-02-17 09:22 +1300
Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-16 13:07 -0800
Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-24 09:21 -0800
Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-24 09:02 -0800
Re: How to find the problem in the object file Ian Collins <ian-news@hotmail.com> - 2017-02-25 09:05 +1300
Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-24 09:26 -0800
Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-02-25 19:38 +0100
Re: How to find the problem in the object file Ian Collins <ian-news@hotmail.com> - 2017-02-03 07:32 +1300
Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 11:24 -0800
Re: How to find the problem in the object file Robert Wessel <robertwessel2@yahoo.com> - 2017-02-02 16:56 -0600
Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 11:12 -0800
Re: How to find the problem in the object file Robert Wessel <robertwessel2@yahoo.com> - 2017-02-06 04:47 -0600
Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-08 21:59 -0800
Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-02-09 09:13 -0800
Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-15 19:28 -0800
Re: How to find the problem in the object file Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-24 17:48 -0800
Re: How to find the problem in the object file Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-25 17:36 -0800
Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-01-26 15:51 +0100
Re: How to find the problem in the object file Alla _ <modelling.data@gmail.com> - 2017-01-26 08:29 -0800
Re: How to find the problem in the object file Richard Heathfield <rjh@cpax.org.uk> - 2017-01-26 16:34 +0000
Re: How to find the problem in the object file Alla _ <modelling.data@gmail.com> - 2017-01-26 09:48 -0800
Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-01-26 08:52 -0800
Re: How to find the problem in the object file James Kuyper <jameskuyper@verizon.net> - 2017-01-26 13:53 -0500
Re: How to find the problem in the object file supercat@casperkitty.com - 2017-01-26 11:00 -0800
Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-01-26 23:49 +0100
Re: How to find the problem in the object file Alla _ <modelling.data@gmail.com> - 2017-01-27 06:08 -0800
Re: How to find the problem in the object file David Brown <david.brown@hesbynett.no> - 2017-01-27 16:20 +0100
Re: How to find the problem in the object file Keith Thompson <kst-u@mib.org> - 2017-01-26 08:41 -0800
Re: How to find the problem in the object file m.labanowicz@gmail.com - 2017-01-27 01:26 -0800
csiph-web