Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #73976 > unrolled thread
| Started by | Alla _ <modelling.data@gmail.com> |
|---|---|
| First post | 2015-10-27 09:52 -0700 |
| Last post | 2015-10-31 01:14 -0700 |
| Articles | 20 on this page of 174 — 20 participants |
Back to article view | Back to comp.lang.c
Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 09:52 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 10:06 -0700
Re: Problem with the function that should display new letter John Gordon <gordon@panix.com> - 2015-10-27 17:16 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 11:28 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 10:09 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 10:12 -0700
Re: Problem with the function that should display new letter Barry Schwarz <schwarzb@dqel.com> - 2015-10-27 13:12 -0700
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-27 13:23 -0700
Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-27 13:49 -0700
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-27 21:27 +0000
Re: Problem with the function that should display new letter Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-10-27 18:00 -0400
Re: Problem with the function that should display new letter glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-28 02:53 +0000
Re: Problem with the function that should display new letter Robert Wessel <robertwessel2@yahoo.com> - 2015-10-28 00:43 -0500
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 06:08 +0000
Re: Problem with the function that should display new letter glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-28 08:44 +0000
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-28 09:26 +0100
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 08:44 +0000
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-28 10:40 +0100
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-28 06:44 -0700
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-28 06:35 -0700
Re: Problem with the function that should display new letter "D. Aaron Sawyer" <aaron@110.net> - 2015-10-27 13:40 -0400
Re: Problem with the function that should display new letter "D. Aaron Sawyer" <aaron@110.net> - 2015-10-27 13:47 -0400
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 11:38 -0700
Re: Problem with the function that should display new letter "D. Aaron Sawyer" <aaron@110.net> - 2015-10-27 16:46 -0400
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 11:39 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 18:20 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 11:36 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 12:09 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 11:51 -0700
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-27 19:25 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-27 12:27 -0700
Re: Problem with the function that should display new letter Ian Collins <ian-news@hotmail.com> - 2015-10-28 10:07 +1300
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-28 00:50 -0700
Re: Problem with the function that should display new letter Ian Collins <ian-news@hotmail.com> - 2015-10-28 21:04 +1300
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-28 01:13 -0700
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 10:40 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 11:02 +0000
Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-28 11:28 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 11:57 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 12:53 +0000
Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-28 13:33 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 08:35 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 10:59 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 11:04 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 11:38 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 11:43 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 12:10 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 12:58 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 13:55 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 14:02 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 15:01 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 15:44 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 16:22 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 16:26 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 16:44 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 18:45 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 19:26 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-28 20:44 +0000
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-28 22:59 +0100
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 22:48 +0000
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-29 01:14 +0100
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 01:07 +0000
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-29 14:07 +0100
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 13:57 +0000
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-29 16:22 +0100
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-29 08:38 -0700
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-29 17:25 +0100
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-29 12:46 -0700
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-30 09:03 +0100
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 19:19 +0000
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-30 09:54 +0100
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-30 12:20 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 21:36 +0000
Re: Problem with the function that should display new letter Ian Collins <ian-news@hotmail.com> - 2015-10-30 10:47 +1300
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 22:25 +0000
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-30 09:59 +0100
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-30 10:07 +0100
Re: Problem with the function that should display new letter David Brown <david.brown@hesbynett.no> - 2015-10-28 16:25 +0100
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-28 16:01 +0000
Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-28 09:50 -0700
Re: Problem with the function that should display new letter glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-28 21:57 +0000
Re: Problem with the function that should display new letter Geoff <geoff@invalid.invalid> - 2015-10-28 18:25 -0700
Re: Problem with the function that should display new letter Geoff <geoff@invalid.invalid> - 2015-10-28 18:23 -0700
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 01:44 +0000
Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-28 07:07 -0700
Re: Problem with the function that should display new letter Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 07:07 -0700
Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-30 09:08 -0700
Re: Problem with the function that should display new letter Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 14:29 -0700
Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-30 16:10 -0700
Re: Problem with the function that should display new letter Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 20:27 -0700
Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-31 12:40 -0700
Re: Problem with the function that should display new letter Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-02 02:16 -0800
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 03:36 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 10:46 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 03:56 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 04:00 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 11:02 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 04:05 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 11:14 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 04:14 -0700
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-29 11:26 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 11:26 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 05:29 -0700
Re: Problem with the function that should display new letter James Kuyper <jameskuyper@verizon.net> - 2015-10-29 09:23 -0400
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 07:44 -0700
Re: Problem with the function that should display new letter James Kuyper <jameskuyper@verizon.net> - 2015-10-29 11:39 -0400
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 09:52 -0700
Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-29 16:02 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 09:56 -0700
Re: Problem with the function that should display new letter James Kuyper <jameskuyper@verizon.net> - 2015-10-29 13:41 -0400
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 17:46 +0000
Re: Problem with the function that should display new letter Udyant Wig <udyantw@gmail.com> - 2015-10-30 00:14 +0530
Re: Problem with the function that should display new letter raltbos@xs4all.nl (Richard Bos) - 2015-10-29 19:30 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 22:08 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 22:28 -0700
Re: Problem with the function that should display new letter Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 08:10 -0700
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-30 08:56 -0700
Re: Problem with the function that should display new letter Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 13:18 -0700
Re: Problem with the function that should display new letter Ian Collins <ian-news@hotmail.com> - 2015-10-30 09:11 +1300
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 01:21 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 04:04 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 11:11 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 04:19 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 11:24 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 05:26 -0700
Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-29 08:31 -0700
Re: Problem with the function that should display new letter James Kuyper <jameskuyper@verizon.net> - 2015-10-29 09:42 -0400
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 08:31 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-29 10:17 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-29 17:36 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 01:18 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 08:36 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 08:38 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 02:26 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 09:32 +0000
Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-30 13:39 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 03:59 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 11:18 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 06:24 -0700
Re: Problem with the function that should display new letter James Kuyper <jameskuyper@verizon.net> - 2015-10-30 14:18 -0400
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 06:34 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 13:39 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 06:57 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-11-01 09:06 +0000
Re: Problem with the function that should display new letter Keith Thompson <kst-u@mib.org> - 2015-10-30 08:49 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 10:18 -0700
Re: Problem with the function that should display new letter Barry Schwarz <schwarzb@dqel.com> - 2015-10-29 11:48 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 01:23 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 01:42 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 09:13 +0000
Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-30 10:17 +0000
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 10:23 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 06:39 -0700
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 06:45 -0700
Re: Problem with the function that should display new letter Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 13:55 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-30 07:05 -0700
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-10-30 23:29 +0000
Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 01:14 +0000
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-10-31 17:02 +0000
Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 18:05 +0000
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-10-31 23:46 +0000
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-11-01 08:46 -0800
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-11-01 23:43 +0000
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-11-01 16:05 -0800
Re: Problem with the function that should display new letter Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-01 21:41 +0000
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-11-01 22:46 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-31 18:22 +0000
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-10-31 23:57 +0000
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-10-31 17:20 +0000
Re: Problem with the function that should display new letter Bartc <bc@freeuk.com> - 2015-10-31 13:38 +0000
Re: Problem with the function that should display new letter supercat@casperkitty.com - 2015-10-31 11:28 -0700
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-11-01 00:06 +0000
Re: Problem with the function that should display new letter Steve Thompson <stevet810@gmail.com> - 2015-10-31 17:58 +0000
Re: Problem with the function that should display new letter Alla _ <modelling.data@gmail.com> - 2015-10-31 01:14 -0700
Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-10-28 13:33 +0000 |
| Message-ID | <87r3kfglrt.fsf@bsb.me.uk> |
| In reply to | #74069 |
Bartc <bc@freeuk.com> writes: > On 28/10/2015 11:28, Ben Bacarisse wrote: >> Bartc <bc@freeuk.com> writes: > >>> This is one of those cases where an exception can be made. A-Z are >>> commonly numbered 1 to 26 in all sorts of situations. (If you had to >>> tap N times on the metal pipe in your cell to communicate one of A to >>> Z, then 0 taps for A makes that awkward.) >> >> The program is not going to tap anything out. It's going to do modular >> arithmetic on the result and then index that array again. Both are >> naturally 0-based operations. >> >>> So a return of i+1 would be simplest (with adjustments in the >>> caller). >> >> How is returning i+1 simpler than returning i? > > Is the caller going to check the result? Then it needs to be decided > whether lookup returns 0 to 25 on success, and -1 etc on failure, or 1 > to 26 on success, and 0 on failure. What am I supposed to get from this? Do you think I don't know you have to decide what to return? That seems to be all you are saying. Anyway, in case it matters, yes, you need to decide what to return in all the various cases. > In the latter case, returning i+1 is simpler (Another way is to offset > the array so that 'A' starts at element [1]. Then the need to have A=0 > for the purpose of indexing disappears.) "In the latter case"! So your point is if you want to return 1-26 returning i+1 is simpler? Yes, yes it is, if you have decided that already. My point was quite different. It was to question the idea that it was simpler overall. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-28 08:35 +0000 |
| Message-ID | <n0q18q$v5b$1@dont-email.me> |
| In reply to | #74045 |
On 28/10/15 07:50, Alla _ wrote:
<snip>
> Thank you. When used in main function, 'return 0' means
> that the function did perform its task correctly. Does
> return 0 mean the same in the look_up function?
Every function can be thought of as having two important aspects: the
*interface*, and the *implementation*.
The interface to a function, at its simplest (and simple is good),
comprises the name of the function, its parameter types (and,
optionally, names), its return type, and some documentation on what it does.
The implementation is the "body" of the function. Although this doesn't
apply to you at the moment, it is not only possible but (later on!)
often desirable for the source code of the function body to be
unavailable to the programmer who is calling that function - that is, it
might only be available to them as object code in a library. So the only
thing they have to go on is the interface. It is therefore imperative
that interfaces are well-defined. Specifically, it is very important
that the caller knows not only what the return type /is/, but what it
/means/.
Normally, you get to decide what the return type means, but not in the
case of main(). The main function is special, because it is the
interface between your program and the operating system (or other
working environment). As such, you don't get to choose how that
interface looks. The operating system has to know, and the only way it
can know is if the interface to main is well-defined.
So, in any hosted implementation (such as the one you are using), the
interface to main must be either:
int main(void);
OR
int main(int argc, char **argv);
OR
an exact equivalent of one of those two interfaces.
Furthermore, the *meaning* of the return type of main() has to be
well-defined, because the operating system has to know what it means,
and there's no way to tell it, so you have to follow the rules.
The rules for main are:
A return value of 0 means "success" (whatever that means).
A return value of EXIT_SUCCESS (defined in <stdlib.h>) means "success",
too, although there is no requirement for it to be the same kind of
success! (Normally, it is.)
A return value of EXIT_FAILURE (again defined in <stdlib.h>) means
"something went wrong".
Any other return value steps outside the guarantees given by the
language definition (which isn't to say that other return values can't
sometimes be useful, but here in comp.lang.c we try to stay within the
bounds of the guarantees given by the language definition).
That's main(). You need to learn all of the above. (It's not difficult -
int main(void) or int main(int argc, char **argv), and return either 0
or EXIT_SUCCESS or EXIT_FAILURE - that's all you need to remember.)
But for your own functions, you get to decide what the return type is.
You get to decide what the return value means. And you get to decide
what parameters the function takes. Finally, you get to decide what the
function does and how it does it. But you have a responsibility to
document the behaviour of the function and the meaning of the return
type. You haven't been doing this so far, which is understandable, but
it's about time you started.
> I don't understand what return 0 means within look_up
> function.
You wrote the function. You get to decide what it means.
As I read look_up, I deduce the following facts from its source (which I
will re-present here):
int look_up (int alpha_letter)
{
int i;
for (i = 0; i < 26; i++)
{
if (alpha_low [i] == alpha_letter || alpha_up [i] == alpha_letter)
return i;
}
return 0;
}
The interface to this function is complicated by the fact that you use
file scope data (the alpha_low and alpha_up arrays), but at heart it is
as follows: you accept as a parameter a character, and you search for
that character within the two arrays. If you find it, you return the
index into the array at which that character can be found (0 to 25). So
if the input is 'a' or 'A', you return 0. If it's 'b' or 'B', you return
1. If it's 'z' or 'Z', you return 25.
If the character is not found, you return 0.
This means that it is not possible for the caller to distinguish between
a successful match of 'a' or 'A', on the one hand and, on the other
hand, a complete failure to find the letter.
Thus, return 0; is not a well-chosen default.
> I understand that it comes into play if there is no
> match, as you said, but what does it say?
It says 'a' or 'A', basically. And in saying so, it tells a lie. So you
need to fix that.
> As Richard has pointed out, I do have to enable certain
> warnings, but before that I have to learn how to do that :)
> Will get to that.
If you are currently invoking your compiler like this:
gcc -o programname programname.c
then, at least to get you started, try doing this instead:
gcc -Wall -Wextra -std=c99 -pedantic -o programname programname.c
Let's break that down. First, your existing command line:
gcc -o programname programname.c
gcc - the compiler program name
-o programname - the name you want your executable program to have
programname.c - the source code filename
Now, adding warnings:
gcc - the compiler program name
-Wall - turn on all the warnings (actually, this doesn't turn them all on!)
-Wextra - turn on some extra warnings not enabled by -Wall
-std=c99 - tells the compiler to use C99 rules (-std=c90 is also allowed)
-pedantic - tells the compiler to let you know everything the ISO C
Standard requires it to let you know (i.e. it flags up some gcc
extensions that are otherwise not diagnosed)
-o programname - the name you want your executable program to have
programname.c - the source code filename
That may all look rather complicated, but it doesn't have to be a big
deal. Just get your fingers into the habit of typing:
gcc -Wall -Wextra -std=c99 -pedantic -o foo foo.c
and you're done (until such time as you discover the joys of Makefiles).
The payoff is that your compiler will start to give you a lot more help
in discovering problems with your code.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-28 10:59 +0000 |
| Message-ID | <n0q9lm$rtv$1@dont-email.me> |
| In reply to | #74054 |
On 28/10/2015 08:35, Richard Heathfield wrote: > So, in any hosted implementation (such as the one you are using), the > interface to main must be either: > > int main(void); > OR > int main(int argc, char **argv); (That's what I used to think. But you don't get the latter interface automatically, not under Windows anyway. The only interface the OS recognises is 'int main(void)' (or 'int anyfunction(void)' depending on what entry point name is used in the executable). The use of 'main(argc, argv)' requires that the C implementation arranges to call an internal function which obtains these arguments from the OS. It's usually done transparently so that it looks like the OS calls main(argc, argv) directly. You find this stuff out when, for example, you try and use the 'ld' linker directly without going through gcc.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-28 11:04 +0000 |
| Message-ID | <n0q9ut$s9m$2@dont-email.me> |
| In reply to | #74059 |
On 28/10/15 10:59, Bartc wrote: > On 28/10/2015 08:35, Richard Heathfield wrote: > >> So, in any hosted implementation (such as the one you are using), the >> interface to main must be either: >> >> int main(void); >> OR >> int main(int argc, char **argv); > > (That's what I used to think. It remains true. > But you don't get the latter interface > automatically, not under Windows anyway. I do. If you don't, it may be that you're not using your tools correctly. > > The only interface the OS recognises is 'int main(void)' (or 'int > anyfunction(void)' depending on what entry point name is used in the > executable). What happens under the hood is irrelevant. From the perspective of the C programmer, what I said is true. And in comp.lang.c, that's the only perspective that matters. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-28 11:38 +0000 |
| Message-ID | <n0qbvp$4f2$1@dont-email.me> |
| In reply to | #74062 |
On 28/10/2015 11:04, Richard Heathfield wrote: > On 28/10/15 10:59, Bartc wrote: >> On 28/10/2015 08:35, Richard Heathfield wrote: >> >>> So, in any hosted implementation (such as the one you are using), the >>> interface to main must be either: >>> >>> int main(void); >>> OR >>> int main(int argc, char **argv); >> >> (That's what I used to think. > > It remains true. > >> But you don't get the latter interface >> automatically, not under Windows anyway. > > I do. If you don't, it may be that you're not using your tools correctly. You get it because the C compiler adds some magic. >> The only interface the OS recognises is 'int main(void)' (or 'int >> anyfunction(void)' depending on what entry point name is used in the >> executable). > > What happens under the hood is irrelevant. From the perspective of the C > programmer, what I said is true. And in comp.lang.c, that's the only > perspective that matters. This group also covers the C standard library, yes? Then it might be worth knowing that, if you want to use the library from assembly code for example, you can't assume that you can also make use of main(argc,argv). -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-28 11:43 +0000 |
| Message-ID | <n0qc9p$5l0$1@dont-email.me> |
| In reply to | #74066 |
On 28/10/15 11:38, Bartc wrote: > On 28/10/2015 11:04, Richard Heathfield wrote: >> On 28/10/15 10:59, Bartc wrote: >>> On 28/10/2015 08:35, Richard Heathfield wrote: >>> >>>> So, in any hosted implementation (such as the one you are using), the >>>> interface to main must be either: >>>> >>>> int main(void); >>>> OR >>>> int main(int argc, char **argv); >>> >>> (That's what I used to think. >> >> It remains true. >> >>> But you don't get the latter interface >>> automatically, not under Windows anyway. >> >> I do. If you don't, it may be that you're not using your tools correctly. > > You get it because the C compiler adds some magic. The C compiler adds *lots* of magic. It turns C source into executable code. That big magic. But far more to the point, we are discussing the C language. In the C language, the interfaces I gave for main() are ***required*** to be supported by an implementation that targets a hosted environment. If your implementation does not support both those interfaces to main in a hosted environment, it is not a C compiler (in the strictest sense of the term). >>> The only interface the OS recognises is 'int main(void)' (or 'int >>> anyfunction(void)' depending on what entry point name is used in the >>> executable). >> >> What happens under the hood is irrelevant. From the perspective of the C >> programmer, what I said is true. And in comp.lang.c, that's the only >> perspective that matters. > > This group also covers the C standard library, yes? Then it might be > worth knowing that, if you want to use the library from assembly code > for example, you can't assume that you can also make use of > main(argc,argv). If you're using the library from assembly code, you need to be asking about it in a different newsgroup. Here in comp.lang.c, in a hosted environment it is necessarily the case that the implementation supports argc and argv (although it is not required to do anything useful with them - but at the very least, argv[argc] is guaranteed to exist and to be a null pointer). -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-28 12:10 +0000 |
| Message-ID | <n0qdrt$bb6$1@dont-email.me> |
| In reply to | #74067 |
On 28/10/2015 11:43, Richard Heathfield wrote: > On 28/10/15 11:38, Bartc wrote: >> This group also covers the C standard library, yes? Then it might be >> worth knowing that, if you want to use the library from assembly code >> for example, you can't assume that you can also make use of >> main(argc,argv). > > If you're using the library from assembly code, (I need to do both: from generated assembly code, and from generated C code. With the former, I don't have the luxury of using main(argc, argc) (nor of using WinMain(...)). Since the input to both targets has to be the same, I can only work with main(void).) > you need to be asking > about it in a different newsgroup. (Which one would that be that knows the ins and outs of how the C runtime works? I have actually tried that and there was a lot of confusion there too.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-28 12:58 +0000 |
| Message-ID | <n0qglb$lft$1@dont-email.me> |
| In reply to | #74070 |
On 28/10/15 12:10, Bartc wrote: > On 28/10/2015 11:43, Richard Heathfield wrote: >> On 28/10/15 11:38, Bartc wrote: > >>> This group also covers the C standard library, yes? Then it might be >>> worth knowing that, if you want to use the library from assembly code >>> for example, you can't assume that you can also make use of >>> main(argc,argv). >> >> If you're using the library from assembly code, > > (I need to do both: from generated assembly code, and from generated C > code. With the former, I don't have the luxury of using main(argc, argc) > (nor of using WinMain(...)). Since the input to both targets has to be > the same, I can only work with main(void).) <OT> Assembly language how-to for command line arguments: https://www.freebsd.org/doc/en/books/developers-handbook/x86-command-line.html </OT> >> you need to be asking >> about it in a different newsgroup. > > (Which one would that be that knows the ins and outs of how the C > runtime works? Finding an appropriate newsgroup for the things you want to talk about is your job, not mine. > I have actually tried that and there was a lot of > confusion there too.) The only confusion /here/ is yours. C supports argc and argv just fine. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-28 13:55 +0000 |
| Message-ID | <n0qk00$419$1@dont-email.me> |
| In reply to | #74073 |
On 28/10/2015 12:58, Richard Heathfield wrote: > On 28/10/15 12:10, Bartc wrote: >> (I need to do both: from generated assembly code, and from generated C >> code. With the former, I don't have the luxury of using main(argc, argc) >> (nor of using WinMain(...)). Since the input to both targets has to be >> the same, I can only work with main(void).) > > <OT> > Assembly language how-to for command line arguments: > https://www.freebsd.org/doc/en/books/developers-handbook/x86-command-line.html > </OT> "Before a UNIX® system starts a program, it pushes some data on the stack,..." Presumably that would be argc and the list of argv values, which would be jolly handy when you happen to be running C programs! But apparently that doesn't seem to happen with Windows (and how would it know that an executable represents a C program?) Just too much 'intimacy' between C and Unix IMO (and I wonder which came first: how Unix deals with argc/argv, or how C deals with it?) >> (Which one would that be that knows the ins and outs of how the C >> runtime works? > > Finding an appropriate newsgroup for the things you want to talk about > is your job, not mine. Well, your remit seems to include knowing it's not this one. Even though the question is about 'int main(int argc, char** argv)'. It's obviously not Cobol... >> I have actually tried that and there was a lot of >> confusion there too.) > > The only confusion /here/ is yours. C supports argc and argv just fine. C the language, the C compiler, the linker, the C runtime, the OS....? Before I came across the problem, I also hazily thought that main(argc,argv) was somehow always available, without knowing the details. It's no longer of interest to me, I was pointing it out as an interesting fact. But someone thinking of putting together a C compiler, and depending on using a generic linker and C runtime, will also come across the issue sooner or later. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-28 14:02 +0000 |
| Message-ID | <n0qkd4$68n$1@dont-email.me> |
| In reply to | #74078 |
On 28/10/15 13:55, Bartc wrote:
> On 28/10/2015 12:58, Richard Heathfield wrote:
>> On 28/10/15 12:10, Bartc wrote:
>
>>> (I need to do both: from generated assembly code, and from generated C
>>> code. With the former, I don't have the luxury of using main(argc, argc)
>>> (nor of using WinMain(...)). Since the input to both targets has to be
>>> the same, I can only work with main(void).)
>>
>> <OT>
>> Assembly language how-to for command line arguments:
>> https://www.freebsd.org/doc/en/books/developers-handbook/x86-command-line.html
>>
>> </OT>
>
> "Before a UNIX® system starts a program, it pushes some data on the
> stack,..."
>
> Presumably that would be argc and the list of argv values, which would
> be jolly handy when you happen to be running C programs!
>
> But apparently that doesn't seem to happen with Windows
<OT>
The previous Web search took a couple of seconds. So did this one, which
is for Windows:
;
----------------------------------------------------------------------------
; echo.asm
;
; NASM implementation of a program that displays its commandline
arguments,
; one per line.
;
----------------------------------------------------------------------------
global _main
extern _printf
section .text
_main:
mov ecx, [esp+4] ; argc
mov edx, [esp+8] ; argv
top:
push ecx ; save registers that printf wastes
push edx
push dword [edx] ; the argument string to display
push format ; the format string
call _printf
add esp, 8 ; remove the two parameters
pop edx ; restore registers printf used
pop ecx
add edx, 4 ; point to next argument
dec ecx ; count down
jnz top ; if not done counting keep going
ret
format:
db '%s', 10, 0
> (and how would it know that an executable represents a C program?)
You might try doing your own research occasionally. I've given you a
starting point for both Linux and Windows. Assembly language is topical
in assembly language newsgroups, not comp.lang.c.
</OT>
> Just too much 'intimacy' between C and Unix IMO (and I wonder which came
> first: how Unix deals with argc/argv, or how C deals with it?)
I don't know and I don't really care. The point is, the interfaces to
main in C are well-defined.
<snip>
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-28 15:01 +0000 |
| Message-ID | <n0qns1$jce$1@dont-email.me> |
| In reply to | #74079 |
On 28/10/2015 14:02, Richard Heathfield wrote: > On 28/10/15 13:55, Bartc wrote: >> "Before a UNIX® system starts a program, it pushes some data on the >> stack,..." >> >> Presumably that would be argc and the list of argv values, which would >> be jolly handy when you happen to be running C programs! >> >> But apparently that doesn't seem to happen with Windows > > The previous Web search took a couple of seconds. So did this one, which > is for Windows: > _main: > mov ecx, [esp+4] ; argc > mov edx, [esp+8] ; argv .... > You might try doing your own research occasionally. This crashes when linked with ld, because that is not how Windows passes control to a program. It works when using gcc as linker, but the program is 8 times the size with a lot of extra junk whose job it is make it look like that is the normal interface from the OS. It is this kind of thing that can make people confused. But, being dependent on a very specific and sprawling 250MB C compiler where you never know what is doing what, can also partly defeat the purpose of using assembly. (Having an external dependency on the C runtime via msvcrt.dll, which is always part of the OS, is not a problem.) > I don't know and I don't really care. The point is, the interfaces to > main in C are well-defined. Some of us have to work both inside and outside the language, so this stuff can be important. But I think it is also useful to be aware of what is going on. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-28 15:44 +0000 |
| Message-ID | <n0qqcq$t7d$1@dont-email.me> |
| In reply to | #74082 |
On 28/10/15 15:01, Bartc wrote: > On 28/10/2015 14:02, Richard Heathfield wrote: <OT stuff snipped> >> The point is, the interfaces to >> main in C are well-defined. > > Some of us have to work both inside and outside the language, so this > stuff can be important. But I think it is also useful to be aware of > what is going on. There are plenty of very important things to talk about. In fact, there are so many that we have built up a system for categorising them, so that people who are interested in a particular topic can focus on that topic without having to wade through lots of stuff that doesn't interest them. For example, the comp.lang.c newsgroup discusses C programming. For those who wish to work inside the C language, this is the right group. For those who wish to work outside the C language, this is not the right group. For those (like you) who wish to do both, this is the right group for the part where you are working inside the C language, but not the right group for the part where you are working outside the C language. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-28 16:22 +0000 |
| Message-ID | <n0qskk$78e$1@dont-email.me> |
| In reply to | #74088 |
On 28/10/2015 15:44, Richard Heathfield wrote: > On 28/10/15 15:01, Bartc wrote: >> On 28/10/2015 14:02, Richard Heathfield wrote: > > <OT stuff snipped> > >>> The point is, the interfaces to >>> main in C are well-defined. >> >> Some of us have to work both inside and outside the language, so this >> stuff can be important. But I think it is also useful to be aware of >> what is going on. > > There are plenty of very important things to talk about. In fact, there > are so many that we have built up a system for categorising them, so > that people who are interested in a particular topic can focus on that > topic without having to wade through lots of stuff that doesn't interest > them. For example, the comp.lang.c newsgroup discusses C programming. > For those who wish to work inside the C language, this is the right > group. For those who wish to work outside the C language, this is not > the right group. For those (like you) who wish to do both, this is the > right group for the part where you are working inside the C language, > but not the right group for the part where you are working outside the C > language. Except the dividing line is fuzzy. For example, even when I don't want to use C at all, I can't get away from it: * I need to use gcc in order to link, if I want to use main(argc,argv), the subject of this subthread. * If I want to communicate with the OS, the API is in C terms (and clearly designed to be called from C). * If I want find out exactly what size a 'WORD' is in that API, or exactly how a particular struct is laid out, I need to write C code to do so. * If I want to use a third party library, then more than likely, the API will again be in C, it will come C header files that I have to make sense of. * Then some external libraries and some applications are only available as C sources (and are usually a nightmare to do anything with outside of Unix). * If I want to even look at any open source software, then most of it seems to be in C. * Sometimes, I need code to run on a target that my own language doesn't support (in the form of generating native ASM). Then I have to generate C code, considerable amounts of it sometimes. * If I want to distribute a program in my language, then I really need to give out a C source version if I want anyone to be able to build it. Because C insinuates itself everywhere, then a group like this necessarily needs to have a wider scope than a more specific language. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-28 16:26 +0000 |
| Message-ID | <n0qsqm$7js$1@dont-email.me> |
| In reply to | #74091 |
On 28/10/15 16:22, Bartc wrote: > On 28/10/2015 15:44, Richard Heathfield wrote: >> [...] For example, the comp.lang.c newsgroup discusses C programming. >> For those who wish to work inside the C language, this is the right >> group. For those who wish to work outside the C language, this is not >> the right group. For those (like you) who wish to do both, this is the >> right group for the part where you are working inside the C language, >> but not the right group for the part where you are working outside the C >> language. > > Except the dividing line is fuzzy. It's pretty clear, actually. See K&R1, and ISO 9899 (in all its splendid variety). That's where the line is. <snip> -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-28 16:44 +0000 |
| Message-ID | <n0qtub$civ$1@dont-email.me> |
| In reply to | #74092 |
On 28/10/2015 16:26, Richard Heathfield wrote: > On 28/10/15 16:22, Bartc wrote: >> On 28/10/2015 15:44, Richard Heathfield wrote: >>> [...] For example, the comp.lang.c newsgroup discusses C programming. >>> For those who wish to work inside the C language, this is the right >>> group. For those who wish to work outside the C language, this is not >>> the right group. For those (like you) who wish to do both, this is the >>> right group for the part where you are working inside the C language, >>> but not the right group for the part where you are working outside the C >>> language. >> >> Except the dividing line is fuzzy. > > It's pretty clear, actually. See K&R1, and ISO 9899 (in all its splendid > variety). That's where the line is. You snipped my list. The point is that people can be working on projects unconnected with C even in the language they're (I'm two or three languages removed from it at the minute), yet still, something to do with C will regularly turn up. If it ends up as something being discussed here, then it can't always be completely isolated from whatever the context happened to be. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-28 18:45 +0000 |
| Message-ID | <n0r50e$a9q$1@dont-email.me> |
| In reply to | #74093 |
On 28/10/15 16:44, Bartc wrote: > On 28/10/2015 16:26, Richard Heathfield wrote: >> On 28/10/15 16:22, Bartc wrote: >>> On 28/10/2015 15:44, Richard Heathfield wrote: >>>> [...] For example, the comp.lang.c newsgroup discusses C programming. >>>> For those who wish to work inside the C language, this is the right >>>> group. For those who wish to work outside the C language, this is not >>>> the right group. For those (like you) who wish to do both, this is the >>>> right group for the part where you are working inside the C language, >>>> but not the right group for the part where you are working outside >>>> the C >>>> language. >>> >>> Except the dividing line is fuzzy. >> >> It's pretty clear, actually. See K&R1, and ISO 9899 (in all its splendid >> variety). That's where the line is. > > You snipped my list. That's right. It didn't appear to be relevant to comp.lang.c. > The point is that people can be working on projects > unconnected with C There are other newsgroups for matters unconnected with C. FCOL! -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-28 19:26 +0000 |
| Message-ID | <n0r7e6$kue$1@dont-email.me> |
| In reply to | #74097 |
On 28/10/2015 18:45, Richard Heathfield wrote: > On 28/10/15 16:44, Bartc wrote: >> You snipped my list. > > That's right. It didn't appear to be relevant to comp.lang.c. > >> The point is that people can be working on projects >> unconnected with C > > There are other newsgroups for matters unconnected with C. And you've done it again with your selective and misleading quoting. I go on to say: "...something to do with C will regularly turn up." An example of where I go on to post about that something is in the thread "Generic function-calling code". Sometimes a subject just doesn't tidily into a self-contained little slot. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-28 20:44 +0000 |
| Message-ID | <n0rbva$8bu$1@dont-email.me> |
| In reply to | #74100 |
On 28/10/15 19:26, Bartc wrote: > On 28/10/2015 18:45, Richard Heathfield wrote: >> On 28/10/15 16:44, Bartc wrote: > >>> You snipped my list. >> >> That's right. It didn't appear to be relevant to comp.lang.c. >> >>> The point is that people can be working on projects >>> unconnected with C >> >> There are other newsgroups for matters unconnected with C. > > And you've done it again with your selective and misleading quoting. Selective, true. Misleading? I don't think so. > I go on to say: > > "...something to do with C will regularly turn up." Not in my experience. <snip> -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-28 22:59 +0100 |
| Message-ID | <n0rgc3$q58$1@dont-email.me> |
| In reply to | #74091 |
On 28/10/15 17:22, Bartc wrote: > On 28/10/2015 15:44, Richard Heathfield wrote: >> On 28/10/15 15:01, Bartc wrote: >>> On 28/10/2015 14:02, Richard Heathfield wrote: >> >> <OT stuff snipped> >> >>>> The point is, the interfaces to >>>> main in C are well-defined. >>> >>> Some of us have to work both inside and outside the language, so this >>> stuff can be important. But I think it is also useful to be aware of >>> what is going on. >> >> There are plenty of very important things to talk about. In fact, there >> are so many that we have built up a system for categorising them, so >> that people who are interested in a particular topic can focus on that >> topic without having to wade through lots of stuff that doesn't interest >> them. For example, the comp.lang.c newsgroup discusses C programming. >> For those who wish to work inside the C language, this is the right >> group. For those who wish to work outside the C language, this is not >> the right group. For those (like you) who wish to do both, this is the >> right group for the part where you are working inside the C language, >> but not the right group for the part where you are working outside the C >> language. > > Except the dividing line is fuzzy. > > For example, even when I don't want to use C at all, I can't get away > from it: > > * I need to use gcc in order to link, if I want to use main(argc,argv), > the subject of this subthread. > MSVC will, AFAIUI, give argc and argv (and envp) to main when you make a console application. And if you are not using C or C++, then the concept of "main(argc, argv)" doesn't make sense anyway - you use whatever method is suitable for the language in question if you want to access command-line parameters. > * If I want to communicate with the OS, the API is in C terms (and > clearly designed to be called from C). Windows API uses Pascal calling conventions, not C-style conventions, and can be easily called from any language that can support external calls. (*nix systems will use calling conventions suitable for C, for the convenience of everyone, but these can also be called from other languages.) > > * If I want find out exactly what size a 'WORD' is in that API, or > exactly how a particular struct is laid out, I need to write C code to > do so. Or you could look in the documentation. Or you can use any other language that has support for those structs and APIs. > > * If I want to use a third party library, then more than likely, the API > will again be in C, it will come C header files that I have to make > sense of. Many will, but others use different languages. And if it is in C, it is generally easy to write support for the library in other languages. It would be a different matter entirely if the API were in Java, C#, Python, etc. - then you are pretty much stuck with the library's choice of language. C gives a very convenient and clear common base, and except for variadic functions like printf, it's generally a simple matter to interface to other languages. > > * Then some external libraries and some applications are only available > as C sources (and are usually a nightmare to do anything with outside of > Unix). If you don't like using freely available libraries in source code, perhaps you can pay someone to give you closed source code. > > * If I want to even look at any open source software, then most of it > seems to be in C. There is open source software written in dozens of different languages. And you can usually choose to buy something closed-source if you don't like open source code. > > * Sometimes, I need code to run on a target that my own language doesn't > support (in the form of generating native ASM). Then I have to generate > C code, considerable amounts of it sometimes. If you have such a dislike of C, you could always pick a different intermediary language. It would be more work, but it's your choice. > > * If I want to distribute a program in my language, then I really need > to give out a C source version if I want anyone to be able to build it. > > Because C insinuates itself everywhere, then a group like this > necessarily needs to have a wider scope than a more specific language. > This group does not concern itself much with the implementation of C libraries, or run-time support. Nor does it cover C compilers very closely. It's fine to branch out a bit from the main focus on C, of course.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-28 22:48 +0000 |
| Message-ID | <n0rj72$56p$1@dont-email.me> |
| In reply to | #74110 |
On 28/10/2015 21:59, David Brown wrote: > On 28/10/15 17:22, Bartc wrote: >> Except the dividing line is fuzzy. [Between what is topical and not] >> >> For example, even when I don't want to use C at all, I can't get away >> from it: >> >> * I need to use gcc in order to link, if I want to use main(argc,argv), >> the subject of this subthread. > > MSVC will, AFAIUI, give argc and argv (and envp) to main when you make a > console application. And if you are not using C or C++, then the > concept of "main(argc, argv)" doesn't make sense anyway - you use > whatever method is suitable for the language in question if you want to > access command-line parameters. From what I can make out, Windows only ever calls a raw entry point equivalent to int main(void). 'int main(int argc...)' and 'WinMain(...)' are just conventions supported by C compilers and their platform-specific support. You don't get them if you go step outside the normal tools (this came up when I wanted to generate apps with 100% ASM and using standalone linkers, but still using the documented C library functions. Took a while to sort out, not helped by experts insisting that Windows worked a different way. It's not a problem now; what I miss more is gcc's '__chkstk()' routine, but I think I can recreate that.) >> * If I want to communicate with the OS, the API is in C terms (and >> clearly designed to be called from C). > > Windows API uses Pascal calling conventions, not C-style conventions, On Win64 everything uses the same convention. (Incompatible with Linux64, obviously...) >> * If I want find out exactly what size a 'WORD' is in that API, or >> exactly how a particular struct is laid out, I need to write C code to >> do so. > > Or you could look in the documentation. Or you can use any other > language that has support for those structs and APIs. That doesn't really work. Eg it tells you T is defined as U which is defined as V, eventually arriving at a C type, but one which you still have to actually use sizeof() on to double-check. When it comes to structs, then you have all that in spades, plus padding and rounding and alignment to try and double guess. It's easier to just experiment. And these can vary between 32-bits and 64-bits as well. >> * If I want to use a third party library, then more than likely, the API >> will again be in C, it will come C header files that I have to make >> sense of. > > Many will, but others use different languages. And if it is in C, it is > generally easy to write support for the library in other languages. It > would be a different matter entirely if the API were in Java, C#, > Python, etc. - then you are pretty much stuck with the library's choice > of language. C gives a very convenient and clear common base, and > except for variadic functions like printf, it's generally a simple > matter to interface to other languages. Yes, I know. I'm not complaining; it could be a lot worse! (Eg. C++). The point is C comes into it again even if I'm trying not to program in it. >> * Sometimes, I need code to run on a target that my own language doesn't >> support (in the form of generating native ASM). Then I have to generate >> C code, considerable amounts of it sometimes. > > If you have such a dislike of C, you could always pick a different > intermediary language. It would be more work, but it's your choice. There isn't anything else, apart from C++. Other intermediate codes are too high level or too big and complex; it would be easier just to generate the native code. -- Bartc
[toc] | [prev] | [next] | [standalone]
Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web