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 1 of 11 [1] 2 3 … 11 Next page →
| From | Real Troll <real.troll@trolls.com> |
|---|---|
| Date | 2018-04-30 02:10 +0000 |
| Subject | The case AGAINST C |
| Message-ID | <pc5tpv$1o5f$1@gioia.aioe.org> |
Dr P.J Moylan has written a paper to argue a case against using C. <ftp://ftp.pmoylan.org/papers/78.The_Case_Against_C.pdf> He argues that: > The misplaced loyalty to C is, in my > opinion, just as serious a problem among > professionals as the BASIC problem is among > amateurs.
[toc] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2018-04-30 03:14 +0000 |
| Message-ID | <pc61nh$leh$1@reader1.panix.com> |
| In reply to | #129945 |
In article <pc5tpv$1o5f$1@gioia.aioe.org>, Real Troll <real.troll@trolls.com> wrote: >Dr P.J Moylan has written a paper to argue a case against using C. > ><ftp://ftp.pmoylan.org/papers/78.The_Case_Against_C.pdf> > >He argues that: > >> The misplaced loyalty to C is, in my >> opinion, just as serious a problem among >> professionals as the BASIC problem is among >> amateurs. That paper is from 1992? He raises some valid points, and I would suggest that C's best response is more in the domain of convention and tooling rather than language diktat. E.g., his proposed hazard of #include is usually addressed through externally-specified dependencies feeding a build system, such as a Makefile or something specifying a compile-time dependency that causes recompilation of a translation units if one of its dependencies is changed. Indeed, I don't believe there's any prohibition against a compiler doing this in principle, even if it may be rather complicated in the sense that one must take care to honor #include's semantics with respect to the surrounding lexical environment, etc (consider X macros and the like). Overall, he raises some valid points, but I think he overstates them. The comparison to Modula-2 obviously dates the paper. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2018-04-30 05:48 -0700 |
| Message-ID | <kfnpo2gkgg7.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #129946 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: > In article <pc5tpv$1o5f$1@gioia.aioe.org>, > Real Troll <real.troll@trolls.com> wrote: > >> Dr P.J Moylan has written a paper to argue a case against using C. >> >> <ftp://ftp.pmoylan.org/papers/78.The_Case_Against_C.pdf> >> >> He argues that: >> >>> The misplaced loyalty to C is, in my >>> opinion, just as serious a problem among >>> professionals as the BASIC problem is among >>> amateurs. > > That paper is from 1992? He raises some valid points, and I > would suggest that C's best response is more in the domain of > convention and tooling rather than language diktat. E.g., > his proposed hazard of #include is usually addressed through > externally-specified dependencies feeding a build system, such > as a Makefile or something specifying a compile-time dependency > that causes recompilation of a translation units if one of its > dependencies is changed. [...] > > Overall, he raises some valid points, but I think he overstates > them. [...] A calm, rational, sensible assessment. And obviously correct, since it agrees with my own. :)
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-30 14:58 +0100 |
| Message-ID | <eiFFC.77030$I77.14295@fx44.am4> |
| In reply to | #129946 |
On 30/04/2018 04:14, Dan Cross wrote: > In article <pc5tpv$1o5f$1@gioia.aioe.org>, > Real Troll <real.troll@trolls.com> wrote: >> Dr P.J Moylan has written a paper to argue a case against using C. >> >> <ftp://ftp.pmoylan.org/papers/78.The_Case_Against_C.pdf> >> >> He argues that: >> >>> The misplaced loyalty to C is, in my >>> opinion, just as serious a problem among >>> professionals as the BASIC problem is among >>> amateurs. > > That paper is from 1992? He raises some valid points, and I > would suggest that C's best response is more in the domain of > convention and tooling rather than language diktat. E.g., > his proposed hazard of #include is usually addressed through > externally-specified dependencies feeding a build system, such > as a Makefile or something specifying a compile-time dependency > that causes recompilation of a translation units if one of its > dependencies is changed. And this is how it all starts. This is a bit like not bothering with standards of spelling and grammar amongst school kids because they can just use spell-checkers and other tools. (And which also don't work if outside that environment, for example writing by hand onto paper.) Now, fixing the language to that extent might not have been possible for various reasons (maybe there was were no body to do that, with the standards committee's job being to harmonise various minor extensions rather than radically modernise the language). Except that C still allows all the work done by those tools to be undone, for example by allowing () parameter lists, so that are argument checking goes out the window. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Davs <johndemeert0@gmail.com> |
|---|---|
| Date | 2018-05-07 04:18 -0700 |
| Message-ID | <f30e37cb-7bb4-4ce2-8df1-3f6e7da5004b@googlegroups.com> |
| In reply to | #129946 |
On 06/05/18 21:16, bartc wrote: > On 06/05/2018 19:19, Lew Pitcher wrote: > >>> My linker complained about multiple definitions of variables. >> >> From the Standard C standpoint, wouldn't that make your linker "wrong"? > > > >> Historically, linkage editors assign the same storage location to >> multiple >> storage definitions that have both the same name and size, and are >> uninitialized. uninitialized variable is pushed thru the stack and the value is carried with the code initialized variable is mapped in memory and are access to that memory.
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-07 05:26 -0700 |
| Message-ID | <b837d94d-28fa-4383-a8c1-3d82f59b6475@googlegroups.com> |
| In reply to | #130308 |
On Monday, May 7, 2018 at 4:18:34 AM UTC-7, Davs wrote: > On 06/05/18 21:16, bartc wrote: > > On 06/05/2018 19:19, Lew Pitcher wrote: > > > >>> My linker complained about multiple definitions of variables. > >> > >> From the Standard C standpoint, wouldn't that make your linker "wrong"? > > > > > > > >> Historically, linkage editors assign the same storage location to > >> multiple > >> storage definitions that have both the same name and size, and are > >> uninitialized. > > uninitialized variable is pushed thru the stack and the value is carried with the code > > initialized variable is mapped in memory and are access to that memory. These losers get their jollies out of provoking angry responses to their nonsense, which is the very definition of a troll. Oh goodness, that is just tons of hooey. What is your evidence? Linux offers the least of everything to the average user. Translation of DFS speak: His remarkable "diagnostic mastery" distracted him from a plugin he insists does not exists that John Gohde found in under a minute for GnuPG. The only thing inoperative here is DFS. Until DFS offers up his 'top-of-the-line' Linux system for testing, there is no threat, just giddy contentions. -- E-commerce Simplified http://www.5z8.info/killallimmigrants_j6f7mm_gruesome-gunshot-wounds https://groups.google.com/forum/#!topic/comp.lang.c/KDQrv8appR8 Jonas Eklundh
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2018-05-07 11:21 -0400 |
| Message-ID | <pcpqu1$m78$1@dont-email.me> |
| In reply to | #130308 |
Davs wrote:
> On 06/05/18 21:16, bartc wrote:
>> On 06/05/2018 19:19, Lew Pitcher wrote:
>>
>>>> My linker complained about multiple definitions of variables.
>>>
>>> From the Standard C standpoint, wouldn't that make your linker "wrong"?
>>
>>
>>
>>> Historically, linkage editors assign the same storage location to
>>> multiple
>>> storage definitions that have both the same name and size, and are
>>> uninitialized.
>
> uninitialized variable is pushed thru the stack and the value is carried
> with the code
Uninitialized "static" and "external" objects are typically accounted for,
but not explicitly allocated, by the compiler and linker.
In Unix-like systems, they are marked (by the compiler and/or linker) as
belonging in the BSS ("Block Started by Symbol) located (by the loader) in
an area of process memory that has not otherwise been filled. (The binary
contains the "text" (code) segment, and the "data" (static, initialized
objects) segment; the process memory is subdivided into "text"
(corresponding to the "text" segment), "data" (corresponding to the "data"
segment), "BSS", "heap" and "stack", with the contents of the BSS, heap and
stack defaulting to whatever was in memory at the time).
Alternatively, unitialized "auto" objects are typically allocated on a stack
or other form of execution-time temporary storage.
> initialized variable is mapped in memory and are access to that memory.
--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-07 09:21 -0700 |
| Message-ID | <f06211e5-44dd-4321-81e6-4a2f5314cb01@googlegroups.com> |
| In reply to | #130318 |
On Monday, May 7, 2018 at 8:21:46 AM UTC-7, Lew Pitcher wrote:
> Davs wrote:
>
> > On 06/05/18 21:16, bartc wrote:
> >> On 06/05/2018 19:19, Lew Pitcher wrote:
> >>
> >>>> My linker complained about multiple definitions of variables.
> >>>
> >>> From the Standard C standpoint, wouldn't that make your linker "wrong"?
> >>
> >>
> >>
> >>> Historically, linkage editors assign the same storage location to
> >>> multiple
> >>> storage definitions that have both the same name and size, and are
> >>> uninitialized.
> >
> > uninitialized variable is pushed thru the stack and the value is carried
> > with the code
>
> Uninitialized "static" and "external" objects are typically accounted for,
> but not explicitly allocated, by the compiler and linker.
>
> In Unix-like systems, they are marked (by the compiler and/or linker) as
> belonging in the BSS ("Block Started by Symbol) located (by the loader) in
> an area of process memory that has not otherwise been filled. (The binary
> contains the "text" (code) segment, and the "data" (static, initialized
> objects) segment; the process memory is subdivided into "text"
> (corresponding to the "text" segment), "data" (corresponding to the "data"
> segment), "BSS", "heap" and "stack", with the contents of the BSS, heap and
> stack defaulting to whatever was in memory at the time).
>
> Alternatively, unitialized "auto" objects are typically allocated on a stack
> or other form of execution-time temporary storage.
>
>
> > initialized variable is mapped in memory and are access to that memory.
>
>
> --
> Lew Pitcher
> "In Skills, We Trust"
> PGP public key available upon request
Just nonsense from Peter the Cöwardly Liön. But Peter the Cöwardly Liön has thoroughly left objectivity behind and is just holding me at fault for the exploits of himself.
Can you get David Brown to agree? Thanks to Peter the Cöwardly Liön and his 'co-trolls' you now need a whitelist. If David Brown and others start trolling him again I will feel compelled to... as I said. I'm referring to our clan here, not Peter the Cöwardly Liön's friends, who will never agree to stop.
--
Best CMS Solution of 2017
http://www.5z8.info/michaelangelo-virus_t6v2vq_molotovcocktail
Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2018-05-07 12:13 -0500 |
| Message-ID | <b521fd5m8o3hcg0etur3i06l4hkrf1k8cb@4ax.com> |
| In reply to | #130318 |
On Mon, 07 May 2018 11:21:33 -0400, Lew Pitcher
<lew.pitcher@digitalfreehold.ca> wrote:
>Davs wrote:
>
>> On 06/05/18 21:16, bartc wrote:
>>> On 06/05/2018 19:19, Lew Pitcher wrote:
>>>
>>>>> My linker complained about multiple definitions of variables.
>>>>
>>>> From the Standard C standpoint, wouldn't that make your linker "wrong"?
>>>
>>>
>>>
>>>> Historically, linkage editors assign the same storage location to
>>>> multiple
>>>> storage definitions that have both the same name and size, and are
>>>> uninitialized.
>>
>> uninitialized variable is pushed thru the stack and the value is carried
>> with the code
>
>Uninitialized "static" and "external" objects are typically accounted for,
>but not explicitly allocated, by the compiler and linker.
>
>In Unix-like systems, they are marked (by the compiler and/or linker) as
>belonging in the BSS ("Block Started by Symbol) located (by the loader) in
>an area of process memory that has not otherwise been filled. (The binary
>contains the "text" (code) segment, and the "data" (static, initialized
>objects) segment; the process memory is subdivided into "text"
>(corresponding to the "text" segment), "data" (corresponding to the "data"
>segment), "BSS", "heap" and "stack", with the contents of the BSS, heap and
>stack defaulting to whatever was in memory at the time).
Not true for typical BSS segments as generated by C compilers, which
must have the area cleared. It can be cleared by either by the OS or
the runtime, depending on the implementation, but it does need to be
cleared from the perspective of the C program.
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-07 10:24 -0700 |
| Message-ID | <a8c045ee-5215-4871-a5c5-ac8c88411d85@googlegroups.com> |
| In reply to | #130324 |
On Monday, May 7, 2018 at 10:13:33 AM UTC-7, robert...@yahoo.com wrote:
> On Mon, 07 May 2018 11:21:33 -0400, Lew Pitcher
> <lew.pitcher@digitalfreehold.ca> wrote:
>
> >Davs wrote:
> >
> >> On 06/05/18 21:16, bartc wrote:
> >>> On 06/05/2018 19:19, Lew Pitcher wrote:
> >>>
> >>>>> My linker complained about multiple definitions of variables.
> >>>>
> >>>> From the Standard C standpoint, wouldn't that make your linker "wrong"?
> >>>
> >>>
> >>>
> >>>> Historically, linkage editors assign the same storage location to
> >>>> multiple
> >>>> storage definitions that have both the same name and size, and are
> >>>> uninitialized.
> >>
> >> uninitialized variable is pushed thru the stack and the value is carried
> >> with the code
> >
> >Uninitialized "static" and "external" objects are typically accounted for,
> >but not explicitly allocated, by the compiler and linker.
> >
> >In Unix-like systems, they are marked (by the compiler and/or linker) as
> >belonging in the BSS ("Block Started by Symbol) located (by the loader) in
> >an area of process memory that has not otherwise been filled. (The binary
> >contains the "text" (code) segment, and the "data" (static, initialized
> >objects) segment; the process memory is subdivided into "text"
> >(corresponding to the "text" segment), "data" (corresponding to the "data"
> >segment), "BSS", "heap" and "stack", with the contents of the BSS, heap and
> >stack defaulting to whatever was in memory at the time).
>
>
> Not true for typical BSS segments as generated by C compilers, which
> must have the area cleared. It can be cleared by either by the OS or
> the runtime, depending on the implementation, but it does need to be
> cleared from the perspective of the C program.
Barry Margolin lies that he uses Linux, while really he never recorded it on a modern device and actually pushed it.
Can ASCII characters be concatenated into a string with a logical connection to the "real" world; that is the question posed recently by those astonished at the non-stop flood of gibberish from trolls and neck beard freaks.
What it looks like is the least of your problems and not key to its performance, especially if it's open source.
--
Top 15 Ways Barry Margolin Trolls
https://youtu.be/HMx0RyzbPgQ
https://www.reddit.com/r/linux/comments/6sfkup/what_desktop_tasks_does_linux_handle_better_than/=
http://www.5z8.info/hack-outlook_c6c9in_michaelangelo-virus
Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2018-05-07 13:27 -0400 |
| Message-ID | <pcq2ai$ib6$1@dont-email.me> |
| In reply to | #130324 |
Robert Wessel wrote:
> On Mon, 07 May 2018 11:21:33 -0400, Lew Pitcher
> <lew.pitcher@digitalfreehold.ca> wrote:
>
>>Davs wrote:
>>
>>> On 06/05/18 21:16, bartc wrote:
>>>> On 06/05/2018 19:19, Lew Pitcher wrote:
>>>>
>>>>>> My linker complained about multiple definitions of variables.
>>>>>
>>>>> From the Standard C standpoint, wouldn't that make your linker
>>>>> "wrong"?
>>>>
>>>>
>>>>
>>>>> Historically, linkage editors assign the same storage location to
>>>>> multiple
>>>>> storage definitions that have both the same name and size, and are
>>>>> uninitialized.
>>>
>>> uninitialized variable is pushed thru the stack and the value is carried
>>> with the code
>>
>>Uninitialized "static" and "external" objects are typically accounted for,
>>but not explicitly allocated, by the compiler and linker.
>>
>>In Unix-like systems, they are marked (by the compiler and/or linker) as
>>belonging in the BSS ("Block Started by Symbol) located (by the loader) in
>>an area of process memory that has not otherwise been filled. (The binary
>>contains the "text" (code) segment, and the "data" (static, initialized
>>objects) segment; the process memory is subdivided into "text"
>>(corresponding to the "text" segment), "data" (corresponding to the "data"
>>segment), "BSS", "heap" and "stack", with the contents of the BSS, heap
>>and stack defaulting to whatever was in memory at the time).
>
>
> Not true for typical BSS segments as generated by C compilers, which
> must have the area cleared. It can be cleared by either by the OS or
> the runtime, depending on the implementation, but it does need to be
> cleared from the perspective of the C program.
True. Obviously, I wasn't clear to my point.
The point was that neither the compiled object nor the linked binary
contained the BSS; it (and it's contents) were established by the loader (or
OS) at the time that the binary was loaded into memory for execution.
The compiled code would not contain "space set aside for the BSS objects";
it would only contain executable instructions that /presumed/ that an object
existed at a specific displacement (and for a specific length) from the
start of BSS.
In other words, the assembly (text/data) would NOT look like
; code: int var1;
var1: DS W ;reserve space for 1 word, call it var1
;... code elided
; code: var1 = 10;
LDIW ACC,10
STW @var1,ACC ; store a word at storage location var1
but, instead, would look like
; code: int var1;
;... code elided
; code: var1 = 10;
LDIW ACC,10
STW @(BSS+var1),ACC ; store a word at var1 displacement
; from beginning of BSS
--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-05-07 17:33 +0000 |
| Message-ID | <E50IC.52493$pg3.43816@fx29.iad> |
| In reply to | #130327 |
Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>Robert Wessel wrote:
>
>> On Mon, 07 May 2018 11:21:33 -0400, Lew Pitcher
>> <lew.pitcher@digitalfreehold.ca> wrote:
>>
>>>Davs wrote:
>>>
>>>> On 06/05/18 21:16, bartc wrote:
>>>>> On 06/05/2018 19:19, Lew Pitcher wrote:
>>>>>
>>>>>>> My linker complained about multiple definitions of variables.
>>>>>>
>>>>>> From the Standard C standpoint, wouldn't that make your linker
>>>>>> "wrong"?
>>>>>
>>>>>
>>>>>
>>>>>> Historically, linkage editors assign the same storage location to
>>>>>> multiple
>>>>>> storage definitions that have both the same name and size, and are
>>>>>> uninitialized.
>>>>
>>>> uninitialized variable is pushed thru the stack and the value is carried
>>>> with the code
>>>
>>>Uninitialized "static" and "external" objects are typically accounted for,
>>>but not explicitly allocated, by the compiler and linker.
>>>
>>>In Unix-like systems, they are marked (by the compiler and/or linker) as
>>>belonging in the BSS ("Block Started by Symbol) located (by the loader) in
>>>an area of process memory that has not otherwise been filled. (The binary
>>>contains the "text" (code) segment, and the "data" (static, initialized
>>>objects) segment; the process memory is subdivided into "text"
>>>(corresponding to the "text" segment), "data" (corresponding to the "data"
>>>segment), "BSS", "heap" and "stack", with the contents of the BSS, heap
>>>and stack defaulting to whatever was in memory at the time).
>>
>>
>> Not true for typical BSS segments as generated by C compilers, which
>> must have the area cleared. It can be cleared by either by the OS or
>> the runtime, depending on the implementation, but it does need to be
>> cleared from the perspective of the C program.
>
>True. Obviously, I wasn't clear to my point.
>
>The point was that neither the compiled object nor the linked binary
>contained the BSS; it (and it's contents) were established by the loader (or
>OS) at the time that the binary was loaded into memory for execution.
>
>The compiled code would not contain "space set aside for the BSS objects";
>it would only contain executable instructions that /presumed/ that an object
>existed at a specific displacement (and for a specific length) from the
>start of BSS.
>
>In other words, the assembly (text/data) would NOT look like
>
> ; code: int var1;
> var1: DS W ;reserve space for 1 word, call it var1
>
> ;... code elided
>
> ; code: var1 = 10;
> LDIW ACC,10
> STW @var1,ACC ; store a word at storage location var1
>
>but, instead, would look like
>
> ; code: int var1;
>
> ;... code elided
>
> ; code: var1 = 10;
> LDIW ACC,10
> STW @(BSS+var1),ACC ; store a word at var1 displacement
> ; from beginning of BSS
Objects allocated to the BSS section still will have symbol table
entries, so there is no need to do offset-based addressing for the
BSS section.
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2018-05-07 13:50 -0400 |
| Message-ID | <pcq3le$s0n$1@dont-email.me> |
| In reply to | #130328 |
Scott Lurndal wrote:
> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>>Robert Wessel wrote:
>>
>>> On Mon, 07 May 2018 11:21:33 -0400, Lew Pitcher
>>> <lew.pitcher@digitalfreehold.ca> wrote:
>>>
>>>>Davs wrote:
>>>>
>>>>> On 06/05/18 21:16, bartc wrote:
>>>>>> On 06/05/2018 19:19, Lew Pitcher wrote:
>>>>>>
>>>>>>>> My linker complained about multiple definitions of variables.
>>>>>>>
>>>>>>> From the Standard C standpoint, wouldn't that make your linker
>>>>>>> "wrong"?
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Historically, linkage editors assign the same storage location to
>>>>>>> multiple
>>>>>>> storage definitions that have both the same name and size, and are
>>>>>>> uninitialized.
>>>>>
>>>>> uninitialized variable is pushed thru the stack and the value is
>>>>> carried with the code
>>>>
>>>>Uninitialized "static" and "external" objects are typically accounted
>>>>for, but not explicitly allocated, by the compiler and linker.
>>>>
>>>>In Unix-like systems, they are marked (by the compiler and/or linker) as
>>>>belonging in the BSS ("Block Started by Symbol) located (by the loader)
>>>>in an area of process memory that has not otherwise been filled. (The
>>>>binary contains the "text" (code) segment, and the "data" (static,
>>>>initialized objects) segment; the process memory is subdivided into
>>>>"text" (corresponding to the "text" segment), "data" (corresponding to
>>>>the "data" segment), "BSS", "heap" and "stack", with the contents of the
>>>>BSS, heap and stack defaulting to whatever was in memory at the time).
>>>
>>>
>>> Not true for typical BSS segments as generated by C compilers, which
>>> must have the area cleared. It can be cleared by either by the OS or
>>> the runtime, depending on the implementation, but it does need to be
>>> cleared from the perspective of the C program.
>>
>>True. Obviously, I wasn't clear to my point.
>>
>>The point was that neither the compiled object nor the linked binary
>>contained the BSS; it (and it's contents) were established by the loader
>>(or OS) at the time that the binary was loaded into memory for execution.
>>
>>The compiled code would not contain "space set aside for the BSS objects";
>>it would only contain executable instructions that /presumed/ that an
>>object existed at a specific displacement (and for a specific length) from
>>the start of BSS.
>>
>>In other words, the assembly (text/data) would NOT look like
>>
>> ; code: int var1;
>> var1: DS W ;reserve space for 1 word, call it var1
>>
>> ;... code elided
>>
>> ; code: var1 = 10;
>> LDIW ACC,10
>> STW @var1,ACC ; store a word at storage location var1
>>
>>but, instead, would look like
>>
>> ; code: int var1;
>>
>> ;... code elided
>>
>> ; code: var1 = 10;
>> LDIW ACC,10
>> STW @(BSS+var1),ACC ; store a word at var1 displacement
>>; from beginning of BSS
>
> Objects allocated to the BSS section still will have symbol table
> entries, so there is no need to do offset-based addressing for the
> BSS section.
Yup.
The binary carries
- TEXT, with instructions that assume data will be located at established,
fixed displacements from the start of the BSS; this is accomplished at
compile time, and does not require the propogation of the compile symbol
table, and
- the overall length of the BSS, and
- the usual relocation mechanisms, which the loader will use to adjust the
TEXT references to point at the appropriate places in the BSS
FWIW, these are basics from the history and evolution of computer languages,
discussed in much greater depth in such sources as
- Principles of Compiler Design (Alfred Aho & Jeffrey Ullman),
- Compilers - Principles, Techniques and Tools (Aho, Sethi & Ullman)
- The Structure and Design of Programming Languages (J.E. Nicholls)
- A tour through the UNIX C Compiler (D. M. Ritchie)
- A tour through the Portable C Compiler (S. C. Johnson)
- Operating Systems - Design and Implementation (Andrew S. Tanenbaum)
among many others.
--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-07 10:56 -0700 |
| Message-ID | <e1d98d2d-5293-473e-9940-2ceaebd59bb3@googlegroups.com> |
| In reply to | #130328 |
On Monday, May 7, 2018 at 10:33:32 AM UTC-7, Scott Lurndal wrote:
> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
> >Robert Wessel wrote:
> >
> >> On Mon, 07 May 2018 11:21:33 -0400, Lew Pitcher
> >> <lew.pitcher@digitalfreehold.ca> wrote:
> >>
> >>>Davs wrote:
> >>>
> >>>> On 06/05/18 21:16, bartc wrote:
> >>>>> On 06/05/2018 19:19, Lew Pitcher wrote:
> >>>>>
> >>>>>>> My linker complained about multiple definitions of variables.
> >>>>>>
> >>>>>> From the Standard C standpoint, wouldn't that make your linker
> >>>>>> "wrong"?
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Historically, linkage editors assign the same storage location to
> >>>>>> multiple
> >>>>>> storage definitions that have both the same name and size, and are
> >>>>>> uninitialized.
> >>>>
> >>>> uninitialized variable is pushed thru the stack and the value is carried
> >>>> with the code
> >>>
> >>>Uninitialized "static" and "external" objects are typically accounted for,
> >>>but not explicitly allocated, by the compiler and linker.
> >>>
> >>>In Unix-like systems, they are marked (by the compiler and/or linker) as
> >>>belonging in the BSS ("Block Started by Symbol) located (by the loader) in
> >>>an area of process memory that has not otherwise been filled. (The binary
> >>>contains the "text" (code) segment, and the "data" (static, initialized
> >>>objects) segment; the process memory is subdivided into "text"
> >>>(corresponding to the "text" segment), "data" (corresponding to the "data"
> >>>segment), "BSS", "heap" and "stack", with the contents of the BSS, heap
> >>>and stack defaulting to whatever was in memory at the time).
> >>
> >>
> >> Not true for typical BSS segments as generated by C compilers, which
> >> must have the area cleared. It can be cleared by either by the OS or
> >> the runtime, depending on the implementation, but it does need to be
> >> cleared from the perspective of the C program.
> >
> >True. Obviously, I wasn't clear to my point.
> >
> >The point was that neither the compiled object nor the linked binary
> >contained the BSS; it (and it's contents) were established by the loader (or
> >OS) at the time that the binary was loaded into memory for execution.
> >
> >The compiled code would not contain "space set aside for the BSS objects";
> >it would only contain executable instructions that /presumed/ that an object
> >existed at a specific displacement (and for a specific length) from the
> >start of BSS.
> >
> >In other words, the assembly (text/data) would NOT look like
> >
> > ; code: int var1;
> > var1: DS W ;reserve space for 1 word, call it var1
> >
> > ;... code elided
> >
> > ; code: var1 = 10;
> > LDIW ACC,10
> > STW @var1,ACC ; store a word at storage location var1
> >
> >but, instead, would look like
> >
> > ; code: int var1;
> >
> > ;... code elided
> >
> > ; code: var1 = 10;
> > LDIW ACC,10
> > STW @(BSS+var1),ACC ; store a word at var1 displacement
> > ; from beginning of BSS
>
> Objects allocated to the BSS section still will have symbol table
> entries, so there is no need to do offset-based addressing for the
> BSS section.
What's DFS's tool for the flooding deluge? AppleScript? That is the only database he knows, and it is a joke. He must be programming it to produce these goofy "flooding" posts. My conjecture, DFS took a PGP program that he reverse engineered and took credit for... he is feeding it data from the program, grabbing "special" paragraphs, then editing those using a Markv model and then he actively posts them because his lack of work enables him to do that practically endlessly.
I am working on code which will blow what Linux has away.
DFS's posts are nothing but a meaningless rambling. DFS is trying ("very" hard) to project their approach onto Pascal Hambourg. For some time DFS has encouraged the belief that Pascal Hambourg needs 'witnesses' to point out all his poor behavior. The fact is that nobody needs any proof to do that. So DFS pulls this ridiculous flooding foolishness in a sickly attempt to 'hawk' the idea that Pascal Hambourg is like he is.
Over and over, the surface request is DFS wants to "talk tech", but DFS spends most of his time whining about "obsession". Proof DFS accuses everyone of being Snit http://sandman.net/files/snit_circus.png.
This is truly a hobby of DFS's.
-
My Snoring Solution!
https://youtu.be/lF8yk7ul4Mw
http://www.5z8.info/--INITIATE-CREDIT-CARD-XFER--_k7s1jt_inject_worm
https://www.youtube.com/watch?v=IhOfBmWwCVY
Jonas Eklundh
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-08 09:26 +0200 |
| Message-ID | <pcrjf2$uo3$1@dont-email.me> |
| In reply to | #130327 |
On 07/05/18 19:27, Lew Pitcher wrote:
> Robert Wessel wrote:
>
>> On Mon, 07 May 2018 11:21:33 -0400, Lew Pitcher
>> <lew.pitcher@digitalfreehold.ca> wrote:
>>
>>> Davs wrote:
>>>
>>>> On 06/05/18 21:16, bartc wrote:
>>>>> On 06/05/2018 19:19, Lew Pitcher wrote:
>>>>>
>>>>>>> My linker complained about multiple definitions of variables.
>>>>>>
>>>>>> From the Standard C standpoint, wouldn't that make your linker
>>>>>> "wrong"?
>>>>>
>>>>>
>>>>>
>>>>>> Historically, linkage editors assign the same storage location to
>>>>>> multiple
>>>>>> storage definitions that have both the same name and size, and are
>>>>>> uninitialized.
>>>>
>>>> uninitialized variable is pushed thru the stack and the value is carried
>>>> with the code
>>>
>>> Uninitialized "static" and "external" objects are typically accounted for,
>>> but not explicitly allocated, by the compiler and linker.
>>>
>>> In Unix-like systems, they are marked (by the compiler and/or linker) as
>>> belonging in the BSS ("Block Started by Symbol) located (by the loader) in
>>> an area of process memory that has not otherwise been filled. (The binary
>>> contains the "text" (code) segment, and the "data" (static, initialized
>>> objects) segment; the process memory is subdivided into "text"
>>> (corresponding to the "text" segment), "data" (corresponding to the "data"
>>> segment), "BSS", "heap" and "stack", with the contents of the BSS, heap
>>> and stack defaulting to whatever was in memory at the time).
>>
>>
>> Not true for typical BSS segments as generated by C compilers, which
>> must have the area cleared. It can be cleared by either by the OS or
>> the runtime, depending on the implementation, but it does need to be
>> cleared from the perspective of the C program.
>
> True. Obviously, I wasn't clear to my point.
>
> The point was that neither the compiled object nor the linked binary
> contained the BSS; it (and it's contents) were established by the loader (or
> OS) at the time that the binary was loaded into memory for execution.
>
> The compiled code would not contain "space set aside for the BSS objects";
> it would only contain executable instructions that /presumed/ that an object
> existed at a specific displacement (and for a specific length) from the
> start of BSS.
>
> In other words, the assembly (text/data) would NOT look like
>
> ; code: int var1;
> var1: DS W ;reserve space for 1 word, call it var1
>
> ;... code elided
>
> ; code: var1 = 10;
> LDIW ACC,10
> STW @var1,ACC ; store a word at storage location var1
>
> but, instead, would look like
>
> ; code: int var1;
>
The assembly /will/ have an entry for var1. It will look something like:
.section .bss
var1: .space 4
Details will, of course, vary from assembler to assembler. But you have
to have the symbol there in the assembly file, in the .bss section, and
with an appropriate size and alignment. How else is the linker going to
know to reserve space for it and assign addresses that can be used by
the rest of the code?
There is no space reserved in the final executable for the .bss - but it
is still part of the memory map for the program, the offsets (or, for
fixed address systems, the absolute addresses) are known for linking the
code, and the size must be known so that the loader or startup code can
ask the OS for an appropriate chunk of memory, and then clear it. In
small embedded systems, typically the linker will allocate space for the
.bss so that you know everything fits in the memory you have available.
> ;... code elided
>
> ; code: var1 = 10;
> LDIW ACC,10
> STW @(BSS+var1),ACC ; store a word at var1 displacement
> ; from beginning of BSS
>
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-08 09:19 +0200 |
| Message-ID | <pcrj1j$sdp$1@dont-email.me> |
| In reply to | #130324 |
On 07/05/18 19:13, Robert Wessel wrote:
> On Mon, 07 May 2018 11:21:33 -0400, Lew Pitcher
> <lew.pitcher@digitalfreehold.ca> wrote:
>
>> Davs wrote:
>>
>>> On 06/05/18 21:16, bartc wrote:
>>>> On 06/05/2018 19:19, Lew Pitcher wrote:
>>>>
>>>>>> My linker complained about multiple definitions of variables.
>>>>>
>>>>> From the Standard C standpoint, wouldn't that make your linker "wrong"?
>>>>
>>>>
>>>>
>>>>> Historically, linkage editors assign the same storage location to
>>>>> multiple
>>>>> storage definitions that have both the same name and size, and are
>>>>> uninitialized.
>>>
>>> uninitialized variable is pushed thru the stack and the value is carried
>>> with the code
>>
>> Uninitialized "static" and "external" objects are typically accounted for,
>> but not explicitly allocated, by the compiler and linker.
>>
>> In Unix-like systems, they are marked (by the compiler and/or linker) as
>> belonging in the BSS ("Block Started by Symbol) located (by the loader) in
>> an area of process memory that has not otherwise been filled. (The binary
>> contains the "text" (code) segment, and the "data" (static, initialized
>> objects) segment; the process memory is subdivided into "text"
>> (corresponding to the "text" segment), "data" (corresponding to the "data"
>> segment), "BSS", "heap" and "stack", with the contents of the BSS, heap and
>> stack defaulting to whatever was in memory at the time).
>
>
> Not true for typical BSS segments as generated by C compilers, which
> must have the area cleared. It can be cleared by either by the OS or
> the runtime, depending on the implementation, but it does need to be
> cleared from the perspective of the C program.
>
Except for some embedded toolchains, which do /not/ clear the bss on the
basis that this would take too long in startup, and that such clearing
is often unnecessary. This is, of course, non-standard behaviour and
the source of vast frustration and confusion until you have found the
problem - and the tiny footnote somewhere in the middle of the 300 pages
of reference manual. (Yes, I have been bitten by this. Twice, to my
shame.)
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-08 00:42 -0700 |
| Message-ID | <3fd4a1fe-99f3-48a9-a289-a85eeb5b0d03@googlegroups.com> |
| In reply to | #130340 |
On Tuesday, May 8, 2018 at 12:19:24 AM UTC-7, David Brown wrote:
> On 07/05/18 19:13, Robert Wessel wrote:
> > On Mon, 07 May 2018 11:21:33 -0400, Lew Pitcher
> > <lew.pitcher@digitalfreehold.ca> wrote:
> >
> >> Davs wrote:
> >>
> >>> On 06/05/18 21:16, bartc wrote:
> >>>> On 06/05/2018 19:19, Lew Pitcher wrote:
> >>>>
> >>>>>> My linker complained about multiple definitions of variables.
> >>>>>
> >>>>> From the Standard C standpoint, wouldn't that make your linker "wrong"?
> >>>>
> >>>>
> >>>>
> >>>>> Historically, linkage editors assign the same storage location to
> >>>>> multiple
> >>>>> storage definitions that have both the same name and size, and are
> >>>>> uninitialized.
> >>>
> >>> uninitialized variable is pushed thru the stack and the value is carried
> >>> with the code
> >>
> >> Uninitialized "static" and "external" objects are typically accounted for,
> >> but not explicitly allocated, by the compiler and linker.
> >>
> >> In Unix-like systems, they are marked (by the compiler and/or linker) as
> >> belonging in the BSS ("Block Started by Symbol) located (by the loader) in
> >> an area of process memory that has not otherwise been filled. (The binary
> >> contains the "text" (code) segment, and the "data" (static, initialized
> >> objects) segment; the process memory is subdivided into "text"
> >> (corresponding to the "text" segment), "data" (corresponding to the "data"
> >> segment), "BSS", "heap" and "stack", with the contents of the BSS, heap and
> >> stack defaulting to whatever was in memory at the time).
> >
> >
> > Not true for typical BSS segments as generated by C compilers, which
> > must have the area cleared. It can be cleared by either by the OS or
> > the runtime, depending on the implementation, but it does need to be
> > cleared from the perspective of the C program.
> >
>
> Except for some embedded toolchains, which do /not/ clear the bss on the
> basis that this would take too long in startup, and that such clearing
> is often unnecessary. This is, of course, non-standard behaviour and
> the source of vast frustration and confusion until you have found the
> problem - and the tiny footnote somewhere in the middle of the 300 pages
> of reference manual. (Yes, I have been bitten by this. Twice, to my
> shame.)
No more! Protected code is totally screwing up your program. Android is based on Linux. No debate.
Another successful Redhat test. That is if you count wasting time as a success. Idiot.
-
What Every Entrepreneur Must Know!!
http://www.5z8.info/php-start_GPS_tracking-user_f8h9lv_-OPEN-WEBCAM---START-RECORD--
https://youtu.be/HMx0RyzbPgQ
Jonas Eklundh
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-08 06:54 -0700 |
| Message-ID | <8d643bef-a78d-4414-a7c5-35ea3ea79e11@googlegroups.com> |
| In reply to | #130340 |
On Tuesday, May 8, 2018 at 2:19:24 AM UTC-5, David Brown wrote: > On 07/05/18 19:13, Robert Wessel wrote: > > Not true for typical BSS segments as generated by C compilers, which > > must have the area cleared. It can be cleared by either by the OS or > > the runtime, depending on the implementation, but it does need to be > > cleared from the perspective of the C program. > > Except for some embedded toolchains, which do /not/ clear the bss on the > basis that this would take too long in startup, and that such clearing > is often unnecessary. This is, of course, non-standard behaviour and > the source of vast frustration and confusion until you have found the > problem - and the tiny footnote somewhere in the middle of the 300 pages > of reference manual. (Yes, I have been bitten by this. Twice, to my > shame.) Speed isn't the only issue. On many platforms, various conditions may cause or require the processor to be reset while RAM holds useful information. Perhaps that could have been handled by having Standard suggest that objects which are qualified "volatile" may be initialized or not at the implementation's discretion since, an implementation would be allowed to change them at will, and there would be no C-observable difference between initializing them and then spontaneously setting them back to their previous value, versus simply leaving them holding whatever they held at the time the CPU was reset.
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-08 07:24 -0700 |
| Message-ID | <bfc39436-4ed6-40d2-b4f0-c7e2bf73ac9d@googlegroups.com> |
| In reply to | #130346 |
On Tuesday, May 8, 2018 at 6:54:54 AM UTC-7, supe...@casperkitty.com wrote: > On Tuesday, May 8, 2018 at 2:19:24 AM UTC-5, David Brown wrote: > > On 07/05/18 19:13, Robert Wessel wrote: > > > Not true for typical BSS segments as generated by C compilers, which > > > must have the area cleared. It can be cleared by either by the OS or > > > the runtime, depending on the implementation, but it does need to be > > > cleared from the perspective of the C program. > > > > Except for some embedded toolchains, which do /not/ clear the bss on the > > basis that this would take too long in startup, and that such clearing > > is often unnecessary. This is, of course, non-standard behaviour and > > the source of vast frustration and confusion until you have found the > > problem - and the tiny footnote somewhere in the middle of the 300 pages > > of reference manual. (Yes, I have been bitten by this. Twice, to my > > shame.) > > Speed isn't the only issue. On many platforms, various conditions may > cause or require the processor to be reset while RAM holds useful > information. Perhaps that could have been handled by having Standard > suggest that objects which are qualified "volatile" may be initialized > or not at the implementation's discretion since, an implementation would > be allowed to change them at will, and there would be no C-observable > difference between initializing them and then spontaneously setting them > back to their previous value, versus simply leaving them holding whatever > they held at the time the CPU was reset. With no evidence at all, as is usual for owl. Both ed and Mendel had their failures and their discomfort. But one played it cool and didn't do anything too publicly that could not be proved mathematically. Ha! Right, owl is wanting to produce a JavaScript variable, which ed can get from torrent sites, that allows him to flood multiple groups. If he wasn't so lost he would get how lost he sounds. And in retaliation you have nothing but an attempt to start more flooding. I'm not raging, just the opposite I'm busting a gut because owl's idiocy is so clear. He actively didn't speak of all the benchmarks that he would quickly mock... and we all know why, owl is too stupid to see why. At least he has his own socks in his corner. ed's computer has more hard drives than owl's. ed wins. owl loses. Any questions? See: I quoted examples of owl blaming me for the actions of others, flooding every group I post to, etc. His response: to double down on your lies. -- Best CMS Solution of 2017 https://youtu.be/0ZNxaaKD7-c http://www.5z8.info/freeanimalporn.com-start-download_s9j7do_dogporn https://youtu.be/VxLiH-x0aeY Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-08 17:15 +0200 |
| Message-ID | <pcseur$ipe$1@dont-email.me> |
| In reply to | #130346 |
On 08/05/18 15:54, supercat@casperkitty.com wrote: > On Tuesday, May 8, 2018 at 2:19:24 AM UTC-5, David Brown wrote: >> On 07/05/18 19:13, Robert Wessel wrote: >>> Not true for typical BSS segments as generated by C compilers, which >>> must have the area cleared. It can be cleared by either by the OS or >>> the runtime, depending on the implementation, but it does need to be >>> cleared from the perspective of the C program. >> >> Except for some embedded toolchains, which do /not/ clear the bss on the >> basis that this would take too long in startup, and that such clearing >> is often unnecessary. This is, of course, non-standard behaviour and >> the source of vast frustration and confusion until you have found the >> problem - and the tiny footnote somewhere in the middle of the 300 pages >> of reference manual. (Yes, I have been bitten by this. Twice, to my >> shame.) > > Speed isn't the only issue. It is the excuse invariably used. The common case is that some microcontrollers have a watchdog that is enabled at reset (a bad idea - it's better to have a more reliable reset controller) with a short timeout (an idiotic idea), and then to say that zeroing out large arrays would take too long before main() is called and the user can kick the watchdog. The sane solutions are to have watchdog control configured by the C startup code, or to have a hook to allow user code to fix the watchdog before the zeroing of the array. > On many platforms, various conditions may > cause or require the processor to be reset while RAM holds useful > information. Every embedded toolchain has a way to define areas of ram that is not cleared or initialised at reset. It is very rare that these are needed anyway. It is certainly not a justification for failing to clear bss data. > Perhaps that could have been handled by having Standard > suggest that objects which are qualified "volatile" may be initialized > or not at the implementation's discretion since, an implementation would > be allowed to change them at will, and there would be no C-observable > difference between initializing them and then spontaneously setting them > back to their previous value, versus simply leaving them holding whatever > they held at the time the CPU was reset. > No, it should not be connected to "volatile" in any way. Having some standardised way to say that a particular variable should not be initialised at startup might be nice, but I don't think the lack of standardisation is a problem to anyone.
[toc] | [prev] | [next] | [standalone]
Page 1 of 11 [1] 2 3 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web