Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #128674 > unrolled thread
| Started by | bartc <bc@freeuk.com> |
|---|---|
| First post | 2018-04-04 00:32 +0100 |
| Last post | 2018-04-26 22:50 -0700 |
| Articles | 20 on this page of 316 — 40 participants |
Back to article view | Back to comp.lang.c
"C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-04 00:32 +0100
Re: "C's Biggest Mistake" Melzzzzz <Melzzzzz@zzzzz.com> - 2018-04-03 23:43 +0000
Re: "C's Biggest Mistake" John Bode <jfbode1029@gmail.com> - 2018-04-03 20:25 -0700
Re: "C's Biggest Mistake" supercat@casperkitty.com - 2018-04-04 08:33 -0700
Re: "C's Biggest Mistake" Lynn McGuire <lynnmcguire5@gmail.com> - 2018-04-04 15:46 -0500
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-04 22:56 +0100
Re: "C's Biggest Mistake" jacobnavia <jacob@jacob.remcomp.fr> - 2018-04-05 00:45 +0200
Re: "C's Biggest Mistake" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-04-04 23:07 +0000
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-05 01:29 +0100
Re: "C's Biggest Mistake" jacobnavia <jacob@jacob.remcomp.fr> - 2018-04-06 00:10 +0200
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-05 23:48 +0100
Re: "C's Biggest Mistake" scott@slp53.sl.home (Scott Lurndal) - 2018-04-05 13:31 +0000
Re: "C's Biggest Mistake" Robert Wessel <robertwessel2@yahoo.com> - 2018-04-05 09:48 -0500
Re: "C's Biggest Mistake" Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-08 16:37 -0700
Re: "C's Biggest Mistake" Keith Thompson <kst-u@mib.org> - 2018-04-08 18:58 -0700
Re: "C's Biggest Mistake" already5chosen@yahoo.com - 2018-04-09 00:56 -0700
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-09 01:59 -0700
Re: "C's Biggest Mistake" mark.bluemel@gmail.com - 2018-04-09 02:36 -0700
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-09 03:49 -0700
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-09 12:14 +0100
Re: "C's Biggest Mistake" mark.bluemel@gmail.com - 2018-04-09 04:40 -0700
Re: "C's Biggest Mistake" Robert Wessel <robertwessel2@yahoo.com> - 2018-04-09 22:21 -0500
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-09 21:37 -0700
Re: "C's Biggest Mistake" Wouter Verhelst <w@uter.be> - 2018-04-10 11:51 +0200
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-10 07:15 -0700
Re: "C's Biggest Mistake" already5chosen@yahoo.com - 2018-04-10 11:50 -0700
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-09 11:55 +0100
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-05 17:26 +0100
Re: "C's Biggest Mistake" scott@slp53.sl.home (Scott Lurndal) - 2018-04-05 17:32 +0000
Re: "C's Biggest Mistake" Keith Thompson <kst-u@mib.org> - 2018-04-05 11:05 -0700
Re: "C's Biggest Mistake" David Brown <david.brown@hesbynett.no> - 2018-04-06 10:06 +0200
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-05 19:09 +0100
Re: "C's Biggest Mistake" Keith Thompson <kst-u@mib.org> - 2018-04-05 11:23 -0700
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-05 20:21 +0100
Re: "C's Biggest Mistake" supercat@casperkitty.com - 2018-04-05 12:30 -0700
Re: "C's Biggest Mistake" Keith Thompson <kst-u@mib.org> - 2018-04-05 13:39 -0700
Re: "C's Biggest Mistake" supercat@casperkitty.com - 2018-04-05 14:15 -0700
Re: "C's Biggest Mistake" Keith Thompson <kst-u@mib.org> - 2018-04-05 14:53 -0700
Re: "C's Biggest Mistake" supercat@casperkitty.com - 2018-04-05 15:08 -0700
Re: "C's Biggest Mistake" Robert Wessel <robertwessel2@yahoo.com> - 2018-04-05 16:34 -0500
Re: "C's Biggest Mistake" scott@slp53.sl.home (Scott Lurndal) - 2018-04-05 19:01 +0000
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-05 20:50 +0100
Re: "C's Biggest Mistake" scott@slp53.sl.home (Scott Lurndal) - 2018-04-05 20:25 +0000
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-05 22:07 +0100
Re: "C's Biggest Mistake" Wouter Verhelst <w@uter.be> - 2018-04-05 22:20 +0200
Re: "C's Biggest Mistake" jameskuyper@verizon.net - 2018-04-05 19:50 -0700
Re: "C's Biggest Mistake" Wouter Verhelst <w@uter.be> - 2018-04-06 11:08 +0200
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-06 04:24 -0700
Re: "C's Biggest Mistake" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-04-12 12:35 +0000
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-12 14:02 +0100
Re: "C's Biggest Mistake" Ian Collins <ian-news@hotmail.com> - 2018-04-13 07:18 +1200
Re: "C's Biggest Mistake" scott@slp53.sl.home (Scott Lurndal) - 2018-04-12 20:12 +0000
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-12 22:20 +0100
Re: "C's Biggest Mistake" Ian Collins <ian-news@hotmail.com> - 2018-04-13 09:35 +1200
Re: "C's Biggest Mistake" supercat@casperkitty.com - 2018-04-12 14:47 -0700
Re: "C's Biggest Mistake" Keith Thompson <kst-u@mib.org> - 2018-04-12 15:19 -0700
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-13 01:44 +0100
Re: "C's Biggest Mistake" Wouter Verhelst <w@uter.be> - 2018-04-13 13:04 +0200
Re: "C's Biggest Mistake" Ed Kellett <e@kellett.im> - 2018-04-13 12:30 +0100
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-13 05:22 -0700
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-13 12:40 +0100
Re: "C's Biggest Mistake" Wouter Verhelst <w@uter.be> - 2018-04-13 14:14 +0200
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-13 13:53 +0100
Re: "C's Biggest Mistake" scott@slp53.sl.home (Scott Lurndal) - 2018-04-13 13:52 +0000
Re: "C's Biggest Mistake" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-04-13 15:25 +0000
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-13 08:45 -0700
Re: "C's Biggest Mistake" Keith Thompson <kst-u@mib.org> - 2018-04-13 08:58 -0700
Re: "C's Biggest Mistake" scott@slp53.sl.home (Scott Lurndal) - 2018-04-13 16:24 +0000
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-13 18:09 +0100
Re: "C's Biggest Mistake" Keith Thompson <kst-u@mib.org> - 2018-04-13 10:26 -0700
Re: "C's Biggest Mistake" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-04-13 11:48 -0400
Re: "C's Biggest Mistake" scott@slp53.sl.home (Scott Lurndal) - 2018-04-13 13:50 +0000
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-13 16:00 +0100
Re: "C's Biggest Mistake" Keith Thompson <kst-u@mib.org> - 2018-04-13 09:03 -0700
Re: "C's Biggest Mistake" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-04-13 12:06 -0400
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-13 18:04 +0100
Re: "C's Biggest Mistake" Keith Thompson <kst-u@mib.org> - 2018-04-13 10:09 -0700
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-13 18:14 +0100
Re: "C's Biggest Mistake" David Brown <david.brown@hesbynett.no> - 2018-04-14 12:56 +0200
Re: "C's Biggest Mistake" Richard Damon <Richard@Damon-Family.org> - 2018-04-14 12:34 -0400
Re: "C's Biggest Mistake" jameskuyper@verizon.net - 2018-04-14 09:59 -0700
Re: "C's Biggest Mistake" Keith Thompson <kst-u@mib.org> - 2018-04-14 12:51 -0700
Re: "C's Biggest Mistake" Ike Naar <ike@iceland.freeshell.org> - 2018-04-15 18:52 +0000
Re: "C's Biggest Mistake" Keith Thompson <kst-u@mib.org> - 2018-04-15 12:39 -0700
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-16 00:56 -0700
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-15 21:49 -0700
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-12 22:34 +0100
Re: "C's Biggest Mistake" Ian Collins <ian-news@hotmail.com> - 2018-04-13 09:50 +1200
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-12 23:16 +0100
Re: "C's Biggest Mistake" Ian Collins <ian-news@hotmail.com> - 2018-04-13 10:30 +1200
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-12 23:42 +0100
Re: "C's Biggest Mistake" Ian Collins <ian-news@hotmail.com> - 2018-04-13 10:46 +1200
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-13 01:21 +0100
Re: "C's Biggest Mistake" Reinhardt Behm <rbehm@hushmail.com> - 2018-04-13 09:04 +0800
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-13 02:14 +0100
Re: "C's Biggest Mistake" David Brown <david.brown@hesbynett.no> - 2018-04-13 10:03 +0200
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-13 02:46 -0700
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-13 11:22 +0100
Re: "C's Biggest Mistake" David Brown <david.brown@hesbynett.no> - 2018-04-13 13:45 +0200
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-13 13:44 +0100
Re: "C's Biggest Mistake" David Brown <david.brown@hesbynett.no> - 2018-04-13 15:18 +0200
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-13 18:27 +0100
Re: "C's Biggest Mistake" Ian Collins <ian-news@hotmail.com> - 2018-04-13 13:43 +1200
Re: "C's Biggest Mistake" Reinhardt Behm <rbehm@hushmail.com> - 2018-04-13 08:55 +0800
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-12 06:04 -0700
Re: "C's Biggest Mistake" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-12 06:09 -0700
Re: "C's Biggest Mistake" Robert Wessel <robertwessel2@yahoo.com> - 2018-04-05 16:44 -0500
Re: "C's Biggest Mistake" David Brown <david.brown@hesbynett.no> - 2018-04-06 14:46 +0200
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-06 05:57 -0700
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-06 14:31 +0100
Re: "C's Biggest Mistake" David Brown <david.brown@hesbynett.no> - 2018-04-06 16:23 +0200
Re: "C's Biggest Mistake" Richard Damon <Richard@Damon-Family.org> - 2018-04-06 10:58 -0400
Re: "C's Biggest Mistake" scott@slp53.sl.home (Scott Lurndal) - 2018-04-06 15:46 +0000
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-06 16:18 +0100
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-06 23:01 -0700
Re: "C's Biggest Mistake" Ian Collins <ian-news@hotmail.com> - 2018-04-05 11:36 +1200
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-05 01:34 +0100
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-05 01:23 -0700
Re: "C's Biggest Mistake" David Brown <david.brown@hesbynett.no> - 2018-04-05 12:59 +0200
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-05 12:33 +0100
Re: "C's Biggest Mistake" David Brown <david.brown@hesbynett.no> - 2018-04-05 14:37 +0200
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-05 14:09 +0100
Re: "C's Biggest Mistake" GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-04-05 16:09 +0200
Re: "C's Biggest Mistake" David Brown <david.brown@hesbynett.no> - 2018-04-05 16:10 +0200
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-06 12:10 +0100
Re: "C's Biggest Mistake" David Brown <david.brown@hesbynett.no> - 2018-04-06 16:01 +0200
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-06 16:03 +0100
Re: "C's Biggest Mistake" David Brown <david.brown@hesbynett.no> - 2018-04-06 17:31 +0200
Re: "C's Biggest Mistake" Ben Bacarisse <ben.lists@bsb.me.uk> - 2018-04-06 17:26 +0100
Re: "C's Biggest Mistake" David Brown <david.brown@hesbynett.no> - 2018-04-06 18:45 +0200
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-06 19:35 +0100
Re: "C's Biggest Mistake" Ian Collins <ian-news@hotmail.com> - 2018-04-07 11:49 +1200
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-07 02:17 +0100
Re: "C's Biggest Mistake" Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2018-04-07 05:10 +0200
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-07 12:09 +0100
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-07 04:29 -0700
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-07 07:05 -0700
Re: "C's Biggest Mistake" Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-08 15:21 -0700
Re: "C's Biggest Mistake" Ian Collins <ian-news@hotmail.com> - 2018-04-09 17:10 +1200
Re: "C's Biggest Mistake" Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-09 07:38 -0700
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-09 08:14 -0700
Re: "C's Biggest Mistake" David Brown <david.brown@hesbynett.no> - 2018-04-07 18:16 +0200
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-07 19:31 +0100
Re: "C's Biggest Mistake" David Brown <david.brown@hesbynett.no> - 2018-04-08 15:19 +0200
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-08 15:16 +0100
Re: "C's Biggest Mistake" David Brown <david.brown@hesbynett.no> - 2018-04-08 16:37 +0200
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-08 15:45 +0100
Re: "C's Biggest Mistake" David Brown <david.brown@hesbynett.no> - 2018-04-08 17:52 +0200
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-08 18:04 +0100
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-08 10:35 -0700
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-08 16:17 +0100
Re: "C's Biggest Mistake" Keith Thompson <kst-u@mib.org> - 2018-04-07 13:13 -0700
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-07 21:39 +0100
Re: "C's Biggest Mistake" Keith Thompson <kst-u@mib.org> - 2018-04-07 13:55 -0700
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-07 22:10 +0100
Re: "C's Biggest Mistake" Keith Thompson <kst-u@mib.org> - 2018-04-07 15:04 -0700
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-07 23:27 +0100
Re: "C's Biggest Mistake" Keith Thompson <kst-u@mib.org> - 2018-04-07 16:03 -0700
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-08 02:11 +0100
Re: "C's Biggest Mistake" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-04-08 02:48 +0100
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-08 11:15 +0100
Re: "C's Biggest Mistake" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-04-08 12:19 +0100
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-08 13:33 +0100
Re: "C's Biggest Mistake" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-04-08 19:52 +0100
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-08 21:12 +0100
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-08 21:14 +0100
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-08 13:28 -0700
Re: "C's Biggest Mistake" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-04-08 22:39 +0100
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-09 00:16 +0100
Re: "C's Biggest Mistake" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-04-09 00:45 +0100
Re: "C's Biggest Mistake" Richard Damon <Richard@Damon-Family.org> - 2018-04-08 22:47 -0400
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-08 18:12 -0700
Re: "C's Biggest Mistake" Robert Wessel <robertwessel2@yahoo.com> - 2018-04-08 17:01 -0500
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-09 00:42 +0100
Re: "C's Biggest Mistake" Richard Damon <Richard@Damon-Family.org> - 2018-04-09 08:29 -0400
Re: "C's Biggest Mistake" Spiros Bousbouras <spibou@gmail.com> - 2018-04-09 15:19 +0000
Re: "C's Biggest Mistake" Spiros Bousbouras <spibou@gmail.com> - 2018-04-09 15:22 +0000
Re: "C's Biggest Mistake" Keith Thompson <kst-u@mib.org> - 2018-04-07 19:21 -0700
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-08 11:24 +0100
Re: "C's Biggest Mistake" already5chosen@yahoo.com - 2018-04-08 05:37 -0700
Re: "C's Biggest Mistake" David Brown <david.brown@hesbynett.no> - 2018-04-08 15:29 +0200
Re: "C's Biggest Mistake" supercat@casperkitty.com - 2018-04-08 13:00 -0700
Re: "C's Biggest Mistake" scott@slp53.sl.home (Scott Lurndal) - 2018-04-09 14:14 +0000
Re: "C's Biggest Mistake" Robert Wessel <robertwessel2@yahoo.com> - 2018-04-09 22:28 -0500
Re: "C's Biggest Mistake" David Brown <david.brown@hesbynett.no> - 2018-04-08 15:24 +0200
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-08 01:26 -0700
Re: "C's Biggest Mistake" asetofsymbols@gmail.com - 2018-04-07 23:20 -0700
Re: "C's Biggest Mistake" Wouter Verhelst <w@uter.be> - 2018-04-08 22:16 +0200
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-09 01:08 +0100
Re: "C's Biggest Mistake" Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-09 08:10 -0700
Re: "C's Biggest Mistake" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-09 08:50 -0700
Re: "C's Biggest Mistake" Wouter Verhelst <w@uter.be> - 2018-04-08 21:53 +0200
Re: "C's Biggest Mistake" scott@slp53.sl.home (Scott Lurndal) - 2018-04-05 13:33 +0000
Re: "C's Biggest Mistake" Wouter Verhelst <w@uter.be> - 2018-04-05 15:38 +0200
Re: "C's Biggest Mistake" supercat@casperkitty.com - 2018-04-05 08:58 -0700
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-05 17:23 +0100
Re: "C's Biggest Mistake" Keith Thompson <kst-u@mib.org> - 2018-04-05 10:55 -0700
Re: "C's Biggest Mistake" GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-04-05 04:42 +0200
Re: "C's Biggest Mistake" Ben Bacarisse <ben.lists@bsb.me.uk> - 2018-04-05 10:55 +0100
Re: "C's Biggest Mistake" Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-04-05 13:08 +0300
Re: "C's Biggest Mistake" scott@slp53.sl.home (Scott Lurndal) - 2018-04-05 13:34 +0000
Re: "C's Biggest Mistake" Ben Bacarisse <ben.lists@bsb.me.uk> - 2018-04-05 14:37 +0100
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-05 11:45 +0100
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-05 07:07 -0700
Re: "C's Biggest Mistake" GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-04-05 13:40 +0200
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-05 12:49 +0100
Re: "C's Biggest Mistake" GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-04-05 14:12 +0200
Re: "C's Biggest Mistake" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-04-05 05:13 -0700
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-05 13:32 +0100
Re: "C's Biggest Mistake" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-04-05 05:55 -0700
Re: "C's Biggest Mistake" Ben Bacarisse <ben.lists@bsb.me.uk> - 2018-04-05 14:41 +0100
Re: "C's Biggest Mistake" GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-04-05 15:53 +0200
Re: "C's Biggest Mistake" Ben Bacarisse <ben.lists@bsb.me.uk> - 2018-04-05 15:20 +0100
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-05 21:26 -0700
Re: "C's Biggest Mistake" GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-04-05 13:50 +0200
Re: "C's Biggest Mistake" Ben Bacarisse <ben.lists@bsb.me.uk> - 2018-04-05 14:28 +0100
Re: "C's Biggest Mistake" luser droog <luser.droog@gmail.com> - 2018-04-05 23:14 -0700
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-06 00:14 -0700
Re: "C's Biggest Mistake" David Kleinecke <dkleinecke@gmail.com> - 2018-04-06 00:15 -0700
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-06 02:19 -0700
Re: "C's Biggest Mistake" GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-04-06 17:19 +0200
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-05 11:51 +0100
Re: "C's Biggest Mistake" supercat@casperkitty.com - 2018-04-05 08:56 -0700
Re: "C's Biggest Mistake" John Bode <jfbode1029@gmail.com> - 2018-04-05 14:25 -0700
Re: "C's Biggest Mistake" "Bill Davy" <Bill@XchelSys.co.uk> - 2018-04-06 08:07 +0100
Re: "C's Biggest Mistake" GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-04-05 04:48 +0200
Re: "C's Biggest Mistake" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-04-03 20:40 -0700
Re: "C's Biggest Mistake" Melzzzzz <Melzzzzz@zzzzz.com> - 2018-04-04 03:51 +0000
Re: "C's Biggest Mistake" mark.bluemel@gmail.com - 2018-04-04 04:33 -0700
Re: "C's Biggest Mistake" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-04-04 05:05 -0700
Re: "C's Biggest Mistake" Reinhardt Behm <rbehm@hushmail.com> - 2018-04-04 21:40 +0800
Re: "C's Biggest Mistake" supercat@casperkitty.com - 2018-04-04 09:09 -0700
Re: "C's Biggest Mistake" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-04-04 09:24 -0700
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-04 09:27 -0700
Re: "C's Biggest Mistake" Wouter Verhelst <w@uter.be> - 2018-04-04 12:14 +0200
Re: "C's Biggest Mistake" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-04-04 06:53 -0700
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-04 15:22 +0100
Re: "C's Biggest Mistake" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-04-04 07:33 -0700
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-04 16:22 +0100
Re: "C's Biggest Mistake" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-04-04 08:46 -0700
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-04 17:39 +0100
Re: "C's Biggest Mistake" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-04-04 10:04 -0700
Re: "C's Biggest Mistake" supercat@casperkitty.com - 2018-04-04 12:32 -0700
Re: "C's Biggest Mistake" Rosario19 <Ros@invalid.invalid> - 2018-04-04 07:55 +0200
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-04 11:39 +0100
Re: "C's Biggest Mistake" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-04-04 11:29 +0000
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-04 14:02 +0100
Re: "C's Biggest Mistake" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-04-04 14:37 +0000
Re: "C's Biggest Mistake" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-04-04 07:41 -0700
Re: "C's Biggest Mistake" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-04-04 19:00 +0000
Re: "C's Biggest Mistake" Thiago Adams <thiago.adams@gmail.com> - 2018-04-04 09:48 -0700
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-04 18:24 +0100
Re: "C's Biggest Mistake" Melzzzzz <Melzzzzz@zzzzz.com> - 2018-04-04 17:27 +0000
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-04 19:37 +0100
Re: "C's Biggest Mistake" Melzzzzz <Melzzzzz@zzzzz.com> - 2018-04-04 20:25 +0000
Re: "C's Biggest Mistake" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-04-04 13:29 -0700
Re: "C's Biggest Mistake" luser droog <luser.droog@gmail.com> - 2018-04-04 13:38 -0700
Re: "C's Biggest Mistake" supercat@casperkitty.com - 2018-04-04 14:15 -0700
Re: "C's Biggest Mistake" Thiago Adams <thiago.adams@gmail.com> - 2018-04-04 16:03 -0700
Re: "C's Biggest Mistake" Thiago Adams <thiago.adams@gmail.com> - 2018-04-04 16:35 -0700
Re: "C's Biggest Mistake" supercat@casperkitty.com - 2018-04-05 08:47 -0700
Re: "C's Biggest Mistake" "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2018-04-13 20:43 +0200
Re: "C's Biggest Mistake" Melzzzzz <Melzzzzz@zzzzz.com> - 2018-04-13 19:47 +0000
Re: "C's Biggest Mistake" scott@slp53.sl.home (Scott Lurndal) - 2018-04-04 16:36 +0000
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-04 19:59 +0100
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-04 12:04 -0700
Re: "C's Biggest Mistake" Wouter Verhelst <w@uter.be> - 2018-04-05 16:04 +0200
Re: "C's Biggest Mistake" jameskuyper@verizon.net - 2018-04-05 07:33 -0700
Re: "C's Biggest Mistake" Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2018-04-05 18:17 +0200
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-05 18:15 +0100
Re: "C's Biggest Mistake" Wouter Verhelst <w@uter.be> - 2018-04-05 22:59 +0200
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-06 00:33 +0100
Re: "C's Biggest Mistake" David Brown <david.brown@hesbynett.no> - 2018-04-06 16:47 +0200
Re: "C's Biggest Mistake" supercat@casperkitty.com - 2018-04-05 16:52 -0700
Re: "C's Biggest Mistake" David Brown <david.brown@hesbynett.no> - 2018-04-06 16:41 +0200
Re: "C's Biggest Mistake" "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2018-04-13 20:34 +0200
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-13 21:04 +0100
Re: "C's Biggest Mistake" Ed Kellett <e@kellett.im> - 2018-04-13 21:24 +0100
Re: "C's Biggest Mistake" scott@slp53.sl.home (Scott Lurndal) - 2018-04-13 21:24 +0000
Re: "C's Biggest Mistake" Melzzzzz <Melzzzzz@zzzzz.com> - 2018-04-13 21:41 +0000
Re: "C's Biggest Mistake" Ian Collins <ian-news@hotmail.com> - 2018-04-14 09:57 +1200
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-14 00:53 +0100
Re: "C's Biggest Mistake" Ian Collins <ian-news@hotmail.com> - 2018-04-14 12:52 +1200
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-14 12:20 +0100
Re: "C's Biggest Mistake" Ian Collins <ian-news@hotmail.com> - 2018-04-15 00:37 +1200
Re: "C's Biggest Mistake" Melzzzzz <Melzzzzz@zzzzz.com> - 2018-04-14 15:36 +0000
Re: "C's Biggest Mistake" Ian Collins <ian-news@hotmail.com> - 2018-04-15 10:20 +1200
Re: "C's Biggest Mistake" Melzzzzz <Melzzzzz@zzzzz.com> - 2018-04-14 23:08 +0000
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-15 02:14 +0100
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-14 22:36 -0700
Re: "C's Biggest Mistake" "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2018-04-14 13:54 +0200
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-14 05:56 -0700
Re: "C's Biggest Mistake" bartc <bc@freeuk.com> - 2018-04-14 14:00 +0100
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-14 06:43 -0700
Re: "C's Biggest Mistake" Melzzzzz <Melzzzzz@zzzzz.com> - 2018-04-14 15:37 +0000
Re: "C's Biggest Mistake" "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2018-04-14 18:48 +0200
Re: "C's Biggest Mistake" "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2018-04-14 18:46 +0200
Re: "C's Biggest Mistake" Melzzzzz <Melzzzzz@zzzzz.com> - 2018-04-14 15:35 +0000
Re: "C's Biggest Mistake" "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2018-04-14 18:51 +0200
Re: "C's Biggest Mistake" David Kleinecke <dkleinecke@gmail.com> - 2018-04-13 14:10 -0700
Re: "C's Biggest Mistake" Keith Thompson <kst-u@mib.org> - 2018-04-13 14:32 -0700
Re: "C's Biggest Mistake" David Kleinecke <dkleinecke@gmail.com> - 2018-04-13 15:58 -0700
Re: "C's Biggest Mistake" Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-08 22:04 -0700
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-08 23:23 -0700
Re: "C's Biggest Mistake" "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2018-04-13 20:38 +0200
Re: "C's Biggest Mistake" Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-16 21:39 -0700
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-16 22:39 -0700
Re: "C's Biggest Mistake" "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-04-05 01:03 +0800
Re: "C's Biggest Mistake" David Brown <david.brown@hesbynett.no> - 2018-04-05 12:47 +0200
Re: "C's Biggest Mistake" fir <profesor.fir@gmail.com> - 2018-04-05 15:29 -0700
Re: "C's Biggest Mistake" fir <profesor.fir@gmail.com> - 2018-04-05 16:10 -0700
Re: "C's Biggest Mistake" fir <profesor.fir@gmail.com> - 2018-04-07 08:00 -0700
Re: "C's Biggest Mistake" "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2018-04-11 08:08 +0200
Re: "C's Biggest Mistake" supercat@casperkitty.com - 2018-04-11 08:39 -0700
Re: "C's Biggest Mistake" benleggiero@gmail.com - 2018-04-26 20:40 -0700
Re: "C's Biggest Mistake" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-26 22:50 -0700
Page 1 of 16 [1] 2 3 … 16 Next page →
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-04 00:32 +0100 |
| Subject | "C's Biggest Mistake" |
| Message-ID | <daUwC.190724$oa6.85775@fx33.am4> |
This is a quote from Walter Bright**: "C's biggest mistake is: Conflating pointers with arrays." This is something I've frequently made clear I thought was a very bad idea, but I've been given endless grief about it, been insulted, called a troll and all the rest. Now someone fairly well respected says the same thing. (He's the creator of the D language, so may be a little biased, but is not pushing D in that article.) (**http://www.drdobbs.com/architecture-and-design/cs-biggest-mistake/228701625) -- bartc
[toc] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2018-04-03 23:43 +0000 |
| Message-ID | <ikUwC.213627$Oy5.45737@fx11.am4> |
| In reply to | #128674 |
On 2018-04-03, bartc <bc@freeuk.com> wrote: > This is a quote from Walter Bright**: > > "C's biggest mistake is: Conflating pointers with arrays." > > This is something I've frequently made clear I thought was a very bad > idea, but I've been given endless grief about it, been insulted, called > a troll and all the rest. > > Now someone fairly well respected says the same thing. (He's the creator > of the D language, so may be a little biased, but is not pushing D in > that article.) > > > > (**http://www.drdobbs.com/architecture-and-design/cs-biggest-mistake/228701625) > I don't think he is right. There are means to pass arrays in C - via structures... -- press any key to continue or any other to quit...
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2018-04-03 20:25 -0700 |
| Message-ID | <9c7013a2-17bd-4f94-a378-1c45151d0d45@googlegroups.com> |
| In reply to | #128674 |
On Tuesday, April 3, 2018 at 6:32:40 PM UTC-5, Bart wrote: > This is a quote from Walter Bright**: > > "C's biggest mistake is: Conflating pointers with arrays." > > This is something I've frequently made clear I thought was a very bad > idea, but I've been given endless grief about it, been insulted, called > a troll and all the rest. > > Now someone fairly well respected says the same thing. (He's the creator > of the D language, so may be a little biased, but is not pushing D in > that article.) > > > > (**http://www.drdobbs.com/architecture-and-design/cs-biggest-mistake/228701625) > > -- > bartc Ritchie wanted to keep B's array semantics, but didn't want to materialize the pointer that B required. So he created the rule that array expressions decay to pointer expressions in most contexts. That's not necessarily a mistake. Adjusting 'a[N]' and 'a[]' to '*a' in function parameter declarations was, though. But that's not C's *biggest* mistake. C's *biggest* mistake is using '=' for assignment and '==' for equality, where one can be easily confused for the other yet still be valid in that context. A whole category of bugs would never have existed had Ritchie decided to use ':=' for assignment.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-04-04 08:33 -0700 |
| Message-ID | <4832d9ad-8ef1-412d-9f24-49bd6463374a@googlegroups.com> |
| In reply to | #128676 |
On Tuesday, April 3, 2018 at 10:25:24 PM UTC-5, John Bode wrote:
> On Tuesday, April 3, 2018 at 6:32:40 PM UTC-5, Bart wrote:
> > This is a quote from Walter Bright**:
> >
> > "C's biggest mistake is: Conflating pointers with arrays."
> >
> > This is something I've frequently made clear I thought was a very bad
> > idea, but I've been given endless grief about it, been insulted, called
> > a troll and all the rest.
> >
> > Now someone fairly well respected says the same thing. (He's the creator
> > of the D language, so may be a little biased, but is not pushing D in
> > that article.)
> >
> >
> >
> > (**http://www.drdobbs.com/architecture-and-design/cs-biggest-mistake/228701625)
> >
> > --
> > bartc
>
> Ritchie wanted to keep B's array semantics, but didn't want to materialize the pointer that
> B required. So he created the rule that array expressions decay to pointer expressions
> in most contexts. That's not necessarily a mistake.
>
> Adjusting 'a[N]' and 'a[]' to '*a' in function parameter declarations was, though.
>
> But that's not C's *biggest* mistake. C's *biggest* mistake is using '=' for assignment
> and '==' for equality, where one can be easily confused for the other yet still be valid in
> that context. A whole category of bugs would never have existed had Ritchie decided to
> use ':=' for assignment.
Accepting array-type declarations for function parameters but treating them
as synonymous with pointer types was an unforced error, especially in new-
style declarations.
A bigger mistake was probably the rationale given for the answer to DR028.
If that rationale had said that lvalues which are derived from other
lvalues may only be used to access the parent in contexts where they do
not alias anything else, that would have clarified the issue nicely.
Instead, the rationale suggests that because writing an "int" and reading
a "float" via union as Implementation-Defined behavior, doing so via
pointers has Undefined Behavior. Not only is that a total non-sequitur,
but it suggests that cases which would not involve Implementation-Defined
behavior should have defined behavior.
If the response had indicated that, given e.g.
struct s1 {int x;};
struct s2 {int x;};
int test1(struct s1 *p1, struct s2 *p2)
{
if (p1->x)
p2->x=4;
return p1->x;
}
int test2(struct s1 *p1, struct s1 *p2)
{
if (p1->x)
{
struct s2 *p2b = (struct s2*)p2;
p2b->x=4;
}
return p1->x;
}
a compiler would be entitled to assume that p1 and p2 would not alias in
test1, but would not be entitled to such an assumption in test2, that
would have avoided the need for the silly "Effective type" rules that add
extra complexity while doing nothing to clarify anything.
[toc] | [prev] | [next] | [standalone]
| From | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| Date | 2018-04-04 15:46 -0500 |
| Message-ID | <pa3diq$3or$1@dont-email.me> |
| In reply to | #128676 |
On 4/3/2018 10:25 PM, John Bode wrote: > On Tuesday, April 3, 2018 at 6:32:40 PM UTC-5, Bart wrote: >> This is a quote from Walter Bright**: >> >> "C's biggest mistake is: Conflating pointers with arrays." >> >> This is something I've frequently made clear I thought was a very bad >> idea, but I've been given endless grief about it, been insulted, called >> a troll and all the rest. >> >> Now someone fairly well respected says the same thing. (He's the creator >> of the D language, so may be a little biased, but is not pushing D in >> that article.) >> >> >> >> (**http://www.drdobbs.com/architecture-and-design/cs-biggest-mistake/228701625) >> >> -- >> bartc > > Ritchie wanted to keep B's array semantics, but didn't want to materialize the pointer that > B required. So he created the rule that array expressions decay to pointer expressions > in most contexts. That's not necessarily a mistake. > > Adjusting 'a[N]' and 'a[]' to '*a' in function parameter declarations was, though. > > But that's not C's *biggest* mistake. C's *biggest* mistake is using '=' for assignment > and '==' for equality, where one can be easily confused for the other yet still be valid in > that context. A whole category of bugs would never have existed had Ritchie decided to > use ':=' for assignment. +1 Lynn
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-04 22:56 +0100 |
| Message-ID | <PRbxC.289512$sQ.267243@fx38.am4> |
| In reply to | #128676 |
On 04/04/2018 04:25, John Bode wrote:
> Ritchie wanted to keep B's array semantics, but didn't want to materialize the pointer that
> B required. So he created the rule that array expressions decay to pointer expressions
> in most contexts. That's not necessarily a mistake.
>
> Adjusting 'a[N]' and 'a[]' to '*a' in function parameter declarations was, though.
>
> But that's not C's *biggest* mistake. C's *biggest* mistake is using '=' for assignment
> and '==' for equality, where one can be easily confused for the other yet still be valid in
> that context. A whole category of bugs would never have existed had Ritchie decided to
> use ':=' for assignment.
There are some many instances of bad design choices introducing more
opportunity for errors that it is hard to choose.
A selection (some have since been tightened up or compiler options or
special tools exist to help detect them):
* Allowing = and == within the same expression you've mentioned
* Allowing a==b or a+b as a statement was probably an error, but is not
picked up
* Allowing a=0; at module level declares an int variable, but is likely
a stray statement
* Calling fn(10) without a prototype (allows further calls with any mix
of arguments)
* Allowing an empty parameter list in a function declaration also allows
the function to be called with any arguments
* int a; at module scope will automatically export the name. Which can
then clash with a 'char* a' declared in another module giving
interesting results/
* /*..*/ comments don't nested. (Miss out the 2nd */, and a swathe of
code up to the closing */ of the next comment is missed out. Often with
no error reported.
* Try out this comment: // path c:\dir\
and the next line is ignored.
* Block braces around 0/1 statements are optional, which lead to another
class of errors when missing/extra braces match up with the wrong ones.
* Dangling else can be another consequence of optional braces.
* Or adding an extra statement here just before stmt1 and you don't
notice there are no braces:
else
stmt1;
* Or you have a rogue semicolon: for(i=0; i<n; ++i); {...} and your loop
completes more quickly than you expect.
* Numbers that start with a leading zero are octal
* char can be signed, as you might find out here:
char table[256],c; ++table[c];
* Pointers can be indexed, even when they don't point into an array: int
a, p=&a; p[1234];
* Arrays can be dereferenced: int A[10]; *A; (Maybe you did want A[0],
or maybe you've got an array and pointer mixed up; the language can't
detect that blatant error.)
* int* p,q,r; probably doesn't do what you think
* Neither does a==b==c
* The '*p=0' in 'int *p=0;' doesn't do the same as here: "*p=0'.
* Lack of proper for loop: for (i=0; i<n; ++j) provides more error
opportunities.
* Need to break out of every switch case block (easy to forget)
* Need to break out of a loop, but you forget you're inside a switch
statement
* Need to break from switch, but forget you're inside a loop.
* You misspell 'default:' in a switch as: 'defualt:' (still compiles;
different behaviour)
* Poor precedence choices: 'a<<3 + 1', and too many of them.
* No built-in mix/max so people write macros used like this: MAX(++a,b)
* No named constants so people can write: #define K a+b (missing
parentheses so expressions can go badly wrong; can't happen with the
correct feature)
That's a couple of dozen features that can lead to errors in C that
probably wouldn't in another language. I have a feeling there are plenty
more, and I haven't really touched on things to do with the macro
processor or other areas of the language.
But I think everyone knows C has these problems and yet it is still
successful....
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2018-04-05 00:45 +0200 |
| Message-ID | <pa3kin$ddm$1@dont-email.me> |
| In reply to | #128729 |
Le 04/04/2018 à 23:56, bartc a écrit :
> On 04/04/2018 04:25, John Bode wrote:
>
>> Ritchie wanted to keep B's array semantics, but didn't want to
>> materialize the pointer that
>> B required. So he created the rule that array expressions decay to
>> pointer expressions
>> in most contexts. That's not necessarily a mistake.
>>
>> Adjusting 'a[N]' and 'a[]' to '*a' in function parameter declarations
>> was, though.
>>
Yes, it was a mistake. Arrays aren't pointers.
>> But that's not C's *biggest* mistake. C's *biggest* mistake is using
>> '=' for assignment
>> and '==' for equality, where one can be easily confused for the other
>> yet still be valid in
>> that context. A whole category of bugs would never have existed had
>> Ritchie decided to
>> use ':=' for assignment.
>
Could be, I have no data to confirm that. Personally, that doesn't
bother me after all these years programming in C, but of course I am
biased now.
> There are some many instances of bad design choices introducing more
> opportunity for errors that it is hard to choose.
>
> A selection (some have since been tightened up or compiler options or
> special tools exist to help detect them):
>
> * Allowing = and == within the same expression you've mentioned
>
Most people are aware of that, it is not that difficult to spot. But
those are bugs not very difficult to correct. Yes, a Pascal like
assignment would be better. An improvement would be to declare assignment as
a:=b;
and a == b foe equal:ity and the "=" with assignment meaning would be
banned. And there would be no compatibility problems since old code
would not declare
#define STDC_ASSIGNMENT 1
> * Allowing a==b or a+b as a statement was probably an error, but is not
> picked up
>
This is of course not an error. Why would those operations not yield a
result value? And how would you badd two numbers?
This habit of ranting randomly.
> * Allowing a=0; at module level declares an int variable, but is likely
> a stray statement
>
That is banned since YEARS... No implicit int stuff!
> * Calling fn(10) without a prototype (allows further calls with any mix
> of arguments)
>
Very useful if you have an interface through a function pointer that can
receive any mix of data!
> * Allowing an empty parameter list in a function declaration also allows
> the function to be called with any arguments
>
Yes, so what? If you want it, C gives it to you.
> * int a; at module scope will automatically export the name. Which can
> then clash with a 'char* a' declared in another module giving
> interesting results/
>
So what?
Name clashes will plague ANY language and C is not any exception.
> * /*..*/ comments don't nested. (Miss out the 2nd */, and a swathe of
> code up to the closing */ of the next comment is missed out. Often with
> no error reported.
>
> * Try out this comment: // path c:\dir\
> and the next line is ignored.
>
Old cruft. Yes, that should be banned: continuation blackslashes in //
comments. It is a bug we inherit from the old C++ days... they didn't
thought it out.
> * Block braces around 0/1 statements are optional, which lead to another
> class of errors when missing/extra braces match up with the wrong ones.
>
That's two different styles, and is not really an error in the language
unless you abuse that...
> * Dangling else can be another consequence of optional braces.
>
Yes, that's why in many cases I prefer writing the braces down.
> * Or adding an extra statement here just before stmt1 and you don't
> notice there are no braces:
>
> else
> stmt1;
>
> * Or you have a rogue semicolon: for(i=0; i<n; ++i); {...} and your loop
> completes more quickly than you expect.
>
Yes, but all those "bugs" are just when you wite nonsense. Try not, take
a cup of coffe, and read what you write twice.
> * Numbers that start with a leading zero are octal
>
Obsolete. Yes, should be banned.
> * char can be signed, as you might find out here:
> char table[256],c; ++table[c];
>
Yes, the characters can be "signed" and that's a source of unnecessary
bugs since ages. No real character type, just small signed numbers.
> * Pointers can be indexed, even when they don't point into an array: int
> a, p=&a; p[1234];
>
No error checking yes, C is for people that take care of details like that.
> * Arrays can be dereferenced: int A[10]; *A; (Maybe you did want A[0],
> or maybe you've got an array and pointer mixed up; the language can't
> detect that blatant error.)
>
I always use that error. In the qfloat package, I declare always
Qfloat a[1],B[1];
I access those with:
a[0].exponent
oe
a[0].sign
That way, all functions receive always a pointer, I force passing by
reference
qadd(a,b,c);
all data is passed by reference. An array IS a pointer when the size of
the array is ONE.
[rest of rant ellided]
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2018-04-04 23:07 +0000 |
| Message-ID | <slrnpcamlk.eu5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #128730 |
On Wed, 2018-04-04, jacobnavia wrote: > Le 04/04/2018 à 23:56, bartc a écrit : ... >> * int a; at module scope will automatically export the name. Which can >> then clash with a 'char* a' declared in another module giving >> interesting results/ > > So what? > > Name clashes will plague ANY language and C is not any exception. Well, C is a lot worse than many others, like Python and its modules, and C++ with its classes and namespaces. You end up prefixing all names according to some scheme, and that's uncommon in languages today. If there /is/ a big mistake in C, IMHO this might be it. [snip stuff I pretty much agree with] /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-05 01:29 +0100 |
| Message-ID | <W5exC.503244$Jj7.120772@fx45.am4> |
| In reply to | #128730 |
On 04/04/2018 23:45, jacobnavia wrote:
> Le 04/04/2018 à 23:56, bartc a écrit :
>> * Allowing a==b or a+b as a statement was probably an error, but is
>> not picked up
>>
>
> This is of course not an error. Why would those operations not yield a
> result value? And how would you badd two numbers?
Usually you would want to do something with the result, such as:
x=a+b;
f(a+b);
*(a+b)=0;
but what is the purpose of:
a+b;
or even:
a;
The chances are the programmer made a mistake or left something out. The
problem is that it is legal C.
> This habit of ranting randomly.
>
>> * Allowing a=0; at module level declares an int variable, but is
>> likely a stray statement
>>
>
> That is banned since YEARS... No implicit int stuff!
I just tried a=0; at module level with six C compilers with default
options; none of them report an error (three show a warning, three say
nothing). Not much of a ban!
(I tried a seventh C compiler and that did report an error; that was mine.)
>> * Calling fn(10) without a prototype (allows further calls with any
>> mix of arguments)
>>
> Very useful if you have an interface through a function pointer that can
> receive any mix of data!
>
>> * Allowing an empty parameter list in a function declaration also
>> allows the function to be called with any arguments
>>
>
> Yes, so what? If you want it, C gives it to you.
But its arguments can't be checked and therefore it's dangerous. And
with code like this:
void fred();
fred();
fred(10,20,30);
fred("abc",7.9);
fred(1,1,1,1,1,1,1,1,1,1,1,1,1);
It's most unlikely that all these are correct. But out of the six
compilers, only one reports an error (and mine of course).
> * int a; at module scope will automatically export the name. Which can
>> then clash with a 'char* a' declared in another module giving
>> interesting results/
>>
>
> So what?
>
> Name clashes will plague ANY language and C is not any exception.
How many will AUTOMATICALLY export any name unless you explicitly mark
it as local? So you aren't even aware of the problem except that that
program crashes or has an obscure bug.
(Other languages might also decorate exported names so that they are
specific to their home modules, and it becomes possible to use what
appear to be the same names. So modules A and B share global X, which
belongs to A, and C and D also share X that belongs to C. But the first
X is really A.X and the second is C.X.)
> Yes, but all those "bugs" are just when you wite nonsense. Try not, take
> a cup of coffe, and read what you write twice.
I had EXACTLY the bug with the rogue semicolon the other day.
Fortunately it was a small program and I found it quickly.
>> * Pointers can be indexed, even when they don't point into an array:
>> int a, p=&a; p[1234];
>>
>
> No error checking yes, C is for people that take care of details like that.
Well, if someone really wants to do this sort of stuff, they can write
the access as:
*(p+1234);
They don't need to make it look like an array access. If this was
enforced then if somebody did ACCIDENTALLY access a pointer as array
then it would be picked up.
As it is, more chance for obscure bugs.
>> * Arrays can be dereferenced: int A[10]; *A; (Maybe you did want A[0],
>> or maybe you've got an array and pointer mixed up; the language can't
>> detect that blatant error.)
>>
>
> I always use that error. In the qfloat package, I declare always
>
> Qfloat a[1],B[1];
>
> I access those with:
>
> a[0].exponent
> oe
> a[0].sign
But you don't use *a? Then that's not the problem.
Using *A when A is an array should raise eyebrows. But it is legal C.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2018-04-06 00:10 +0200 |
| Message-ID | <pa66sa$4bk$1@dont-email.me> |
| In reply to | #128738 |
Le 05/04/2018 à 02:29, bartc a écrit : > but what is the purpose of: > > a+b; > > or even: > > a; > > The chances are the programmer made a mistake or left something out. The > problem is that it is legal C. The set of C programs is infinite. In this big set, there are a set of programs where a programmer mistake is present. For instance: int a , b, c; b+c; instead of a=b+c; or worst z = a+b; where a was intended but in the keyboard a and z were near, as in the french keyboard. All those programs are legal C programs. Most compilers complain with a warning at a+b; but will accept z=a+b; if z is another int somewhere. No warnings, and z now has the value that a should hev had. And there is NO language that will solve typing mistakes. In your language if I mistake something for something else, mistype a variable, forget a counter increment or whatever, the program will fail. Yes, programming in any computer language needs precision, mistakes are not allowed. Neither in your language nor C nor in anything.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-05 23:48 +0100 |
| Message-ID | <2JxxC.528086$8G7.406673@fx36.am4> |
| In reply to | #128814 |
On 05/04/2018 23:10, jacobnavia wrote: > Le 05/04/2018 à 02:29, bartc a écrit : > The set of C programs is infinite. In this big set, there are a set of > programs where a programmer mistake is present. Yes, and the idea is to limit the number of correct programs as much as possible, so it is easier to catch incorrect ones. You unnecessarily want to increase the number of programs the compiler will pass, on the off-chance the program /might/ be writing that funny looking code on purpose. > In your language if I mistake something for something else, mistype a > variable, forget a counter increment or whatever, the program will fail. > Yes, programming in any computer language needs precision, mistakes are > not allowed. Neither in your language nor C nor in anything. Yes, you can write wrong code in my language. But the number of ways of doing so is vastly smaller than in C because there are more restrictions, yet without reducing the expressiveness of the language. All of those two dozen or so points I listed yesterday, none will ever be a problem in my language because of more sensible design decisions. And I could list two dozen more. Take one example in C: int (*a)[10]; // pointer to array of 10 int int *b[10]; // array of 10 pointer to int int i, j, x; You access that final int in each of a and b as follows, assuming both have been initialised: x = (*a)[i]; // dereference then index x = *b[i]; // index then dereference So far that's straightforward. The access method matches the declaration. But now see what happens when you mix up the access methods: x = *a[i]; // index the pointer, then deref the array x = (*b)[i]; // deref the array, then index the pointer x = **a; // deref the pointer then deref the array x = a[i][j]; // index the pointer and index the array x = **b; // Same thing on b, even though the type x = b[i][j]; // is different Unbelievably, these all still compile. But they are all wrong and the program will likely crash. But C is incapable of telling you that because it has stupidly mixed up arrays and pointers (this was one part of Walter Bright's complaint). Complain about it here, and people will tell you you don't understand C. Understand it or not, C lets you do this. Now see how it works in my language: ref [10]int a # pointer to array of 10 int [10]ref int b # array of 10 pointer to int int i,j,x; x := a^[i] # deref then index x := b[i]^ # index then deref That's fine (you might notice the comments are not really necessary as the syntax is much more obvious). Now we try and mix it up like the C: x := a[i]^ # ERROR x := b^[i] # ERROR etc a can't be indexed as it's a pointer. b can't be dereferenced as it's an array. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-04-05 13:31 +0000 |
| Message-ID | <6zpxC.75432$bz1.69868@fx01.iad> |
| In reply to | #128729 |
bartc <bc@freeuk.com> writes: >* Try out this comment: // path c:\dir\ > and the next line is ignored. That's a microsoft made a really stupid choice for path separators.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2018-04-05 09:48 -0500 |
| Message-ID | <kgdccdh2i0vdi47i3r30njj2tb1q534dj5@4ax.com> |
| In reply to | #128767 |
On Thu, 05 Apr 2018 13:31:46 GMT, scott@slp53.sl.home (Scott Lurndal) wrote: >bartc <bc@freeuk.com> writes: > >>* Try out this comment: // path c:\dir\ >> and the next line is ignored. > >That's a microsoft made a really stupid choice >for path separators. That's really blaming the victim. Whatever MS's faults may be, are you seriously going to argue that their filename syntax should have had compatibility with C's line continuation syntax** as a prime concern? Back in 1983? **And when combined with C++ style line oriented comments?
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2018-04-08 16:37 -0700 |
| Message-ID | <kfnd0z9e0ct.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #128781 |
Robert Wessel <robertwessel2@yahoo.com> writes: > On Thu, 05 Apr 2018 13:31:46 GMT, scott@slp53.sl.home (Scott Lurndal) > wrote: > >> bartc <bc@freeuk.com> writes: >> >>> * Try out this comment: // path c:\dir\ >>> and the next line is ignored. >> >> That's a microsoft made a really stupid choice >> for path separators. > > That's really blaming the victim. Whatever MS's faults may be, are > you seriously going to argue that their filename syntax should have > had compatibility with C's line continuation syntax as a prime > concern? Back in 1983? IMO Microsoft deserves at least part of the blame, for two reasons: one, it isn't just C, but also for example most unix shells; and two, Microsoft has a history of deliberate incompatibilities (and even known to be technically inferior ones) introduced purely for business reasons. If I thought it was an honest mistake I might be willing to let them off the hook. Judging from their history though an honest mistake seems unlikely.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-04-08 18:58 -0700 |
| Message-ID | <ln1sfpp2d8.fsf@kst-u.example.com> |
| In reply to | #128979 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Robert Wessel <robertwessel2@yahoo.com> writes:
>> On Thu, 05 Apr 2018 13:31:46 GMT, scott@slp53.sl.home (Scott Lurndal)
>> wrote:
>>> bartc <bc@freeuk.com> writes:
>>>> * Try out this comment: // path c:\dir\
>>>> and the next line is ignored.
>>>
>>> That's a microsoft made a really stupid choice
>>> for path separators.
>>
>> That's really blaming the victim. Whatever MS's faults may be, are
>> you seriously going to argue that their filename syntax should have
>> had compatibility with C's line continuation syntax as a prime
>> concern? Back in 1983?
>
> IMO Microsoft deserves at least part of the blame, for two
> reasons: one, it isn't just C, but also for example most unix
> shells; and two, Microsoft has a history of deliberate
> incompatibilities (and even known to be technically inferior
> ones) introduced purely for business reasons. If I thought it
> was an honest mistake I might be willing to let them off the
> hook. Judging from their history though an honest mistake seems
> unlikely.
If I recall correctly, early versions of MS-DOS didn't have
directories, but did use '/' to introduce command-line options
(as Unix commonly uses '-'), something it shared with other
operating systems (including VMS, but I don't know whether there's
a connection there). When directory support was added, using '/'
both to introduce command-line options and as a directory delimiter
would have been unreasonably confusing. In that context, using
'\' as a directory delimiter was probably a reasonable decision.
By the time MS-DOS/Windows, Unix, and C started interacting with
each other, it was too late to make them behave consistently.
--
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 | already5chosen@yahoo.com |
|---|---|
| Date | 2018-04-09 00:56 -0700 |
| Message-ID | <eb93e7e0-1978-4af5-aecc-bb2aa957a9c5@googlegroups.com> |
| In reply to | #128984 |
On Monday, April 9, 2018 at 4:58:36 AM UTC+3, Keith Thompson wrote: > Tim Rentsch <txr@alumni.caltech.edu> writes: > > Robert Wessel <robertwessel2@yahoo.com> writes: > >> On Thu, 05 Apr 2018 13:31:46 GMT, scott@slp53.sl.home (Scott Lurndal) > >> wrote: > >>> bartc <bc@freeuk.com> writes: > >>>> * Try out this comment: // path c:\dir\ > >>>> and the next line is ignored. > >>> > >>> That's a microsoft made a really stupid choice > >>> for path separators. > >> > >> That's really blaming the victim. Whatever MS's faults may be, are > >> you seriously going to argue that their filename syntax should have > >> had compatibility with C's line continuation syntax as a prime > >> concern? Back in 1983? > > > > IMO Microsoft deserves at least part of the blame, for two > > reasons: one, it isn't just C, but also for example most unix > > shells; and two, Microsoft has a history of deliberate > > incompatibilities (and even known to be technically inferior > > ones) introduced purely for business reasons. If I thought it > > was an honest mistake I might be willing to let them off the > > hook. Judging from their history though an honest mistake seems > > unlikely. > > If I recall correctly, early versions of MS-DOS didn't have > directories, but did use '/' to introduce command-line options > (as Unix commonly uses '-'), something it shared with other > operating systems (including VMS, but I don't know whether there's > a connection there). Most likely, there is a connection through common ancestor. MS-DOS inherited the syntax from PC/M, which, in turn, copied it from either RT-11 or RSX-11. VMS inherited it directly from RSX-11. A non-trivial question here is not why MS-DOS used / as an option prefix, but why Unix didn't. > When directory support was added, using '/' > both to introduce command-line options and as a directory delimiter > would have been unreasonably confusing. In that context, using > '\' as a directory delimiter was probably a reasonable decision. > By the time MS-DOS/Windows, Unix, and C started interacting with > each other, it was too late to make them behave consistently. > > -- > 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 | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-04-09 01:59 -0700 |
| Message-ID | <d0254a7d-c837-4360-b35c-b708db6896fa@googlegroups.com> |
| In reply to | #128991 |
On Monday, April 9, 2018 at 12:57:07 AM UTC-7, already...@yahoo.com wrote: > On Monday, April 9, 2018 at 4:58:36 AM UTC+3, Keith Thompson wrote: > > Tim Rentsch <txr@alumni.caltech.edu> writes: > > > Robert Wessel <robertwessel2@yahoo.com> writes: > > >> On Thu, 05 Apr 2018 13:31:46 GMT, scott@slp53.sl.home (Scott Lurndal) > > >> wrote: > > >>> bartc <bc@freeuk.com> writes: > > >>>> * Try out this comment: // path c:\dir\ > > >>>> and the next line is ignored. > > >>> > > >>> That's a microsoft made a really stupid choice > > >>> for path separators. > > >> > > >> That's really blaming the victim. Whatever MS's faults may be, are > > >> you seriously going to argue that their filename syntax should have > > >> had compatibility with C's line continuation syntax as a prime > > >> concern? Back in 1983? > > > > > > IMO Microsoft deserves at least part of the blame, for two > > > reasons: one, it isn't just C, but also for example most unix > > > shells; and two, Microsoft has a history of deliberate > > > incompatibilities (and even known to be technically inferior > > > ones) introduced purely for business reasons. If I thought it > > > was an honest mistake I might be willing to let them off the > > > hook. Judging from their history though an honest mistake seems > > > unlikely. > > > > If I recall correctly, early versions of MS-DOS didn't have > > directories, but did use '/' to introduce command-line options > > (as Unix commonly uses '-'), something it shared with other > > operating systems (including VMS, but I don't know whether there's > > a connection there). > > Most likely, there is a connection through common ancestor. > MS-DOS inherited the syntax from PC/M, which, in turn, copied it from either RT-11 or RSX-11. > VMS inherited it directly from RSX-11. > A non-trivial question here is not why MS-DOS used / as an option prefix, but why Unix didn't. > > > When directory support was added, using '/' > > both to introduce command-line options and as a directory delimiter > > would have been unreasonably confusing. In that context, using > > '\' as a directory delimiter was probably a reasonable decision. > > By the time MS-DOS/Windows, Unix, and C started interacting with > > each other, it was too late to make them behave consistently. > > > > -- > > 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" Promotion is a wonderful thing and consumer stupidity is even better. Only what Jeff Torrey wants matters to Jeff Torrey. There is nothing you or I can do to change that. It's a chance to cause harm and it is what it is. You never take blame for your own actions. Quotes that are easily seen to be trolling. If The Doctor has 'file.txt' open in an editor such as Atom and Jeff Torrey wants to change its name to 'c.txt' via a preset script, The Doctor's suggestion might be good. Zsh shell's update system failed over and over again. How Jeff Torrey figures out when to use his absurd flood script to best emulate the style of The Doctor's posts http://usenet.sandman.net/misc/snit_flood. -- Get Rich Slow! https://prescottareapsychopaths.wordpress.com/shawn-ulman-psychopath https://prescottareapsychopaths.wordpress.com/mark-bilk-psychopath/ Jonas Eklundh
[toc] | [prev] | [next] | [standalone]
| From | mark.bluemel@gmail.com |
|---|---|
| Date | 2018-04-09 02:36 -0700 |
| Message-ID | <e2b5455f-595b-4e7c-91e7-f0201184d332@googlegroups.com> |
| In reply to | #128991 |
On Monday, 9 April 2018 08:57:07 UTC+1, already...@yahoo.com wrote: ... > A non-trivial question here is not why MS-DOS used / as an option > prefix, but why Unix didn't. Unix command syntax seems to be modelled on that of Multics which actually predates (by reading) RSX-11.
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-04-09 03:49 -0700 |
| Message-ID | <4cea169d-8c78-4bad-a130-f8484cd54d3e@googlegroups.com> |
| In reply to | #128993 |
On Monday, April 9, 2018 at 2:36:29 AM UTC-7, mark.b...@gmail.com wrote: > On Monday, 9 April 2018 08:57:07 UTC+1, already...@yahoo.com wrote: > ... > > A non-trivial question here is not why MS-DOS used / as an option > > prefix, but why Unix didn't. > > Unix command syntax seems to be modelled on that of Multics which > actually predates (by reading) RSX-11. With no support at all, as is the norm for Peter Kohlmann. Gee, imagine Peter Kohlmann trying to pin his phooey on me or others, no one has ever seen that before <shrug>. And in reply you have nothing but an attempt to start something. You insisting a lie is real does not make it true. Usenet is a sovereign phenomenon based on the belief in good character that Peter Kohlmann lacks. Right, Peter Kohlmann is seeking to market an HTML variable, which Jolly Roger can get in seconds, that allows him to flood multiple groups. If he wasn't so ignorant he would get how slow he looks ;) If Jolly Roger has 'file.pdf' open in an application such as vim and you want to change its name to 'windows.doc' via a preset script, Jolly Roger's video might be useful. - Curious how these posts are made? Email: fretwizzer@gmail.com
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-09 12:14 +0100 |
| Message-ID | <JWHyC.792395$am7.362798@fx44.am4> |
| In reply to | #128991 |
On 09/04/2018 08:56, already5chosen@yahoo.com wrote: > On Monday, April 9, 2018 at 4:58:36 AM UTC+3, Keith Thompson wrote: >> If I recall correctly, early versions of MS-DOS didn't have >> directories, but did use '/' to introduce command-line options >> (as Unix commonly uses '-'), something it shared with other >> operating systems (including VMS, but I don't know whether there's >> a connection there). > > Most likely, there is a connection through common ancestor. > MS-DOS inherited the syntax from PC/M, which, in turn, copied it from either RT-11 or RSX-11. > VMS inherited it directly from RSX-11. > A non-trivial question here is not why MS-DOS used / as an option prefix, but why Unix didn't. The use of "/" seems to be a DEC thing; maybe they were more popular than Unix at the time. And you might equally ask why Unix used "-" as an option prefix. (My Windows apps use "-" to introduce options (sometimes both "-" and "/" can be chosen from), so that the same instructions work for either OS.) -- bartc
[toc] | [prev] | [next] | [standalone]
Page 1 of 16 [1] 2 3 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web