Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #129945 > unrolled thread
| Started by | Real Troll <real.troll@trolls.com> |
|---|---|
| First post | 2018-04-30 02:10 +0000 |
| Last post | 2018-05-01 13:46 +0000 |
| Articles | 20 on this page of 208 — 30 participants |
Back to article view | Back to comp.lang.c
The case AGAINST C Real Troll <real.troll@trolls.com> - 2018-04-30 02:10 +0000
Re: The case AGAINST C cross@spitfire.i.gajendra.net (Dan Cross) - 2018-04-30 03:14 +0000
Re: The case AGAINST C Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-30 05:48 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-04-30 14:58 +0100
Re: The case AGAINST C Davs <johndemeert0@gmail.com> - 2018-05-07 04:18 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-07 05:26 -0700
Re: The case AGAINST C Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-05-07 11:21 -0400
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-07 09:21 -0700
Re: The case AGAINST C Robert Wessel <robertwessel2@yahoo.com> - 2018-05-07 12:13 -0500
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-07 10:24 -0700
Re: The case AGAINST C Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-05-07 13:27 -0400
Re: The case AGAINST C scott@slp53.sl.home (Scott Lurndal) - 2018-05-07 17:33 +0000
Re: The case AGAINST C Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-05-07 13:50 -0400
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-07 10:56 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-08 09:26 +0200
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-08 09:19 +0200
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-08 00:42 -0700
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-08 06:54 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-08 07:24 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-08 17:15 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-08 09:31 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-08 18:48 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-08 10:33 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-08 23:36 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-08 15:08 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-09 00:56 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-08 16:17 -0700
Re: The case AGAINST C Geoff <geoff@invalid.invalid> - 2018-05-08 11:09 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-08 23:43 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-08 15:24 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-09 00:58 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-09 08:11 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-09 08:51 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-09 11:45 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-09 13:03 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-09 23:40 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-09 15:48 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-10 13:48 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-10 08:28 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-11 10:06 +0200
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-11 02:22 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-11 05:29 -0700
Re: The case AGAINST C scott@slp53.sl.home (Scott Lurndal) - 2018-05-11 13:31 +0000
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-11 15:47 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-11 09:16 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-12 17:43 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-12 14:06 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-10 00:13 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-10 01:31 -0700
Re: The case AGAINST C Wouter Verhelst <w@uter.be> - 2018-05-11 18:01 +0200
Re: The case AGAINST C Geoff <geoff@invalid.invalid> - 2018-05-10 08:30 -0700
Re: The case AGAINST C Wouter Verhelst <w@uter.be> - 2018-05-09 09:29 +0200
Re: The case AGAINST C Geoff <geoff@invalid.invalid> - 2018-05-10 08:41 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-11 04:43 -0700
Re: The case AGAINST C Richard Damon <Richard@Damon-Family.org> - 2018-05-08 21:24 -0400
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-09 09:10 +0200
Re: The case AGAINST C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-05-08 19:52 +0000
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-08 23:48 +0200
Re: The case AGAINST C Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-29 22:07 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-04-30 12:22 +0100
Re: The case AGAINST C Melzzzzz <Melzzzzz@zzzzz.com> - 2018-04-30 12:08 +0000
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-04-30 13:38 +0100
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-30 06:05 -0700
Re: The case AGAINST C supercat@casperkitty.com - 2018-04-30 07:39 -0700
Re: The case AGAINST C Ed Kellett <e@kellett.im> - 2018-04-30 15:53 +0100
Re: The case AGAINST C supercat@casperkitty.com - 2018-04-30 08:14 -0700
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-30 21:26 -0700
Re: The case AGAINST C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-30 09:00 -0700
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-01 04:58 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-04-30 18:07 +0100
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-01 05:33 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-01 05:58 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-01 06:27 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-01 14:37 +0100
Re: The case AGAINST C Melzzzzz <Melzzzzz@zzzzz.com> - 2018-05-01 13:41 +0000
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-01 16:48 +0100
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-01 10:11 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-01 11:00 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-01 19:26 +0100
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-01 11:40 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-01 12:53 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-01 22:03 +0100
Re: The case AGAINST C Ian Collins <ian-news@hotmail.com> - 2018-05-02 09:10 +1200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-01 14:21 -0700
Re: The case AGAINST C Ian Collins <ian-news@hotmail.com> - 2018-05-02 09:26 +1200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-01 15:23 -0700
Re: The case AGAINST C scott@slp53.sl.home (Scott Lurndal) - 2018-05-02 14:07 +0000
Re: The case AGAINST C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-05-03 06:28 +0000
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-01 23:03 +0100
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-02 04:52 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-02 05:12 -0700
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-02 05:34 -0700
Re: The case AGAINST C scott@slp53.sl.home (Scott Lurndal) - 2018-05-02 14:08 +0000
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-02 07:39 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-02 17:13 +0100
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-02 11:01 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-02 21:51 +0100
Re: The case AGAINST C Ian Collins <ian-news@hotmail.com> - 2018-05-03 08:52 +1200
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-02 22:42 +0100
Re: The case AGAINST C Ian Collins <ian-news@hotmail.com> - 2018-05-03 09:57 +1200
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-02 23:22 +0100
Re: The case AGAINST C Ian Collins <ian-news@hotmail.com> - 2018-05-03 10:29 +1200
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-03 00:14 +0100
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-03 03:59 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-03 04:15 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-03 12:50 +0100
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-03 13:36 -0700
Of course I get it... (Was: The case AGAINST C) gazelle@shell.xmission.com (Kenny McCormack) - 2018-05-03 08:44 +0000
Re: The case AGAINST C Dan Purgert <dan@djph.net> - 2018-05-03 12:42 +0000
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-03 05:52 -0700
Re: The case AGAINST C Dan Purgert <dan@djph.net> - 2018-05-03 12:56 +0000
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-03 05:58 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-03 14:36 +0100
Re: The case AGAINST C already5chosen@yahoo.com - 2018-05-03 13:27 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-03 22:43 +0100
Re: The case AGAINST C already5chosen@yahoo.com - 2018-05-03 15:17 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-04 00:50 +0100
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-03 15:41 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-04 11:36 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-04 08:52 -0700
Re: The case AGAINST C scott@slp53.sl.home (Scott Lurndal) - 2018-05-04 17:28 +0000
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-04 12:06 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-05 18:45 +0200
Re: The case AGAINST C scott@slp53.sl.home (Scott Lurndal) - 2018-05-06 18:43 +0000
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-06 23:35 +0200
Re: The case AGAINST C scott@slp53.sl.home (Scott Lurndal) - 2018-05-07 13:23 +0000
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-07 06:30 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-07 16:25 +0200
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-07 07:32 -0700
Re: The case AGAINST C Keith Thompson <kst-u@mib.org> - 2018-05-04 09:09 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-04 18:12 +0100
Global variables bartc <bc@freeuk.com> - 2018-05-06 14:07 +0100
Re: Global variables David Brown <david.brown@hesbynett.no> - 2018-05-06 20:03 +0200
Re: Global variables Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-05-06 15:21 -0400
Re: Global variables Keith Thompson <kst-u@mib.org> - 2018-05-06 13:07 -0700
Re: Global variables Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-05-06 16:13 -0400
Re: Global variables David Brown <david.brown@hesbynett.no> - 2018-05-06 23:39 +0200
Re: Global variables Richard Damon <Richard@Damon-Family.org> - 2018-05-06 17:50 -0400
Re: Global variables David Brown <david.brown@hesbynett.no> - 2018-05-06 23:57 +0200
Re: Global variables Richard Damon <Richard@Damon-Family.org> - 2018-05-06 19:56 -0400
Re: Global variables Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-05-07 03:21 +0100
Re: Global variables David Brown <david.brown@hesbynett.no> - 2018-05-07 09:09 +0200
Re: Global variables Keith Thompson <kst-u@mib.org> - 2018-05-07 08:49 -0700
Re: Global variables bartc <bc@freeuk.com> - 2018-05-06 20:55 +0100
Re: Global variables David Brown <david.brown@hesbynett.no> - 2018-05-06 23:51 +0200
Re: Global variables Keith Thompson <kst-u@mib.org> - 2018-05-06 15:40 -0700
Re: Global variables bartc <bc@freeuk.com> - 2018-05-06 23:54 +0100
Re: Global variables Ian Collins <ian-news@hotmail.com> - 2018-05-07 15:12 +1200
Re: Global variables David Brown <david.brown@hesbynett.no> - 2018-05-07 09:03 +0200
Re: Global variables Tim Rentsch <txr@alumni.caltech.edu> - 2018-05-18 20:23 -0700
Re: Global variables Steve Carroll <frelwizzen@gmail.com> - 2018-05-18 20:44 -0700
Re: Global variables David Brown <david.brown@hesbynett.no> - 2018-05-19 17:22 +0200
Re: Global variables supercat@casperkitty.com - 2018-05-19 11:56 -0700
Re: Global variables supercat@casperkitty.com - 2018-05-06 16:28 -0700
Re: Global variables Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-05-06 14:19 -0400
Re: Global variables bartc <bc@freeuk.com> - 2018-05-06 20:16 +0100
Re: Global variables David Brown <david.brown@hesbynett.no> - 2018-05-06 23:09 +0200
Re: Global variables bartc <bc@freeuk.com> - 2018-05-06 23:41 +0100
Re: The case AGAINST C Keith Thompson <kst-u@mib.org> - 2018-05-03 09:13 -0700
Re: The case AGAINST C Dan Purgert <dan@djph.net> - 2018-05-03 17:29 +0000
Re: The case AGAINST C gazelle@shell.xmission.com (Kenny McCormack) - 2018-05-03 19:24 +0000
Re: The case AGAINST C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-05-04 05:46 +0000
Re: The case AGAINST C Dan Purgert <dan@djph.net> - 2018-05-04 10:55 +0000
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-04 04:03 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-04 12:31 +0100
Re: The case AGAINST C already5chosen@yahoo.com - 2018-05-04 05:10 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-04 13:24 +0100
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 06:26 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 06:35 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 07:06 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 07:19 -0700
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-04 06:37 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 08:19 -0700
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-04 12:07 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-04 16:31 +0100
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 08:41 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 09:50 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 10:04 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 13:51 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 14:30 -0700
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-04 15:14 -0700
Re: The case AGAINST C Robert Wessel <robertwessel2@yahoo.com> - 2018-05-04 11:18 -0500
Re: The case AGAINST C Keith Thompson <kst-u@mib.org> - 2018-05-04 09:05 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-04 17:55 +0100
Re: The case AGAINST C Keith Thompson <kst-u@mib.org> - 2018-05-04 10:54 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-04 19:18 +0100
Re: The case AGAINST C Keith Thompson <kst-u@mib.org> - 2018-05-04 11:24 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-06 16:45 +0200
Re: The case AGAINST C jameskuyper@alumni.caltech.edu - 2018-05-04 11:51 -0700
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-04 12:15 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-04 21:56 +0100
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-06 17:01 +0200
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-06 17:54 +0100
Re: The case AGAINST C Keith Thompson <kst-u@mib.org> - 2018-05-06 13:38 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-06 21:49 +0100
Re: The case AGAINST C Richard Damon <Richard@Damon-Family.org> - 2018-05-06 17:19 -0400
Re: The case AGAINST C Keith Thompson <kst-u@mib.org> - 2018-05-06 15:24 -0700
Re: The case AGAINST C Keith Thompson <kst-u@mib.org> - 2018-05-06 15:16 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-06 23:55 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-06 11:59 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-01 14:51 -0700
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-02 04:46 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-01 11:45 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-01 06:10 -0700
Re: The case AGAINST C C W Rose <cwr@seckford.org> - 2018-05-02 15:23 +0100
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-02 17:36 +0100
Re: The case AGAINST C "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-04-30 22:03 +0800
Re: The case AGAINST C Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2018-05-01 13:46 +0000
Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-05-04 17:28 +0000 |
| Message-ID | <OK0HC.115832$mS3.68566@fx04.iad> |
| In reply to | #130181 |
supercat@casperkitty.com writes: >On Friday, May 4, 2018 at 4:36:58 AM UTC-5, David Brown wrote: >> From the viewpoint of the well-disciplined programmer, C #include files >> cover the main requirements of modules. There are, as I see it, four >> main disadvantages: >> >> 1. No namespacing. (C++ solves this with "namespace" - a feature C >> could easily adopt.) >> >> 2. No separation of publicly useful data (like function declarations) >> and implementation data needed by the compiler (like inline function >> definitions, and details of struct contents). >> >> 3. No pre-compilation (that is a side-effect of the flexibility. It is >> of little consequence for most C programming, but slows down very large >> project builds and is a real pain for a lot of C++ programming). >> >> 4. The flexibility means people who don't know how to make C "modules" >> get things wrong. > >5. No ability to interact with code which isn't processed by the same C > implementation, except perhaps by hard-coding or explicitly passing > the addresses of every point of interaction (e.g. if one wants to > call a routine and knows its address will be stored at 0x20001FF8, > one might be able to do something like: > > void (*myRoutine)(myStructType *) = > *(((void**)(myStructType *))0x20001FF8); > myRoutine(&myStruct); Why would anyone, ever, want to do such a silly thing? That's what linkers are for.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-04 12:06 -0700 |
| Message-ID | <a02e1cd3-9f8b-4955-97db-45ac7c73e73f@googlegroups.com> |
| In reply to | #130198 |
On Friday, May 4, 2018 at 12:28:24 PM UTC-5, Scott Lurndal wrote: > supercat@casperkitty.com writes: > >On Friday, May 4, 2018 at 4:36:58 AM UTC-5, David Brown wrote: > >> From the viewpoint of the well-disciplined programmer, C #include files > >> cover the main requirements of modules. There are, as I see it, four > >> main disadvantages: > >> > >> 1. No namespacing. (C++ solves this with "namespace" - a feature C > >> could easily adopt.) > >> > >> 2. No separation of publicly useful data (like function declarations) > >> and implementation data needed by the compiler (like inline function > >> definitions, and details of struct contents). > >> > >> 3. No pre-compilation (that is a side-effect of the flexibility. It is > >> of little consequence for most C programming, but slows down very large > >> project builds and is a real pain for a lot of C++ programming). > >> > >> 4. The flexibility means people who don't know how to make C "modules" > >> get things wrong. > > > >5. No ability to interact with code which isn't processed by the same C > > implementation, except perhaps by hard-coding or explicitly passing > > the addresses of every point of interaction (e.g. if one wants to > > call a routine and knows its address will be stored at 0x20001FF8, > > one might be able to do something like: > > > > void (*myRoutine)(myStructType *) = > > *(((void**)(myStructType *))0x20001FF8); > > myRoutine(&myStruct); > > Why would anyone, ever, want to do such a silly thing? > > That's what linkers are for. Only if there's some concept of separately-compiled modules. If there's no need to access any facilities outside a C implementation, just about anything that could be done using separately-compiled modules could be done by using a linker which could only process one module. Having a linker that can combine multiple modules is useful, but it's not absolutely essential unless one needs to interact with code that's processed by another language implementation without using fixed-address hackery. To be sure, in cases where one can use a linker to take care of things, that's almost always better than using address-based hacks. On the other hand, there may be some cases where that isn't possible. For example, one may have a family of microprocessor-based or microcontroller-based products that perform I/O differently but need to run the same application code. If the addresses of I/O routines are located at fixed addresses and application code performs all I/O using those, a system's I/O routines may be usable by an application that wasn't even imagined when they were written, and an application may be usable on a system that wasn't even imagined when it was written. No need to link the application and I/O routines. Treat each as a bunch of bits, place it at the right address, and they'll work together with no other munging required.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-05 18:45 +0200 |
| Message-ID | <pckn2e$shq$1@dont-email.me> |
| In reply to | #130198 |
On 04/05/18 19:28, Scott Lurndal wrote: > supercat@casperkitty.com writes: >> On Friday, May 4, 2018 at 4:36:58 AM UTC-5, David Brown wrote: >>> From the viewpoint of the well-disciplined programmer, C #include files >>> cover the main requirements of modules. There are, as I see it, four >>> main disadvantages: >>> >>> 1. No namespacing. (C++ solves this with "namespace" - a feature C >>> could easily adopt.) >>> >>> 2. No separation of publicly useful data (like function declarations) >>> and implementation data needed by the compiler (like inline function >>> definitions, and details of struct contents). >>> >>> 3. No pre-compilation (that is a side-effect of the flexibility. It is >>> of little consequence for most C programming, but slows down very large >>> project builds and is a real pain for a lot of C++ programming). >>> >>> 4. The flexibility means people who don't know how to make C "modules" >>> get things wrong. >> >> 5. No ability to interact with code which isn't processed by the same C >> implementation, except perhaps by hard-coding or explicitly passing >> the addresses of every point of interaction (e.g. if one wants to >> call a routine and knows its address will be stored at 0x20001FF8, >> one might be able to do something like: >> >> void (*myRoutine)(myStructType *) = >> *(((void**)(myStructType *))0x20001FF8); >> myRoutine(&myStruct); > > Why would anyone, ever, want to do such a silly thing? > > That's what linkers are for. > You might want to do something like this to call functions in a ROM or pre-programmed part of an embedded system from your own code. Usually, however, there would be a layer of indirection (such as a table of function pointers at a fixed address, rather than the functions themselves at a fixed address). And anyway, in cases like that there is absolutely nothing wrong with using ugly casts like that - it will all be buried away in a header somewhere. I completely fail to see any connection to modules, or how modules might be better than header files for something like this. (And yes, linker files /could/ be used for things like this. Personally, I prefer to have them in C or header files rather than linker files.)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-05-06 18:43 +0000 |
| Message-ID | <%0IHC.30747$eR.6800@fx30.iad> |
| In reply to | #130243 |
David Brown <david.brown@hesbynett.no> writes: >On 04/05/18 19:28, Scott Lurndal wrote: >> supercat@casperkitty.com writes: >>> On Friday, May 4, 2018 at 4:36:58 AM UTC-5, David Brown wrote: >>>> From the viewpoint of the well-disciplined programmer, C #include files >>>> cover the main requirements of modules. There are, as I see it, four >>>> main disadvantages: >>>> >>>> 1. No namespacing. (C++ solves this with "namespace" - a feature C >>>> could easily adopt.) >>>> >>>> 2. No separation of publicly useful data (like function declarations) >>>> and implementation data needed by the compiler (like inline function >>>> definitions, and details of struct contents). >>>> >>>> 3. No pre-compilation (that is a side-effect of the flexibility. It is >>>> of little consequence for most C programming, but slows down very large >>>> project builds and is a real pain for a lot of C++ programming). >>>> >>>> 4. The flexibility means people who don't know how to make C "modules" >>>> get things wrong. >>> >>> 5. No ability to interact with code which isn't processed by the same C >>> implementation, except perhaps by hard-coding or explicitly passing >>> the addresses of every point of interaction (e.g. if one wants to >>> call a routine and knows its address will be stored at 0x20001FF8, >>> one might be able to do something like: >>> >>> void (*myRoutine)(myStructType *) = >>> *(((void**)(myStructType *))0x20001FF8); >>> myRoutine(&myStruct); >> >> Why would anyone, ever, want to do such a silly thing? >> >> That's what linkers are for. >> > >You might want to do something like this to call functions in a ROM or >pre-programmed part of an embedded system from your own code. And for that I'd still be using cross-compilation system that has a linker which allows definition (and association with a specified value, e.g. address) of arbitrary symbols (e.g. binutils ld, arm's ld, Unixware ld, et alia).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-06 23:35 +0200 |
| Message-ID | <pcnsee$7o2$1@dont-email.me> |
| In reply to | #130264 |
On 06/05/18 20:43, Scott Lurndal wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 04/05/18 19:28, Scott Lurndal wrote: >>> supercat@casperkitty.com writes: >>>> On Friday, May 4, 2018 at 4:36:58 AM UTC-5, David Brown wrote: >>>>> From the viewpoint of the well-disciplined programmer, C #include files >>>>> cover the main requirements of modules. There are, as I see it, four >>>>> main disadvantages: >>>>> >>>>> 1. No namespacing. (C++ solves this with "namespace" - a feature C >>>>> could easily adopt.) >>>>> >>>>> 2. No separation of publicly useful data (like function declarations) >>>>> and implementation data needed by the compiler (like inline function >>>>> definitions, and details of struct contents). >>>>> >>>>> 3. No pre-compilation (that is a side-effect of the flexibility. It is >>>>> of little consequence for most C programming, but slows down very large >>>>> project builds and is a real pain for a lot of C++ programming). >>>>> >>>>> 4. The flexibility means people who don't know how to make C "modules" >>>>> get things wrong. >>>> >>>> 5. No ability to interact with code which isn't processed by the same C >>>> implementation, except perhaps by hard-coding or explicitly passing >>>> the addresses of every point of interaction (e.g. if one wants to >>>> call a routine and knows its address will be stored at 0x20001FF8, >>>> one might be able to do something like: >>>> >>>> void (*myRoutine)(myStructType *) = >>>> *(((void**)(myStructType *))0x20001FF8); >>>> myRoutine(&myStruct); >>> >>> Why would anyone, ever, want to do such a silly thing? >>> >>> That's what linkers are for. >>> >> >> You might want to do something like this to call functions in a ROM or >> pre-programmed part of an embedded system from your own code. > > And for that I'd still be using cross-compilation system that has > a linker which allows definition (and association with a > specified value, e.g. address) of arbitrary symbols (e.g. binutils ld, > arm's ld, Unixware ld, et alia). > Been there, done that - and I prefer to put the addresses directly in the C code and not the linker files. It is rare, however, that you have /functions/ at fixed addresses like this (as I said before, you would usually have tables of function pointers). But registers for controlling peripherals are effectively variables, arrays and structs at fixed addresses - and in the same way you can use casts in C or linker files (or even assembly files) to achieve the results. Putting this sort of thing in the C code is typically more readable, less duplication, easier to get right, easier to understand, and a good deal more efficient in the generated code (for registers - it will generally make no difference for a function).
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-05-07 13:23 +0000 |
| Message-ID | <mrYHC.62828$%s2.7745@fx18.iad> |
| In reply to | #130280 |
David Brown <david.brown@hesbynett.no> writes: >On 06/05/18 20:43, Scott Lurndal wrote: >> David Brown <david.brown@hesbynett.no> writes: >>> On 04/05/18 19:28, Scott Lurndal wrote: >>>> supercat@casperkitty.com writes: >>>>> On Friday, May 4, 2018 at 4:36:58 AM UTC-5, David Brown wrote: >>>>>> From the viewpoint of the well-disciplined programmer, C #include files >>>>>> cover the main requirements of modules. There are, as I see it, four >>>>>> main disadvantages: >>>>>> >>>>>> 1. No namespacing. (C++ solves this with "namespace" - a feature C >>>>>> could easily adopt.) >>>>>> >>>>>> 2. No separation of publicly useful data (like function declarations) >>>>>> and implementation data needed by the compiler (like inline function >>>>>> definitions, and details of struct contents). >>>>>> >>>>>> 3. No pre-compilation (that is a side-effect of the flexibility. It is >>>>>> of little consequence for most C programming, but slows down very large >>>>>> project builds and is a real pain for a lot of C++ programming). >>>>>> >>>>>> 4. The flexibility means people who don't know how to make C "modules" >>>>>> get things wrong. >>>>> >>>>> 5. No ability to interact with code which isn't processed by the same C >>>>> implementation, except perhaps by hard-coding or explicitly passing >>>>> the addresses of every point of interaction (e.g. if one wants to >>>>> call a routine and knows its address will be stored at 0x20001FF8, >>>>> one might be able to do something like: >>>>> >>>>> void (*myRoutine)(myStructType *) = >>>>> *(((void**)(myStructType *))0x20001FF8); >>>>> myRoutine(&myStruct); >>>> >>>> Why would anyone, ever, want to do such a silly thing? >>>> >>>> That's what linkers are for. >>>> >>> >>> You might want to do something like this to call functions in a ROM or >>> pre-programmed part of an embedded system from your own code. >> >> And for that I'd still be using cross-compilation system that has >> a linker which allows definition (and association with a >> specified value, e.g. address) of arbitrary symbols (e.g. binutils ld, >> arm's ld, Unixware ld, et alia). >> > >Been there, done that - and I prefer to put the addresses directly in >the C code and not the linker files. It is rare, however, that you have >/functions/ at fixed addresses like this (as I said before, you would >usually have tables of function pointers). But registers for >controlling peripherals are effectively variables, arrays and structs at >fixed addresses - and in the same way you can use casts in C or linker >files (or even assembly files) to achieve the results. Putting this >sort of thing in the C code is typically more readable, less >duplication, easier to get right, easier to understand, and a good deal >more efficient in the generated code (for registers - it will generally >make no difference for a function). > For our processor, the device registers are described by YAML files[*]. The YAML is processed (python) to produce header files and a linker script that is populated with the required physical addresses. Firmware/OS drivers however determine the base aperture address for a device's registers by scanning the ECAM and reading the PCI BAR registers. Even the UARTs have their own PCI configuration space for discovery, which means that only the ECAM base address(es) need be stored in the linker map (or as hardcoded constants). Even when using constants, they should be symbolic constants for maintenance purposes (not 0x20001FF8). [*] These files are processed into RTL (verilog), header files (C and C++), and the processor hardware reference manual (frame).
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-07 06:30 -0700 |
| Message-ID | <88cebbd4-9b17-4d75-a6e0-bc07efcaa81a@googlegroups.com> |
| In reply to | #130311 |
On Monday, May 7, 2018 at 6:23:41 AM UTC-7, Scott Lurndal wrote: > David Brown <david.brown@hesbynett.no> writes: > >On 06/05/18 20:43, Scott Lurndal wrote: > >> David Brown <david.brown@hesbynett.no> writes: > >>> On 04/05/18 19:28, Scott Lurndal wrote: > >>>> supercat@casperkitty.com writes: > >>>>> On Friday, May 4, 2018 at 4:36:58 AM UTC-5, David Brown wrote: > >>>>>> From the viewpoint of the well-disciplined programmer, C #include files > >>>>>> cover the main requirements of modules. There are, as I see it, four > >>>>>> main disadvantages: > >>>>>> > >>>>>> 1. No namespacing. (C++ solves this with "namespace" - a feature C > >>>>>> could easily adopt.) > >>>>>> > >>>>>> 2. No separation of publicly useful data (like function declarations) > >>>>>> and implementation data needed by the compiler (like inline function > >>>>>> definitions, and details of struct contents). > >>>>>> > >>>>>> 3. No pre-compilation (that is a side-effect of the flexibility. It is > >>>>>> of little consequence for most C programming, but slows down very large > >>>>>> project builds and is a real pain for a lot of C++ programming). > >>>>>> > >>>>>> 4. The flexibility means people who don't know how to make C "modules" > >>>>>> get things wrong. > >>>>> > >>>>> 5. No ability to interact with code which isn't processed by the same C > >>>>> implementation, except perhaps by hard-coding or explicitly passing > >>>>> the addresses of every point of interaction (e.g. if one wants to > >>>>> call a routine and knows its address will be stored at 0x20001FF8, > >>>>> one might be able to do something like: > >>>>> > >>>>> void (*myRoutine)(myStructType *) = > >>>>> *(((void**)(myStructType *))0x20001FF8); > >>>>> myRoutine(&myStruct); > >>>> > >>>> Why would anyone, ever, want to do such a silly thing? > >>>> > >>>> That's what linkers are for. > >>>> > >>> > >>> You might want to do something like this to call functions in a ROM or > >>> pre-programmed part of an embedded system from your own code. > >> > >> And for that I'd still be using cross-compilation system that has > >> a linker which allows definition (and association with a > >> specified value, e.g. address) of arbitrary symbols (e.g. binutils ld, > >> arm's ld, Unixware ld, et alia). > >> > > > >Been there, done that - and I prefer to put the addresses directly in > >the C code and not the linker files. It is rare, however, that you have > >/functions/ at fixed addresses like this (as I said before, you would > >usually have tables of function pointers). But registers for > >controlling peripherals are effectively variables, arrays and structs at > >fixed addresses - and in the same way you can use casts in C or linker > >files (or even assembly files) to achieve the results. Putting this > >sort of thing in the C code is typically more readable, less > >duplication, easier to get right, easier to understand, and a good deal > >more efficient in the generated code (for registers - it will generally > >make no difference for a function). > > > > For our processor, the device registers are described by YAML files[*]. The > YAML is processed (python) to produce header files and a linker script > that is populated with the required physical addresses. Firmware/OS > drivers however determine the base aperture address for a device's > registers by scanning the ECAM and reading the PCI BAR registers. Even > the UARTs have their own PCI configuration space for discovery, which > means that only the ECAM base address(es) need be stored in the linker > map (or as hardcoded constants). > > Even when using constants, they should be symbolic constants for maintenance > purposes (not 0x20001FF8). > > [*] These files are processed into RTL (verilog), header files (C and C++), and the processor > hardware reference manual (frame). Any heinously desperate druggie could easily do the same. Do you believe the idiocy Bill 'The Shill' Cunningham is pushing? Bill 'The Shill' Cunningham is being controlled by Doc O'Leary. You never take responsibility for your own words. Quotes that are easily shown in the Google archive. But Bill 'The Shill' Cunningham feels the need to insult the herd. In spite of my own views about Windows, I still continue to use it for clients who've had difficulties with Windows 7. And why the need to edit the DOM via usenet in a server system? Of course, Bill 'The Shill' Cunningham didn't state this as part of his never ending expansion of 'test'. After the latest update I no longer have to issue 'pactl set-sink-volume 0 +5%' every time I login ;) -- My Snoring Solution https://youtu.be/VxLiH-x0aeY http://www.5z8.info/how-to-build-a-bomb_h2o1be_peepshow http://www.5z8.info/horse-slaughter_w8c4en_launchexe Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-07 16:25 +0200 |
| Message-ID | <pcpnkc$t30$1@dont-email.me> |
| In reply to | #130311 |
On 07/05/18 15:23, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 06/05/18 20:43, Scott Lurndal wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> On 04/05/18 19:28, Scott Lurndal wrote:
>>>>> supercat@casperkitty.com writes:
>>>>>> On Friday, May 4, 2018 at 4:36:58 AM UTC-5, David Brown wrote:
>>>>>>> From the viewpoint of the well-disciplined programmer, C #include files
>>>>>>> cover the main requirements of modules. There are, as I see it, four
>>>>>>> main disadvantages:
>>>>>>>
>>>>>>> 1. No namespacing. (C++ solves this with "namespace" - a feature C
>>>>>>> could easily adopt.)
>>>>>>>
>>>>>>> 2. No separation of publicly useful data (like function declarations)
>>>>>>> and implementation data needed by the compiler (like inline function
>>>>>>> definitions, and details of struct contents).
>>>>>>>
>>>>>>> 3. No pre-compilation (that is a side-effect of the flexibility. It is
>>>>>>> of little consequence for most C programming, but slows down very large
>>>>>>> project builds and is a real pain for a lot of C++ programming).
>>>>>>>
>>>>>>> 4. The flexibility means people who don't know how to make C "modules"
>>>>>>> get things wrong.
>>>>>>
>>>>>> 5. No ability to interact with code which isn't processed by the same C
>>>>>> implementation, except perhaps by hard-coding or explicitly passing
>>>>>> the addresses of every point of interaction (e.g. if one wants to
>>>>>> call a routine and knows its address will be stored at 0x20001FF8,
>>>>>> one might be able to do something like:
>>>>>>
>>>>>> void (*myRoutine)(myStructType *) =
>>>>>> *(((void**)(myStructType *))0x20001FF8);
>>>>>> myRoutine(&myStruct);
>>>>>
>>>>> Why would anyone, ever, want to do such a silly thing?
>>>>>
>>>>> That's what linkers are for.
>>>>>
>>>>
>>>> You might want to do something like this to call functions in a ROM or
>>>> pre-programmed part of an embedded system from your own code.
>>>
>>> And for that I'd still be using cross-compilation system that has
>>> a linker which allows definition (and association with a
>>> specified value, e.g. address) of arbitrary symbols (e.g. binutils ld,
>>> arm's ld, Unixware ld, et alia).
>>>
>>
>> Been there, done that - and I prefer to put the addresses directly in
>> the C code and not the linker files. It is rare, however, that you have
>> /functions/ at fixed addresses like this (as I said before, you would
>> usually have tables of function pointers). But registers for
>> controlling peripherals are effectively variables, arrays and structs at
>> fixed addresses - and in the same way you can use casts in C or linker
>> files (or even assembly files) to achieve the results. Putting this
>> sort of thing in the C code is typically more readable, less
>> duplication, easier to get right, easier to understand, and a good deal
>> more efficient in the generated code (for registers - it will generally
>> make no difference for a function).
>>
>
> For our processor, the device registers are described by YAML files[*]. The
> YAML is processed (python) to produce header files and a linker script
> that is populated with the required physical addresses. Firmware/OS
> drivers however determine the base aperture address for a device's
> registers by scanning the ECAM and reading the PCI BAR registers. Even
> the UARTs have their own PCI configuration space for discovery, which
> means that only the ECAM base address(es) need be stored in the linker
> map (or as hardcoded constants).
>
When you have automatic generation of the files from a separate source
like this, it makes less difference where the fixed addresses go once
you reach the C (or C++) level, as maintenance of the linker files or C
files or header files does not matter.
It also sounds like you only have a very few fixed addresses - so you'd
have large struct definitions in headers somewhere and just a few fixed
addresses for the base of the structs. For small microcontrollers, some
header files are written like that - others have lots of individual
addresses. (Usually you get these from the manufacturer, or from a
toolchain supplier, rather than writing them yourself. So to a large
extent, you use what you are given here.)
> Even when using constants, they should be symbolic constants for maintenance
> purposes (not 0x20001FF8).
I partly agree. For maintenance purposes it is important that the
number of "magic numbers" is minimal, that they are written only once,
and that the related numbers are kept in one place. But it does not
actually matter if they are given names or not. If you read the
"PCI_BAR" hardware register only once, in the "initialisePCI" function,
then it may well be as clear to write:
#define readHReg32(addr) (*((volatile const uint32_t *) (addr)))
void initialisePCI(void) {
pciBar = readHReg32(0x20001ff8);
...
}
as to write:
#define PCI_BAR_REG 0x20001ff8
void initialisePCI(void) {
pciBar = readHreg32(PCI_BAR_REG);
...
}
It all depends on the structure of the code, how flexible you need to
be, how portable it should be, what kind of things might change, etc.
Scattering magic numbers around your code is clearly not a good thing -
but neither is filling up code and namespaces with lots of symbols that
are used once or not at all if it does not actually help the code. I am
wary of being /too/ categoric and rigid about the "right" way to
structure this sort of thing - I have seen the "right" way taken to
extremes that leads to less understandable and maintainable code.
>
> [*] These files are processed into RTL (verilog), header files (C and C++), and the processor
> hardware reference manual (frame).
>
That is handy when you have the option. Most of us have to deal with
pre-built microcontrollers and pre-generated headers, and must live with
the format we get from the manufacturer.
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-07 07:32 -0700 |
| Message-ID | <0ca5831d-8e25-4408-a8dd-df614d26fd38@googlegroups.com> |
| In reply to | #130315 |
On Monday, May 7, 2018 at 7:25:27 AM UTC-7, David Brown wrote:
> On 07/05/18 15:23, Scott Lurndal wrote:
> > David Brown <david.brown@hesbynett.no> writes:
> >> On 06/05/18 20:43, Scott Lurndal wrote:
> >>> David Brown <david.brown@hesbynett.no> writes:
> >>>> On 04/05/18 19:28, Scott Lurndal wrote:
> >>>>> supercat@casperkitty.com writes:
> >>>>>> On Friday, May 4, 2018 at 4:36:58 AM UTC-5, David Brown wrote:
> >>>>>>> From the viewpoint of the well-disciplined programmer, C #include files
> >>>>>>> cover the main requirements of modules. There are, as I see it, four
> >>>>>>> main disadvantages:
> >>>>>>>
> >>>>>>> 1. No namespacing. (C++ solves this with "namespace" - a feature C
> >>>>>>> could easily adopt.)
> >>>>>>>
> >>>>>>> 2. No separation of publicly useful data (like function declarations)
> >>>>>>> and implementation data needed by the compiler (like inline function
> >>>>>>> definitions, and details of struct contents).
> >>>>>>>
> >>>>>>> 3. No pre-compilation (that is a side-effect of the flexibility. It is
> >>>>>>> of little consequence for most C programming, but slows down very large
> >>>>>>> project builds and is a real pain for a lot of C++ programming).
> >>>>>>>
> >>>>>>> 4. The flexibility means people who don't know how to make C "modules"
> >>>>>>> get things wrong.
> >>>>>>
> >>>>>> 5. No ability to interact with code which isn't processed by the same C
> >>>>>> implementation, except perhaps by hard-coding or explicitly passing
> >>>>>> the addresses of every point of interaction (e.g. if one wants to
> >>>>>> call a routine and knows its address will be stored at 0x20001FF8,
> >>>>>> one might be able to do something like:
> >>>>>>
> >>>>>> void (*myRoutine)(myStructType *) =
> >>>>>> *(((void**)(myStructType *))0x20001FF8);
> >>>>>> myRoutine(&myStruct);
> >>>>>
> >>>>> Why would anyone, ever, want to do such a silly thing?
> >>>>>
> >>>>> That's what linkers are for.
> >>>>>
> >>>>
> >>>> You might want to do something like this to call functions in a ROM or
> >>>> pre-programmed part of an embedded system from your own code.
> >>>
> >>> And for that I'd still be using cross-compilation system that has
> >>> a linker which allows definition (and association with a
> >>> specified value, e.g. address) of arbitrary symbols (e.g. binutils ld,
> >>> arm's ld, Unixware ld, et alia).
> >>>
> >>
> >> Been there, done that - and I prefer to put the addresses directly in
> >> the C code and not the linker files. It is rare, however, that you have
> >> /functions/ at fixed addresses like this (as I said before, you would
> >> usually have tables of function pointers). But registers for
> >> controlling peripherals are effectively variables, arrays and structs at
> >> fixed addresses - and in the same way you can use casts in C or linker
> >> files (or even assembly files) to achieve the results. Putting this
> >> sort of thing in the C code is typically more readable, less
> >> duplication, easier to get right, easier to understand, and a good deal
> >> more efficient in the generated code (for registers - it will generally
> >> make no difference for a function).
> >>
> >
> > For our processor, the device registers are described by YAML files[*]. The
> > YAML is processed (python) to produce header files and a linker script
> > that is populated with the required physical addresses. Firmware/OS
> > drivers however determine the base aperture address for a device's
> > registers by scanning the ECAM and reading the PCI BAR registers. Even
> > the UARTs have their own PCI configuration space for discovery, which
> > means that only the ECAM base address(es) need be stored in the linker
> > map (or as hardcoded constants).
> >
>
> When you have automatic generation of the files from a separate source
> like this, it makes less difference where the fixed addresses go once
> you reach the C (or C++) level, as maintenance of the linker files or C
> files or header files does not matter.
>
> It also sounds like you only have a very few fixed addresses - so you'd
> have large struct definitions in headers somewhere and just a few fixed
> addresses for the base of the structs. For small microcontrollers, some
> header files are written like that - others have lots of individual
> addresses. (Usually you get these from the manufacturer, or from a
> toolchain supplier, rather than writing them yourself. So to a large
> extent, you use what you are given here.)
>
> > Even when using constants, they should be symbolic constants for maintenance
> > purposes (not 0x20001FF8).
>
> I partly agree. For maintenance purposes it is important that the
> number of "magic numbers" is minimal, that they are written only once,
> and that the related numbers are kept in one place. But it does not
> actually matter if they are given names or not. If you read the
> "PCI_BAR" hardware register only once, in the "initialisePCI" function,
> then it may well be as clear to write:
>
> #define readHReg32(addr) (*((volatile const uint32_t *) (addr)))
>
> void initialisePCI(void) {
> pciBar = readHReg32(0x20001ff8);
> ...
> }
>
> as to write:
>
> #define PCI_BAR_REG 0x20001ff8
>
> void initialisePCI(void) {
> pciBar = readHreg32(PCI_BAR_REG);
> ...
> }
>
> It all depends on the structure of the code, how flexible you need to
> be, how portable it should be, what kind of things might change, etc.
> Scattering magic numbers around your code is clearly not a good thing -
> but neither is filling up code and namespaces with lots of symbols that
> are used once or not at all if it does not actually help the code. I am
> wary of being /too/ categoric and rigid about the "right" way to
> structure this sort of thing - I have seen the "right" way taken to
> extremes that leads to less understandable and maintainable code.
>
> >
> > [*] These files are processed into RTL (verilog), header files (C and C++), and the processor
> > hardware reference manual (frame).
> >
>
> That is handy when you have the option. Most of us have to deal with
> pre-built microcontrollers and pre-generated headers, and must live with
> the format we get from the manufacturer.
Well... like I said, Michael P. would never deny the flooder is David 'The Shill' Brown, who is a demonstrable Swift programmer but I don't know if it could be used to automate this.
When I first posted, I wanted to be fair and open minded. I gave David 'The Shill' Brown more than a wise person generally would. The one talent David 'The Shill' Brown learned well is to attempt to humiliate Michael P. into false confession and if that does not work, drown him out with flooding or subtly change the argument. From the way David 'The Shill' Brown complained - by getting wrong basics of the Slrn and more - he has not handled a graphically complex issue before. If he had he would have understood the requirements of learning to use the && and || operators!
That's what David 'The Shill' Brown does when he gets mad. He quickly creates a new identity, starts a stupid thread so he can claim some lie. Hey it was my left hand... and then David 'The Shill' Brown talks to himself with his right hand. Linux offers the least to the least.
You're nine seconds away from being in everyone's kill filter.
But David 'The Shill' Brown feels the need to belittle the cult-like herd of convenient friends. So be it.
--
Puppy Videos
http://www.5z8.info/gruesome-gunshot-wounds_t5z0au_cockdock.gif
Jonas Eklundh
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-04 09:09 -0700 |
| Message-ID | <lnk1sjcshg.fsf@kst-u.example.com> |
| In reply to | #130124 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> (An alternative to header guards is to use the #import instead of
> #include. This is non-standard, but supported by many compilers.
> Putting "#pragma once" in a header is similarly non-standard by often
> supported. Header guards are the simplest, standard, and most used method.)
[...]
From the GNU C preprocessor manual:
CPP supports a variant of '#include' called '#import' which
includes a file, but does so at most once. If you use '#import'
instead of '#include', then you don't need the conditionals
inside the header file to prevent multiple inclusion of
the contents. '#import' is standard in Objective-C, but is
considered a deprecated extension in C and C++.
'#import' is not a well designed feature. It requires the users
of a header file to know that it should only be included once.
It is much better for the header file's implementor to write
the file so that users don't need to know this. Using a wrapper
'#ifndef' accomplishes this goal.
In the present implementation, a single use of '#import' will
prevent the file from ever being read again, by either '#import'
or '#include'. You should not rely on this; do not use both
'#import' and '#include' to refer to the same header file.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
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"
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-04 18:12 +0100 |
| Message-ID | <vw0HC.117791$GV1.73418@fx32.am4> |
| In reply to | #130124 |
On 04/05/2018 10:36, David Brown wrote: > On 03/05/18 15:36, bartc wrote: >> In other words, this is a more grown-up way of doing this stuff. You >> really wouldn't want to go back to headers. >> > > I agree that a good module system has advantages over includes. I don't > agree that includes are anything like as problematic as you make out - > you just need to know how to use them properly and have a bit of > self-discipline. I didn't have a module system 25 years ago, but the crude scheme I used then I think was still better than C's #includes: * A normal module had no import or include statements (not for this purpose anyway; just for general purpose code inclusion) * When you compiled a module, you also gave it the name of ONE header file. Although this could contain 'include' to combine header data from several files. * This one header had its own scope. (But it did not create a private name space. I think module-scope vars/functions with the same names would shadow the ones in the header.) * The header file could contain initialised data (I'm not sure about function definitions). It would also contain declarations for global functions defined in modules. * The header file formed a module in its own right and needed to compiled and linked in as part of the program. Thus the variables defined in it belonged to the header. * Usually, with an IDE and project file which listed modules, headers and libraries, the IDE would create the project header file which was shared by all the modules. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-06 14:07 +0100 |
| Subject | Global variables |
| Message-ID | <M6DHC.72415$Ze.56654@fx39.am4> |
| In reply to | #130124 |
[Was: The case AGAINST C]
On 04/05/2018 10:36, David Brown wrote:
> On 03/05/18 15:36, bartc wrote:
>> They couldn't be more different. [include and import]
>
> Yes, they /could/ be more different - because the way #include is mostly
> used is very similar to a more structured "module" concept. Typically,
> languages that have a module system have a lot more structure and
> restrictions than you have in include files. In C, the include system
> is very flexible - you have to enforce a structure and modularisation
> yourself.
My first implementation of modules had one big disadvantage: it required
a strictly hierarchical module structure.
That wasn't always easy to achieve, but a workaround was to write
explicit declarations for global entities that didn't fit into the scheme.
Exactly as has to be done manually with C header files. Except that with
my scheme, this was only needed for 1% of such declarations; 99% of them
are automatic and require no effort whatsoever.
(And with my new scheme which doesn't enforce a module hierarchy, they
are 100% automatic.)
This has its advantages and disadvantages - sometimes the
> flexibility is great, but it also means you have to understand how to
> use include files properly for correct and modular coding.
> Unfortunately, many C programmers (yourself including) don't understand
> the details here.
You think so? I must know something about it to have created several
such systems each successively better than the stone age methods used in C.
> 4. The flexibility means people who don't know how to make C "modules"
> get things wrong.
That must be a lot of people then. In my case, I'm so used to the
effortless way my language does it that I forget how easy it is to get
it wrong in C.
Here's a beautiful example of getting it wrong, a simple 5-module
1-header project:
http://kociemba.org/downloads/optiqtmSrc.zip # (rubik's cube solver)
The header declares lots of global variables and tables, without using
extern and without them being also declared in one of the C files, which
has the effect that they are seen as defined, exported variables from
each C file that uses them.
My linker complained about multiple definitions of variables.
But no other C compiler's linker said anything at all (apart from one
that crashed, I believe for other reasons).
These clashes could very easily have been of separately declared,
incompatible objects, yet no error is notified or even a warning.
No doubt gcc/gcc's linker could have its arm twisted to do so, but the
point is that hasn't happened here as the error is there. Compilers MUST
report such fundamental problems.
(Funny how a simple tool is more adept at this stuff than an elaborate one.)
--------------
There was another source error in that project, which was the widespread
use of () parameter list rather than (void). The danger here is that
arguments to those functions are unchecked. If the program might not
crash, it shows a misunderstanding of what a function does.
Again, only my compiler said anything (in default mode). I could used a
compatibility switch, but I decided to fix the source code.
Maybe more people should do that.
(This project did have a very simple makefile, but it was hardly needed:
just compile the 5 files and link them.)
> C #include files can be used for other more flexible uses too, which
> modules cannot.
You mean general text include?
Having modules doesn't preclude the use of a file include feature. But
it would be confusing if C had both as you'd then have modules, #include
used instead of modules, and #include used for other purposes.
>> Nothing stops you including the same .h header file 20 times, and so
>> many header files have messy #ifdef guards to prevent this.
>
> The #ifdef guards are cheap, simple, and very familiar to all C
> programmers. A "proper" C module concept would not need them, but they
> are not a hardship.
#ifdef guards still require that the header file is rescanned token by
token to get to the matching #endif. Unless compilers jump through hoops
to avoid that.
> Look, it is actually fairly simple. Not as simple as it could have
> been, perhaps, but not hard.
>
> "extern int abc;" /declares/ "abc" to be an integer with external
> (global) linkage - but it does not define it, allocate space for it, or
> provide any initialisation for it.
>
> "int abc;" is a "tentative definition" - if no full definition
> ("external definition" in the C standards) is found by the end of that
> translation unit, then it is treated as if it were a full definition
> "int abc = 0;".
>
> "int abc = 0;" or other initialisation is always a full definition.
You say it's simple but then go into rather a long explanation.
A lot of source code doesn't do this because it's not enforced.
Module-scope variables very often are not initialised. 'extern' is often
not used. So projects are full of tentative which are not defined
anywhere, but no errors are raised.
Here's how it works in one of my current languages; names declared at
module scope:
int abc # defined variable, not exported
global int def # defined variable, exported
There is no need for an 'extern' version, as 'import' takes care of
those details.
THAT is simple.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-06 20:03 +0200 |
| Subject | Re: Global variables |
| Message-ID | <pcng2e$i93$1@dont-email.me> |
| In reply to | #130257 |
On 06/05/18 15:07, bartc wrote:
> [Was: The case AGAINST C]
>
> On 04/05/2018 10:36, David Brown wrote:
>> On 03/05/18 15:36, bartc wrote:
>
>>> They couldn't be more different. [include and import]
>>
>> Yes, they /could/ be more different - because the way #include is mostly
>> used is very similar to a more structured "module" concept. Typically,
>> languages that have a module system have a lot more structure and
>> restrictions than you have in include files. In C, the include system
>> is very flexible - you have to enforce a structure and modularisation
>> yourself.
>
> My first implementation of modules had one big disadvantage: it required
> a strictly hierarchical module structure.
>
> That wasn't always easy to achieve, but a workaround was to write
> explicit declarations for global entities that didn't fit into the scheme.
>
> Exactly as has to be done manually with C header files. Except that with
> my scheme, this was only needed for 1% of such declarations; 99% of them
> are automatic and require no effort whatsoever.
>
> (And with my new scheme which doesn't enforce a module hierarchy, they
> are 100% automatic.)
>
> This has its advantages and disadvantages - sometimes the
>> flexibility is great, but it also means you have to understand how to
>> use include files properly for correct and modular coding.
>> Unfortunately, many C programmers (yourself including) don't understand
>> the details here.
>
> You think so? I must know something about it to have created several
> such systems each successively better than the stone age methods used in C.
>
>> 4. The flexibility means people who don't know how to make C "modules"
>> get things wrong.
>
> That must be a lot of people then. In my case, I'm so used to the
> effortless way my language does it that I forget how easy it is to get
> it wrong in C.
>
> Here's a beautiful example of getting it wrong, a simple 5-module
> 1-header project:
>
> http://kociemba.org/downloads/optiqtmSrc.zip # (rubik's cube solver)
>
> The header declares lots of global variables and tables, without using
> extern and without them being also declared in one of the C files, which
> has the effect that they are seen as defined, exported variables from
> each C file that uses them.
>
> My linker complained about multiple definitions of variables.
>
> But no other C compiler's linker said anything at all (apart from one
> that crashed, I believe for other reasons).
>
> These clashes could very easily have been of separately declared,
> incompatible objects, yet no error is notified or even a warning.
>
> No doubt gcc/gcc's linker could have its arm twisted to do so, but the
> point is that hasn't happened here as the error is there. Compilers MUST
> report such fundamental problems.
No, neither compilers nor linkers /have/ to report on such problems.
You seem to be getting your knickers in a twist here about something
that I /agree/ is a bad feature, something that I /agree/ should never
be used, and that I /agree/ should never have been allowed in the first
place.
The C standards don't have anything to say about having multiple
definitions (identical or otherwise) of a variable in a program. Early
pre-standard C toolchains supported it, and code was written that used
it - so later toolchains kept it for compatibility. I think that was a
mistake.
It is not hard to find examples of code using such multiple definitions.
That does not mean that it is something everyone does, and it
certainly does not mean it is a problem with the language or the tools -
merely that some programmers don't know how to use the language and
tools to write well-structured code. I fully agree that such bad
structure would not be in published code if tools did not commonly
support it or commonly diagnosed it. Having the language had explicitly
ban it is not enough - C++ /does/ have a rule against multiple
definitions of objects, but people manage to break that rule in the same
way.
>
> (Funny how a simple tool is more adept at this stuff than an elaborate
> one.)
Not really, no. A car is a good deal harder to learn to control than a
tricycle. Simple does not mean better (nor does it mean worse) - it
just means simple.
>
> --------------
>
> There was another source error in that project, which was the widespread
> use of () parameter list rather than (void). The danger here is that
> arguments to those functions are unchecked. If the program might not
> crash, it shows a misunderstanding of what a function does.
Another mistake from the programmer, not the language. (But as already
noted by Keith and myself, and probably agreed by many others, it would
be better if common tools gave a warning on such legal but obsolete and
dangerous constructs.)
>
> Again, only my compiler said anything (in default mode). I could used a
> compatibility switch, but I decided to fix the source code.
>
> Maybe more people should do that.
>
> (This project did have a very simple makefile, but it was hardly needed:
> just compile the 5 files and link them.)
>
>> C #include files can be used for other more flexible uses too, which
>> modules cannot.
>
> You mean general text include?
>
> Having modules doesn't preclude the use of a file include feature. But
> it would be confusing if C had both as you'd then have modules, #include
> used instead of modules, and #include used for other purposes.
It is relatively rare for #include to be used for general source
inclusion, but it does happen. One example I have seen is to divide a
program into parts but then to compile them together as one translation
unit for efficiency reasons. I have also seen (and used myself) files
that are generated externally, such as to define const arrays of data
that you want directly linked into a program. Then you might have
something like:
// In file pics.c
const uint8_t smiley_face_picture_data[] = {
#include "pics/smile_face.inc"
};
const uint8_t sad_face_picture_data[] = {
#include "pics/sad_face.inc"
};
The ".inc" files are generated by something else, like a Python script
called automatically from the project's Makefile (yes, make does a great
deal more than just call the compiler), and they consist of just
comma-separated lists of data values.
I have also seen include files used for portability, such as:
// In file xxx.c
#include "port/start_packed_struct.h"
packed_struct {
char c;
int i;
};
#include "port/end_packed_struct.h"
For one compiler, you might have:
// port/start_packed_struct.h
struct __attribute__((__packed__))
// port/end_packed_struct.h
For another, you might have:
// port/start_packed_struct.h
#pragma push
#pragma pack 1
struct
// port/end_packed_struct.h
#pragma pop
That is just three cases where flexible include files can be very
helpful - but where they don't fit the common model of a "header file"
with extern declarations and related declarations and definitions. And
none of these would work with a more rigid (but safer) module system.
>
>>> Nothing stops you including the same .h header file 20 times, and so
>>> many header files have messy #ifdef guards to prevent this.
>>
>> The #ifdef guards are cheap, simple, and very familiar to all C
>> programmers. A "proper" C module concept would not need them, but they
>> are not a hardship.
>
> #ifdef guards still require that the header file is rescanned token by
> token to get to the matching #endif. Unless compilers jump through hoops
> to avoid that.
Compilers are very good at handling these efficiently. The time taken
by gcc and other serious compilers to skip over duplicate headers is
absolutely negligible. I am sure the developers of these tools have
worked hard to make them so - but the effort required by compiler
developers has never been a criteria for features of C. (This is
different from some languages, such as Pascal, where ease of
implementation was very important in the language design.)
>
>> Look, it is actually fairly simple. Not as simple as it could have
>> been, perhaps, but not hard.
>>
>> "extern int abc;" /declares/ "abc" to be an integer with external
>> (global) linkage - but it does not define it, allocate space for it, or
>> provide any initialisation for it.
>>
>> "int abc;" is a "tentative definition" - if no full definition
>> ("external definition" in the C standards) is found by the end of that
>> translation unit, then it is treated as if it were a full definition
>> "int abc = 0;".
>>
>> "int abc = 0;" or other initialisation is always a full definition.
>
> You say it's simple but then go into rather a long explanation.
It /is/ simple - but I gave an explanation of how and why it works, with
all the rules, to help teach you. Perhaps naïvely I thought you could
learn from it and then write correct code afterwards, rather than merely
using it as another example of something you don't understand about C
and can therefore be used to claim C is "broken".
>
> A lot of source code doesn't do this because it's not enforced.
>
> Module-scope variables very often are not initialised.
Often they are initialised, often they are not. I could not guess at
the proportions.
> 'extern' is often
> not used.
"extern" is used all the time in declarations and in headers. Code that
has variable declarations in headers should use "extern" in almost all
cases (occasionally "static" is used instead) - if the code does not
have "extern" or "static" on something that should be a non-defining
object declaration, the code is bad. ("extern" is entirely optional for
non-defining function declarations - I like to use it, but many people
do not. We are concerned with objects here.)
> So projects are full of tentative which are not defined
> anywhere, but no errors are raised.
It is fine to have tentative definitions - they become "real"
definitions (or "external definition") at the end of the translation
unit. There is only a problem if more than one translation unit has
definitions for the same identifier in the same program - something that
happens easily if you have tentative definitions in a header file.
>
> Here's how it works in one of my current languages; names declared at
> module scope:
>
> int abc # defined variable, not exported
>
> global int def # defined variable, exported
>
> There is no need for an 'extern' version, as 'import' takes care of
> those details.
I would not want that. I prefer to have the interface for a module -
the exported part - declared independently. Sure, it means a little
duplication - but nothing difficult, and it will all be checked by the
compiler. I greatly prefer C's methods (with appropriately structured
and constrained header files, and aided by good tools), or Modula 2
(where interface files are independent of implementation files). Pascal
(where these are two sections within the same file) is okay. Python's
method is very poor - /everything/ is exported, and available from other
files via a module import statement - unless you use ugly underscores
everywhere. Your method is a little better than Python's, as you need
an explicit "global" for exporting symbols, but it still means they are
scattered around the implementation file rather than in a dedicated
interface file containing only the API and documentation.
> > THAT is simple.
>
That is one simple way to do it. C has a different simple way to do it.
Other languages have other ways to do it - usually simple, but perhaps
with different rules.
There is nothing difficult or confusing about C's method. I think it is
sub-optimal - I would prefer a better choice of default qualifiers.
(I'd prefer "static const" by default, and require an explicit "var" for
variable data and an explicit "extern" - or "global" if you prefer - for
exported data.)
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2018-05-06 15:21 -0400 |
| Subject | Re: Global variables |
| Message-ID | <pcnkjb$i85$1@dont-email.me> |
| In reply to | #130261 |
David Brown wrote:
[snip]
> The C standards don't have anything to say about having multiple
> definitions (identical or otherwise) of a variable in a program.
6.7 Declarations
3 If an identifier has no linkage, there shall be no more than one
================
declaration of the identifier (in a declarator or type specifier) with
the same scope and in the same name space, ...
...
6.9 External definitions
3 There shall be no more than one external definition for each identifier
================
declared with internal linkage in a translation unit. Moreover, if an
identifier declared with internal linkage is used in an expression
(other than as a part of the operand of a sizeof or _Alignof operator
whose result is an integer constant), there shall be exactly one
===========
external definition for the identifier in the translation unit.
...
6.9.2 External object definitions
2 A declaration of an identifier for an object that has file scope
without an initializer, and without a storage-class specifier or with
the storage-class specifier static, constitutes a tentative definition.
If a translation unit contains one or more tentative definitions for an
=================================
identifier, and the translation unit contains no external definition
for that identifier, then the behavior is exactly as if the translation
unit contains a file scope declaration of that identifier, with the
composite type as of the end of the translation unit, with an
initializer equal to 0.
> Early
> pre-standard C toolchains supported it, and code was written that used
> it - so later toolchains kept it for compatibility. I think that was a
> mistake.
>
> It is not hard to find examples of code using such multiple definitions.
> That does not mean that it is something everyone does, and it
> certainly does not mean it is a problem with the language or the tools -
> merely that some programmers don't know how to use the language and
> tools to write well-structured code. I fully agree that such bad
> structure would not be in published code if tools did not commonly
> support it or commonly diagnosed it. Having the language had explicitly
> ban it is not enough - C++ /does/ have a rule against multiple
> definitions of objects, but people manage to break that rule in the same
> way.
>
>
>>
>> (Funny how a simple tool is more adept at this stuff than an elaborate
>> one.)
>
> Not really, no. A car is a good deal harder to learn to control than a
> tricycle. Simple does not mean better (nor does it mean worse) - it
> just means simple.
>
>>
>> --------------
>>
>> There was another source error in that project, which was the widespread
>> use of () parameter list rather than (void). The danger here is that
>> arguments to those functions are unchecked. If the program might not
>> crash, it shows a misunderstanding of what a function does.
>
> Another mistake from the programmer, not the language. (But as already
> noted by Keith and myself, and probably agreed by many others, it would
> be better if common tools gave a warning on such legal but obsolete and
> dangerous constructs.)
>
>>
>> Again, only my compiler said anything (in default mode). I could used a
>> compatibility switch, but I decided to fix the source code.
>>
>> Maybe more people should do that.
>>
>> (This project did have a very simple makefile, but it was hardly needed:
>> just compile the 5 files and link them.)
>>
>>> C #include files can be used for other more flexible uses too, which
>>> modules cannot.
>>
>> You mean general text include?
>>
>> Having modules doesn't preclude the use of a file include feature. But
>> it would be confusing if C had both as you'd then have modules, #include
>> used instead of modules, and #include used for other purposes.
>
> It is relatively rare for #include to be used for general source
> inclusion, but it does happen. One example I have seen is to divide a
> program into parts but then to compile them together as one translation
> unit for efficiency reasons. I have also seen (and used myself) files
> that are generated externally, such as to define const arrays of data
> that you want directly linked into a program. Then you might have
> something like:
>
> // In file pics.c
> const uint8_t smiley_face_picture_data[] = {
> #include "pics/smile_face.inc"
> };
>
> const uint8_t sad_face_picture_data[] = {
> #include "pics/sad_face.inc"
> };
>
> The ".inc" files are generated by something else, like a Python script
> called automatically from the project's Makefile (yes, make does a great
> deal more than just call the compiler), and they consist of just
> comma-separated lists of data values.
>
>
> I have also seen include files used for portability, such as:
>
> // In file xxx.c
>
> #include "port/start_packed_struct.h"
> packed_struct {
> char c;
> int i;
> };
> #include "port/end_packed_struct.h"
>
>
> For one compiler, you might have:
>
> // port/start_packed_struct.h
> struct __attribute__((__packed__))
>
> // port/end_packed_struct.h
>
>
> For another, you might have:
>
> // port/start_packed_struct.h
> #pragma push
> #pragma pack 1
> struct
>
> // port/end_packed_struct.h
> #pragma pop
>
>
>
> That is just three cases where flexible include files can be very
> helpful - but where they don't fit the common model of a "header file"
> with extern declarations and related declarations and definitions. And
> none of these would work with a more rigid (but safer) module system.
>
>
>>
>>>> Nothing stops you including the same .h header file 20 times, and so
>>>> many header files have messy #ifdef guards to prevent this.
>>>
>>> The #ifdef guards are cheap, simple, and very familiar to all C
>>> programmers. A "proper" C module concept would not need them, but they
>>> are not a hardship.
>>
>> #ifdef guards still require that the header file is rescanned token by
>> token to get to the matching #endif. Unless compilers jump through hoops
>> to avoid that.
>
> Compilers are very good at handling these efficiently. The time taken
> by gcc and other serious compilers to skip over duplicate headers is
> absolutely negligible. I am sure the developers of these tools have
> worked hard to make them so - but the effort required by compiler
> developers has never been a criteria for features of C. (This is
> different from some languages, such as Pascal, where ease of
> implementation was very important in the language design.)
>
>>
>>> Look, it is actually fairly simple. Not as simple as it could have
>>> been, perhaps, but not hard.
>>>
>>> "extern int abc;" /declares/ "abc" to be an integer with external
>>> (global) linkage - but it does not define it, allocate space for it, or
>>> provide any initialisation for it.
>>>
>>> "int abc;" is a "tentative definition" - if no full definition
>>> ("external definition" in the C standards) is found by the end of that
>>> translation unit, then it is treated as if it were a full definition
>>> "int abc = 0;".
>>>
>>> "int abc = 0;" or other initialisation is always a full definition.
>>
>> You say it's simple but then go into rather a long explanation.
>
> It /is/ simple - but I gave an explanation of how and why it works, with
> all the rules, to help teach you. Perhaps naïvely I thought you could
> learn from it and then write correct code afterwards, rather than merely
> using it as another example of something you don't understand about C
> and can therefore be used to claim C is "broken".
>
>>
>> A lot of source code doesn't do this because it's not enforced.
>>
>> Module-scope variables very often are not initialised.
>
> Often they are initialised, often they are not. I could not guess at
> the proportions.
>
>> 'extern' is often
>> not used.
>
> "extern" is used all the time in declarations and in headers. Code that
> has variable declarations in headers should use "extern" in almost all
> cases (occasionally "static" is used instead) - if the code does not
> have "extern" or "static" on something that should be a non-defining
> object declaration, the code is bad. ("extern" is entirely optional for
> non-defining function declarations - I like to use it, but many people
> do not. We are concerned with objects here.)
>
>> So projects are full of tentative which are not defined
>> anywhere, but no errors are raised.
>
> It is fine to have tentative definitions - they become "real"
> definitions (or "external definition") at the end of the translation
> unit. There is only a problem if more than one translation unit has
> definitions for the same identifier in the same program - something that
> happens easily if you have tentative definitions in a header file.
>
>
>>
>> Here's how it works in one of my current languages; names declared at
>> module scope:
>>
>> int abc # defined variable, not exported
>>
>> global int def # defined variable, exported
>>
>> There is no need for an 'extern' version, as 'import' takes care of
>> those details.
>
> I would not want that. I prefer to have the interface for a module -
> the exported part - declared independently. Sure, it means a little
> duplication - but nothing difficult, and it will all be checked by the
> compiler. I greatly prefer C's methods (with appropriately structured
> and constrained header files, and aided by good tools), or Modula 2
> (where interface files are independent of implementation files). Pascal
> (where these are two sections within the same file) is okay. Python's
> method is very poor - /everything/ is exported, and available from other
> files via a module import statement - unless you use ugly underscores
> everywhere. Your method is a little better than Python's, as you need
> an explicit "global" for exporting symbols, but it still means they are
> scattered around the implementation file rather than in a dedicated
> interface file containing only the API and documentation.
>
>> > THAT is simple.
>>
>
> That is one simple way to do it. C has a different simple way to do it.
> Other languages have other ways to do it - usually simple, but perhaps
> with different rules.
>
> There is nothing difficult or confusing about C's method. I think it is
> sub-optimal - I would prefer a better choice of default qualifiers.
> (I'd prefer "static const" by default, and require an explicit "var" for
> variable data and an explicit "extern" - or "global" if you prefer - for
> exported data.)
--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-06 13:07 -0700 |
| Subject | Re: Global variables |
| Message-ID | <lnmuxcblai.fsf@kst-u.example.com> |
| In reply to | #130268 |
Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
> David Brown wrote:
> [snip]
>> The C standards don't have anything to say about having multiple
>> definitions (identical or otherwise) of a variable in a program.
>
> 6.7 Declarations
> 3 If an identifier has no linkage, there shall be no more than one
> ================
> declaration of the identifier (in a declarator or type specifier) with
> the same scope and in the same name space, ...
[27 lines deleted]
>> Early
[224 lines deleted]
>> exported data.)
Lew (and everyone else), please snip quoted text that you're not
replying to. The end of your article consisted of about 226 lines
of quoted text from the parent article that you didn't comment on.
I had to skim through all of it to determine that there was no
new material.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
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"
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2018-05-06 16:13 -0400 |
| Subject | Re: Global variables |
| Message-ID | <pcnnlu$6fh$1@dont-email.me> |
| In reply to | #130271 |
Keith Thompson wrote: [snip] > Lew (and everyone else), please snip quoted text that you're not > replying to. The end of your article consisted of about 226 lines > of quoted text from the parent article that you didn't comment on. > I had to skim through all of it to determine that there was no > new material. My apologies, Keith I had meant to snip the tail of that post, but in my haste, forgot. -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-06 23:39 +0200 |
| Subject | Re: Global variables |
| Message-ID | <pcnsmp$94e$1@dont-email.me> |
| In reply to | #130268 |
On 06/05/18 21:21, Lew Pitcher wrote: > David Brown wrote: > [snip] >> The C standards don't have anything to say about having multiple >> definitions (identical or otherwise) of a variable in a program. I was not explicit in this, but we were talking about having more than one definition of a variable with external linkage, with one definition in each translation unit. (That's what you get if you have a header file with "int x;" and include it from several C files that are then linked together.) The paragraphs you quote are all about multiple definitions within the same translation unit.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2018-05-06 17:50 -0400 |
| Subject | Re: Global variables |
| Message-ID | <lMKHC.29474$RI2.6333@fx26.iad> |
| In reply to | #130281 |
On 5/6/18 5:39 PM, David Brown wrote: > On 06/05/18 21:21, Lew Pitcher wrote: >> David Brown wrote: >> [snip] >>> The C standards don't have anything to say about having multiple >>> definitions (identical or otherwise) of a variable in a program. > > I was not explicit in this, but we were talking about having more than > one definition of a variable with external linkage, with one definition > in each translation unit. (That's what you get if you have a header > file with "int x;" and include it from several C files that are then > linked together.) The paragraphs you quote are all about multiple > definitions within the same translation unit. > One item in J.2 is An identifier with external linkage is used, but in the program there does not exist exactly one external definition for the identifier, or the identifier is not used and there exist multiple external definitions for the identifier (6.9). While Appendex J is Informative, it indicates that the implication that the lack of a explicit definition of how to handle multiple definitions (not exactly one definition) of an object with external linkage falls to the standards definition of undefined behavior.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-06 23:57 +0200 |
| Subject | Re: Global variables |
| Message-ID | <pcntoh$fbd$1@dont-email.me> |
| In reply to | #130282 |
On 06/05/18 23:50, Richard Damon wrote: > On 5/6/18 5:39 PM, David Brown wrote: >> On 06/05/18 21:21, Lew Pitcher wrote: >>> David Brown wrote: >>> [snip] >>>> The C standards don't have anything to say about having multiple >>>> definitions (identical or otherwise) of a variable in a program. >> >> I was not explicit in this, but we were talking about having more than >> one definition of a variable with external linkage, with one definition >> in each translation unit. (That's what you get if you have a header >> file with "int x;" and include it from several C files that are then >> linked together.) The paragraphs you quote are all about multiple >> definitions within the same translation unit. >> > > One item in J.2 is > An identifier with external linkage is used, but in the program there > does not exist exactly one external definition for the identifier, or > the identifier is not used and there exist multiple external definitions > for the identifier (6.9). > Interesting - this does not correspond directly to anything in 6.9 (as the nominative text does not mention the whole program). > While Appendex J is Informative, it indicates that the implication that > the lack of a explicit definition of how to handle multiple definitions > (not exactly one definition) of an object with external linkage falls to > the standards definition of undefined behavior. > Even if it were not mentioned explicitly in J.2, I /think/ there is enough in the main text to say that the behaviour of a program with multiple definitions of the same object would be undefined behaviour due to the omission of a definition for it. Linkers and C implementations can, of course, give a definition to the behaviour above and beyond the C standard here - and many do so.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2018-05-06 19:56 -0400 |
| Subject | Re: Global variables |
| Message-ID | <wCMHC.149313$RM2.140840@fx05.iad> |
| In reply to | #130284 |
On 5/6/18 5:57 PM, David Brown wrote: > On 06/05/18 23:50, Richard Damon wrote: >> On 5/6/18 5:39 PM, David Brown wrote: >>> On 06/05/18 21:21, Lew Pitcher wrote: >>>> David Brown wrote: >>>> [snip] >>>>> The C standards don't have anything to say about having multiple >>>>> definitions (identical or otherwise) of a variable in a program. >>> >>> I was not explicit in this, but we were talking about having more than >>> one definition of a variable with external linkage, with one definition >>> in each translation unit. (That's what you get if you have a header >>> file with "int x;" and include it from several C files that are then >>> linked together.) The paragraphs you quote are all about multiple >>> definitions within the same translation unit. >>> >> >> One item in J.2 is >> An identifier with external linkage is used, but in the program there >> does not exist exactly one external definition for the identifier, or >> the identifier is not used and there exist multiple external definitions >> for the identifier (6.9). >> > > Interesting - this does not correspond directly to anything in 6.9 (as > the nominative text does not mention the whole program). Most of 6.9 is defining conditions that the implementation is required to diagnose. Most 'whole program' issues are not required to be diagnosed. > >> While Appendex J is Informative, it indicates that the implication that >> the lack of a explicit definition of how to handle multiple definitions >> (not exactly one definition) of an object with external linkage falls to >> the standards definition of undefined behavior. >> > > Even if it were not mentioned explicitly in J.2, I /think/ there is > enough in the main text to say that the behaviour of a program with > multiple definitions of the same object would be undefined behaviour due > to the omission of a definition for it. > > Linkers and C implementations can, of course, give a definition to the > behaviour above and beyond the C standard here - and many do so. > Yes, the normative description is implicitly of a single definition, so the lack of any other mention makes it fall as undefined by omission. Section J was added, in my opinion, to allow many of the things which were intentionally not defined to be mentioned to allow someone to be satisfied at seeing it mentioned. It is made non-normative as it technically isn't needed as if something hasn't been defined, the standard doesn't require this to be explicitly stated, and by being non-normative they don't need to be as careful about conflicts if some edge case IS defined elsewhere in the Standard.
[toc] | [prev] | [next] | [standalone]
Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web