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-11 08:39 -0700 |
| Articles | 20 on this page of 314 — 39 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
Page 8 of 16 — ← Prev page 1 … 6 7 [8] 9 10 … 16 Next page →
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-04-09 08:14 -0700 |
| Message-ID | <d5131557-2e56-4e58-a868-9cd8147d0564@googlegroups.com> |
| In reply to | #129006 |
On Monday, April 9, 2018 at 7:38:30 AM UTC-7, Tim Rentsch wrote: > Ian Collins <ian-news@hotmail.com> writes: > > > On 04/09/2018 10:21 AM, Tim Rentsch wrote: > > > >> Ian Collins <ian-news@hotmail.com> writes: > >> > >>> If your language is so good, why aren't we all using it while you sit > >>> on a beach enjoying the royalties [...] > >> > >> Your algorithm for flamebait reply prevention is failing some > >> of its tests. > > > > It doesn't have any, [...] > > Well then you better get cracking and write some. Your reputation > as a serious TDD'er is in jeopardy. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Gee, no on saw more forgeries coming. LOL! -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.28 Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWJpfjAAoJEC03b6bOr/+drC0P/RZBxcLK8eFZ7QUKjlqJRqfj 66udasAYnovhi+C1bpBxXZIm8Xxg2+JDdVoMfw/d+5R8+KpEXpxK+4y9GB8NuBBz 98+LuNNIus0cXJ6goCyKZj5FUajHYIhgoEAb+O8F0pYMcqv08R39IddgVEQCasDZ 9QPXlQco0QOSD49BArlDa7qgwi17Rs2zkYnw27jEIVEuYlfhqj2T7Mcirwby4JD3 +1Geq5kCdeCtMG+z6gAdth0akrSMlYLAnixbYolEFm6wtg7DW2BrwVo7NTY8Zuy1 UjRrn8JAoHrCec82HulrBBEXC/dhti2SIszDnt1GnZSTB33p1plQgklUmmqN8Qvu To/TAz07YWAeUHcYSyHzmJuVbL0r9emcQD/AfB8CxAhh+p5F5kc2hfwAOmJ4cGpV +kIqUp7N1UXqSOXnFyxYz4HJv9/c0UPNXSY2QDPmaWd7AFrB80BcOw2yVS30jQwo QhBtvoj2t/FJi/G7KnIpGYl3ZFy7QxtNL6PnPW5y46EjzDbNEnMbETTxAzI24QGw x5xgyhdiyRnpCvyHFd21d09bYOrBHH6qe3NMVTRBPjh1MUaw1E8WhQo916Zvk4jz pD23EIt9uk79a2aD+EbC/vZHLPGTqlbI1bmYV5KlzJusIO2i939Cs/AhYcdM8mEQ WqdC0S1YIC7GfYk7riFe =F3OP -----END PGP SIGNATURE----- -- This Trick Gets Women Hot For You https://youtu.be/GPPqvw8iEBs https://youtu.be/48_DdtLGR9s Jonas Eklundh
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-04-07 18:16 +0200 |
| Message-ID | <paaqsr$6kf$1@dont-email.me> |
| In reply to | #128862 |
On 06/04/18 20:35, bartc wrote:
> On 06/04/2018 16:31, David Brown wrote:
>> On 06/04/18 17:03, bartc wrote:
>
>> "5-2" - yes, people would write that, especially if they hadn't noticed
>> the space key on their keyboard.
>
> Now you're being silly.
I'm exaggerating a bit, of course - but I think it is clearer to write
"5 - 2" than "5-2". Good use of spacing makes code easier to read, and
spaces around binary operators is very common practice.
>
> This is a problem with any hex number that ends with E, that happens to
> be immediately followed by "+" or "-" (followed by anything else; it
> doesn't need to be a constant).
>
> Such as 0xE-1.
>
> You're saying it doesn't matter because some numbers are likely but
> others are less likely to occur? Who are you to say that?
Yes, I am saying it is not a problem because it does not occur often.
How many people actually write hex constants? Very, very few
programmers ever need them - few enough even understand them. Of the
times people write hex constants, how often are these then followed
immediately by a plus or minus operator? A very small fraction. Of
those that write that, how many prefer to crowd their numbers together
instead of spreading them out to make it clearer? Let's give you the
benefit of the doubt and say a sizeable proportion.
And what happens if someone writes a number like that? The compiler
complains, and they have to add a space or two. If this were some
hidden fault, or silently incorrect code, it could be a worry. But here
we are risking that a very small fraction of a tiny number of
programmers might get mildly and briefly confused.
Tell me, how often has this caused trouble for /you/ in your
programming? How often have you heard of it being a problem for others?
>
>> If a compiler "blows up" on reading it, it's a compiler bug. Report it,
>> and it will no doubt be fixed.
>
> No, it's conforming behaviour. But it means it can halt compilation of a
> program that is otherwise completely fine.
So what you are saying is that it is an oddity in the syntax of C. Yes,
it is an oddity - but it is not one that occurs often, nor one that is
difficult to handle for the few people that might meet it.
>
> And if a program is developed with a non-conforming compiler where 0xE-1
> is treated as the value 14-1 or 13 (eg. lccwin, DMC, MSVC and mcc), then
> the problem will raise its head when the program is compiled with a
> conforming one, requiring intervention.
>
> (If you are not the author, then it can mean modifying a large app that
> you don't know.)
>
> > "5-2" - yes, people would write that, especially if they hadn't noticed
> > the space key on their keyboard.
>
> Or the code has been generated rather than typed. Or code that had been
> written as 0xE - 1 has been through a preprocessor that eliminates the
> space. Now that preprocessed code can't be compiled.
>
A preprocessor that eliminates the space? Who is being silly now?
>>
>> Or is there some other problem here?
>
> After reading the above, do you still think it's total non-issue?
Yes - totally and completely. Your tiny dimple of a molehill remains
just that.
>
> Perhaps it doesn't bother you because you always write spaces either
> side of "+" and "-". Oh, that's OK then.
>
>
>> A minor bug in a compiler for a code construct that would be extremely
>> rare, is somehow symptomatic of everything in C?
>
> Odd how I can see consequences of these minor language flaws, while you
> are content to ignore them. I can see you're not a language designer.
>
My language design experience is very small (not non-existent, and I
have done courses on the topic, but limited in practice to a couple of
very niche domain-specific languages).
That does not stop me seeing that this is a very minor language flaw,
with very, very limited consequences.
> The preprocessor is responsible for a lot of these odd behaviours.
>
Frankly, if 0x123e-2 is the best you can come up with, you have not
tried particularly hard. The preprocessor gives lots of scope for
confusion or complication in C programming, and misunderstandings and
misinterpretations amongst compiler writers. The problem areas are
easily avoided, but they do exist.
> As for being extremely rare, you don't know that and neither do I.
Of course they are. Rub a couple of brain cells together, and you will
understand.
> Maybe
> it happens and people deal with it (which by itself is off, in forcing
> people to inject white space when it's supposed to be of no
> significance). Maybe others always use non-conforming compilers.
>
> But it shouldn't exist at all.
>
I agree there - it is an unnecessary quirk in the language. But it is
so inconsequential that the standards committee have never bothered to
fix it. It would involve more work for them than it would save the
world's C programmers combined.
>> If you say so - I can't remember, nor do I care about the details. I do
>> remember that it didn't do the job at hand.
>
> My feature was specifically designed to do the job at hand. And the
> details are taken care of by the language; you just use it.
>
> No such feature exists in C - you have to reinvent it each time.
Or you can look up "x macros" and read about the technique, so that you
don't have to invent it.
>
>> If you want a "batteries included" language, go elsewhere. C is a low
>> level language with small libraries
>
> (Small libraries, really?)
Yes. The C standard library is small compared to most general-purpose
languages.
>
>> and lets you write the details
>> yourself in the way that best suits the task in hand.
>
> Mine is the same, and it has even less included than C.
Your language is not a general-purpose programming language. It is a
specific language made by one person for use by one person for the tasks
that one person needs.
>
> Yet I can write expressions like 0xE-1 with no problem (actually I would
> never even have dreamed it could be a problem). And I can write a
> continued line with a comment without the comment itself being continued.
And how often have you ever felt the need to write 0xE-1 ?
I can see you would want to have line continuations after a line
comment, but that is only because (unlike C) your language needs line
continuations. (That is not a criticism of your choice of making line
endings special - it would not be /my/ choice in a language design, but
I can happily understand why others like it.)
>
>> I am saying that if your code is so complex that it is hard to see what
>> is going on - such as how your "break" statements are working - then the
>> code is too complex.
>
> What, a loop containing nothing but one switch statement is too complex?
> Now I know you're having me on!
>
> In my programs this is so common that there is a special statement for
> it in my language:
>
> doswitch c:=p++^
> when 'A'..'Z', '0'..'9' then
> else
> exit
> end doswitch
(Shudder! A keyword for /that/ ?)
>
> A switch statement, that loops. Hence the need for 'exit' (ie. break).
> No nonsense about being inside a switch so that exit is not possible.
>
> It's not possible to break down this statement into smaller bits.
>
> BTW the full C version of this would look like this:
>
> while (1)
> switch (c=*p++) {
> case 'A': case 'B': case 'C': case 'D': case 'E': case 'F':
> case 'G': case 'H': case 'I': case 'J': case 'K': case 'L':
> case 'M': case 'N': case 'O': case 'P': case 'Q': case 'R':
> case 'S': case 'T': case 'U': case 'V': case 'W': case 'X':
> case 'Y': case 'Z': case '0': case '1': case '2': case '3':
> case '4': case '5': case '6': case '7': case '8': case '9':
> break;
> default:
> goto endofloop;
> }
> endofloop:
>
I'd rather have ranges in cases (like you have, and like gcc has as an
extension), and I'd rather C did not need "break" statements in
switches. Contrary to your beliefs, I have never claimed C was perfect.
But that would be a very weird way to write the code in C. Why would
you have a switch here?
while (true) {
c = *p++;
if ((c >= 'A') && (c <= 'Z)) continue;
if ((c >= '0') && (c <= '9)) continue;
break;
}
(There are many other ways to write it - that was just one example.)
> Which version do you think is more error prone? Which version was forced
> to use a goto? (Either that or add flags.) Which one has the rather
> confusing 'break'? (You need to look at context to see if this belongs
> to the while or the switch.)
>
Well, your C switch version was insane. But that does not mean that
your own version was outstanding. It is fine, once you have learned
your language, but it is hardly anything special compared to the C
version I gave above.
Incidentally, good indentation would make it clearer to you what the
"break" applies to - the innermost loop or switch.
>> What do you mean? The language /does/ allow switch inside a loop, and
>> the "break" applies to the switch.
>
> The intention was clearly to break out of the loop. But the language
> doesn't allow it.
"When I use a word," Humpty Dumpty said, in rather a scornful tone, "it
means just what I choose it to mean—neither more nor less."
>
>> However, you'd still have the same issue with "break" with two nested
>> loops.
>
> Um, I don't have that problem either in my language... Just saying.
>
> It's not that it's so advanced, but C is so backward (and other
> languages have copied such aspects).
Baring languages that intentionally match C syntax (like C++), other
languages only copy things from C if the designers see that it works
well in practice. Or do you assume that most language designers - of
real, successful languages - are amateurs and you are the only one who
/really/ understands programming?
>
>> The language does not need such a loop, and most C programmers are fine
>> without one.
>
> to n do ...
>
> versus:
>
> for (int i=0; i<n; ++i) ...
>
> OK.... obviously people here like typing punctuation.
Or, rather, some people here seem to have difficulty using a keyboard
and have to avoid punctuation (and spaces).
>
> ----------------------------
>
> I'm sorry, this is unfair as, despite the substantial, mature tools
> available for C, my language clearly outclasses it. And it's smaller and
> simpler.
>
> But this is what is so frustrating.
>
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-07 19:31 +0100 |
| Message-ID | <u88yC.663755$oi5.475916@fx43.am4> |
| In reply to | #128900 |
On 07/04/2018 17:16, David Brown wrote:
> Yes, I am saying it is not a problem because it does not occur often.
> How many people actually write hex constants?
In any other sphere of programming, such a thing would be considered a
bug. That is, of all the possible numbers that can be encountered in
input - input you might have no influence over - it can go wrong with 6%
of all such numbers, if a "+" or "-" follows.
Trying to mitigate such a error by saying these are hex constants so
they might be less likely, or there might be intervening spaces, or you
can modify the input to fix the problem (for each of thousands of
possible files), is an incredibly sloppy approach.
> Very, very few
> programmers ever need them - few enough even understand them.
You enjoy making these proclamations don't you?
In the Linux kernel, about one line in nine uses hex constants (or
rather, they contain "0x" which was a quick way of checking 18Mloc over
30K files).
>> Or the code has been generated rather than typed. Or code that had
>> been written as 0xE - 1 has been through a preprocessor that
>> eliminates the space. Now that preprocessed code can't be compiled.
>>
>
> A preprocessor that eliminates the space? Who is being silly now?
My preprocessor eliminates non-significant spaces and tabs. (Indents can
optionally be retained.)
What's silly about that?
> Frankly, if 0x123e-2 is the best you can come up with, you have not
> tried particularly hard.
Roughly 1000000000000000000 different hex constants followed by + or -.
> I agree there - it is an unnecessary quirk in the language. But it is
> so inconsequential that the standards committee have never bothered to
> fix it. It would involve more work for them than it would save the
> world's C programmers combined.
C would do a lot better without the preprocessor. D got rid of it by
adding proper features to cover the typical use-cases.
With a preprocessor, you have to consider that with one of these
function- or function-like calls, the number of leading zeros is
significant:
F(00000); // (function: this is just 0)
G(00000); // (macro: these 0s might form a token)
Who wants to try and read program code like that? Masochists?
> And how often have you ever felt the need to write 0xE-1 ?
Why, what would be so unusual about writing a = 0xFFFF-a? Except it is
on a trailing 'E' digit that this goes funny in C. It is a perfectly
reasonable construct.
> But that would be a very weird way to write the code in C. Why would
> you have a switch here?
>
> while (true) {
> c = *p++;
> if ((c >= 'A') && (c <= 'Z)) continue;
> if ((c >= '0') && (c <= '9)) continue;
> break;
> }
Look for real examples of doswitch in this module:
https://pastebin.com/raw/KmwHDt64
This is designed for speed. With lots of case values, switch is faster
than an if/else chain. (In some cases, a character map within a
while-loop is faster; that is used too.)
The switch expresses exactly the intention, and it is trivial to add or
remove cases. And the control expression occurs just once (even in your
short example, it occurs 5 times).
> "When I use a word," Humpty Dumpty said, in rather a scornful tone, "it
> means just what I choose it to mean—neither more nor less."
If you look back you will see there was a comment explaining what the
break was intended to do. But C made it impossible.
>> to n do ...
>>
>> versus:
>>
>> for (int i=0; i<n; ++i) ...
>>
>> OK.... obviously people here like typing punctuation.
>
> Or, rather, some people here seem to have difficulty using a keyboard
> and have to avoid punctuation (and spaces).
You want to tell the language you want to repeat a body of code N times;
what's the best way of doing that? Let's see:
(1) Tell it the only two pieces of information it really needs other
than the loop body:
(a) Tell it you want such a loop (to)
(b) Tell it the number of times to repeat (N)
or:
(2) Decide to write a generic loop where you have to:
(a) Tell it you want such a loop (for)
(b) Tell it the name of the loop variable you've invented (i)
(c) Tell it the type (int)
(d) Tell it the start value (0)
(e) Tell it how to assign it (=)
(f) Tell it which variable to compare against the limit (i again)
(g) Tell it how to compare (<)
(h) Tell it what to compare against (N)
(i) Tell it which variable to modify (i yet again)
(j) Tell it how to modify it (++)
(k) Try and remember what it was you were going to put in the body..
Hmm, that's a tough one....
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-04-08 15:19 +0200 |
| Message-ID | <pad4tn$2ee$1@dont-email.me> |
| In reply to | #128902 |
On 07/04/18 20:31, bartc wrote: > On 07/04/2018 17:16, David Brown wrote: > >> Yes, I am saying it is not a problem because it does not occur often. >> How many people actually write hex constants? > > In any other sphere of programming, such a thing would be considered a > bug. That is, of all the possible numbers that can be encountered in > input - input you might have no influence over - it can go wrong with 6% > of all such numbers, if a "+" or "-" follows. > > Trying to mitigate such a error by saying these are hex constants so > they might be less likely, or there might be intervening spaces, or you > can modify the input to fix the problem (for each of thousands of > possible files), is an incredibly sloppy approach. > >> Very, very few programmers ever need them - few enough even >> understand them. > > You enjoy making these proclamations don't you? > > In the Linux kernel, about one line in nine uses hex constants (or > rather, they contain "0x" which was a quick way of checking 18Mloc over > 30K files). I did a quick check for the latest 4.16 Linux kernel code. There are 26192 ".c" files. In total there are 17910737 lines. 34598 of these contain "0x" - that is one line in 517. The coding convention for Linux is to have spaces around binary operators, so there should be no cases of a hex constant followed directly by a plus or a minus sign. In fact, there are /two/ cases in the entire base of c files for the Linux kernel, both in the same struct initialisation for an Ethernet driver. There are also two cases of a hex constant followed by " -1". So, here are some statistics. In the combined C files of the Linux kernel - a code base of very low level code in which hex constants are going to be much more common than "normal" C programming - we have this: Total lines: 17,910,737 Total lines with "0x": 34598 (about one in 517) Total hex constants: 44523 Hex constants ending in "e": 933 (about one in 48) Hex constants followed by "+" or "-" and a decimal digit: 154 (one in 289 hex numbers, or one in 116303 lines of code) Hex constants ending in "e" followed by a "+" or "-" followed by a decimal digit: 0 For the header files, we have: Total lines: 5,165,384 Total lines with "0x": 1,540,333 (about one in 3.35) Total hex constants: 1,749,349 Hex constants ending in "e": 34388 (about one in 51) Hex constants followed by "+" or "-" and a decimal digit: 607 (one in 2882 hex numbers, or one in 8509 lines of code) Hex constants ending in "e" followed by a "+" or "-" followed by a decimal digit: 3 (all in comments, not code) Do I think hex constants ending in "e", followed by "+" or "-", followed by a decimal digit constitute a noticeably problem in C programming? No, I don't. > >>> Or the code has been generated rather than typed. Or code that had >>> been written as 0xE - 1 has been through a preprocessor that >>> eliminates the space. Now that preprocessed code can't be compiled. >>> >> >> A preprocessor that eliminates the space? Who is being silly now? > > My preprocessor eliminates non-significant spaces and tabs. (Indents can > optionally be retained.) > > What's silly about that? If it eliminates the /significant/ space between "0123e" and "-2", then it is clearly broken. Writing a preprocessor that you know fails to interpret correct code in the way it is supposed to, is clearly silly. > >> Frankly, if 0x123e-2 is the best you can come up with, you have not >> tried particularly hard. > > Roughly 1000000000000000000 different hex constants followed by + or -. I thought it was obvious that I meant "any hex constant". > >> I agree there - it is an unnecessary quirk in the language. But it is >> so inconsequential that the standards committee have never bothered to >> fix it. It would involve more work for them than it would save the >> world's C programmers combined. > > C would do a lot better without the preprocessor. D got rid of it by > adding proper features to cover the typical use-cases. No, C would not do better without the preprocessor. You can certainly create a language that has a fair amount in common with C, but no pre-processor - but it would not be C. It would be a significantly different language. > > With a preprocessor, you have to consider that with one of these > function- or function-like calls, the number of leading zeros is > significant: > > F(00000); // (function: this is just 0) > G(00000); // (macro: these 0s might form a token) > > Who wants to try and read program code like that? Masochists? I have never had to consider that sort of thing. Just because a language, or a feature of a language, lets you do odd things does not mean that people will actually write such code. > >> And how often have you ever felt the need to write 0xE-1 ? > > Why, what would be so unusual about writing a = 0xFFFF-a? Except it is > on a trailing 'E' digit that this goes funny in C. It is a perfectly > reasonable construct. I am asking you how often you have felt the need to write 0xE-1. You can extend it to other hex constants ending in "e" if you like, and other decimal digits. Note that statistically, based on the Linux kernel example, "e" is the last digit of only 2% of hex constants in real code. (This is not surprising, if you think about it.)
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-08 15:16 +0100 |
| Message-ID | <svpyC.1493003$jx2.698392@fx03.am4> |
| In reply to | #128937 |
On 08/04/2018 14:19, David Brown wrote:
> On 07/04/18 20:31, bartc wrote:
> So, here are some statistics. In the combined C files of the Linux
> kernel - a code base of very low level code in which hex constants are
> going to be much more common than "normal" C programming - we have this:
>
> Total lines: 17,910,737
> Total lines with "0x": 34598 (about one in 517)
Sorry, I don't trust your figure. I get about 1 in 20 lines looking only
at .c files. Just look at some random .c files with your own eyes.
> For the header files, we have:
>
> Total lines: 5,165,384
> Total lines with "0x": 1,540,333 (about one in 3.35)
And I get about 1 in 3 for .h files, about the same.
But think about that: you said hardly anyone used hex, and here one line
in every three - and some of those three will be blanks or comments -
contain hex constants.
>> My preprocessor eliminates non-significant spaces and tabs. (Indents
>> can optionally be retained.)
>>
>> What's silly about that?
>
> If it eliminates the /significant/ space between "0123e" and "-2", then
> it is clearly broken.
The language is broken if it deems that space significant. 0x123E is one
token, and "-" is another, one that can follow a name or number without
an intervening space.
It's not as though these two legal tokens separated by white space form
another legal token when joined together; the result is a malformed
token. So the whole thing is pointless.
>> F(00000); // (function: this is just 0)
>> G(00000); // (macro: these 0s might form a token)
>>
>> Who wants to try and read program code like that? Masochists?
>
> I have never had to consider that sort of thing.
>
> Just because a language, or a feature of a language, lets you do odd
> things does not mean that people will actually write such code.
I wouldn't have known about it, but even with the limited sources I fed
to my C compiler, I came across these problems.
If the lexer sees 00123, it can't just assume it's the octal number 123,
or decimal 83, because it might be a macro argument that is pasted to
form another token. So you look at:
F(00123)
and don't really know what that number means.
>
>>
>>> And how often have you ever felt the need to write 0xE-1 ?
>>
>> Why, what would be so unusual about writing a = 0xFFFF-a? Except it is
>> on a trailing 'E' digit that this goes funny in C. It is a perfectly
>> reasonable construct.
>
> I am asking you how often you have felt the need to write 0xE-1.
Why 0xE-1 rather than 0xE-a? It goes wrong with ANY hex constant
followed by + or -, if the constant ends with E.
This like having a bug where encountering the decimal value 72616390
generates a syntax error.
Your attitude: how likely is it that someone will write that specific
constant? You get it now? This is just papering over a crack.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-04-08 16:37 +0200 |
| Message-ID | <pad9f9$tt1$1@dont-email.me> |
| In reply to | #128940 |
On 08/04/18 16:16, bartc wrote:
> On 08/04/2018 14:19, David Brown wrote:
>> On 07/04/18 20:31, bartc wrote:
>
>> So, here are some statistics. In the combined C files of the Linux
>> kernel - a code base of very low level code in which hex constants are
>> going to be much more common than "normal" C programming - we have this:
>>
>> Total lines: 17,910,737
>> Total lines with "0x": 34598 (about one in 517)
>
> Sorry, I don't trust your figure. I get about 1 in 20 lines looking only
> at .c files. Just look at some random .c files with your own eyes.
First you claim 1 in 9 lines - then you distrust my check using /real/
counting, then you claim 1 in 20 based on "random checks" by eye.
This was my methodology:
find . -name *.c -exec cat {} \; > combined_c_files
grep 0x combined_c_files | wc -l
I am sure those that have better grepping skills than me could do this
more efficiently, but this was good enough. The more complicated
statistics I made took some Python - the details are not worth posting here.
>
>> For the header files, we have:
>>
>> Total lines: 5,165,384
>> Total lines with "0x": 1,540,333 (about one in 3.35)
>
> And I get about 1 in 3 for .h files, about the same.
>
> But think about that: you said hardly anyone used hex, and here one line
> in every three - and some of those three will be blanks or comments -
> contain hex constants.
Yes - hex constants are rare. The Linux kernel is a highly unusual
project. About the only comparable project would be the BSD kernel.
Most people do not write hex constants in their code at all - probably a
fair proportion of C programmers do not really understand hexidecimal at
all. You get them often in embedded programming, and in very low-level
programming (most of the cases in the Linux kernel are from the drivers
parts). They are not unknown in other code - they can be useful for
flags, for binary formats, etc., but they are not a large proportion of
lines of C code.
>
>>> My preprocessor eliminates non-significant spaces and tabs. (Indents
>>> can optionally be retained.)
>>>
>>> What's silly about that?
>>
>> If it eliminates the /significant/ space between "0123e" and "-2",
>> then it is clearly broken.
>
> The language is broken if it deems that space significant. 0x123E is one
> token, and "-" is another, one that can follow a name or number without
> an intervening space.
Not in C - "0x123e-2" is a single invalid preprocessing number token.
That is the way processing of C source is defined in the standards. You
can happily argue that it is a bit silly that it has this quirk, but you
certainly can't argue that the language is "broken" as a result. It has
worked this way since the dawn of C, as far as I know, and no matter how
much you dislike C, even you cannot claim that the language has failed
because of this quirk.
>
> It's not as though these two legal tokens separated by white space form
> another legal token when joined together; the result is a malformed
> token. So the whole thing is pointless.
>
>>> F(00000); // (function: this is just 0)
>>> G(00000); // (macro: these 0s might form a token)
>>>
>>> Who wants to try and read program code like that? Masochists?
>>
>> I have never had to consider that sort of thing.
>>
>> Just because a language, or a feature of a language, lets you do odd
>> things does not mean that people will actually write such code.
>
> I wouldn't have known about it, but even with the limited sources I fed
> to my C compiler, I came across these problems.
>
> If the lexer sees 00123, it can't just assume it's the octal number 123,
> or decimal 83, because it might be a macro argument that is pasted to
> form another token. So you look at:
>
> F(00123)
>
> and don't really know what that number means.
Just use the phases described in the standards, and you'll be fine. You
only have trouble making your compiler because you refuse to read the
standards, but would rather start with a few sample programs and guess
the rules by trial and error.
>
>
>>
>>>
>>>> And how often have you ever felt the need to write 0xE-1 ?
>>>
>>> Why, what would be so unusual about writing a = 0xFFFF-a? Except it
>>> is on a trailing 'E' digit that this goes funny in C. It is a
>>> perfectly reasonable construct.
>>
>> I am asking you how often you have felt the need to write 0xE-1.
>
> Why 0xE-1 rather than 0xE-a? It goes wrong with ANY hex constant
> followed by + or -, if the constant ends with E.
>
> This like having a bug where encountering the decimal value 72616390
> generates a syntax error.
>
> Your attitude: how likely is it that someone will write that specific
> constant? You get it now? This is just papering over a crack.
>
I am not denying this is a counter-intuitive oddity in the language. I
am merely denying that it makes any difference at all to real world
programming.
It is like having a bug in a compiler that causes a crash if given an
input file of exactly 1,491,196 bytes. Yes, it's a bug, and yes it is
illogical - but no, it does not matter in practice.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-08 15:45 +0100 |
| Message-ID | <SVpyC.985267$Ly1.645941@fx13.am4> |
| In reply to | #128945 |
On 08/04/2018 15:37, David Brown wrote: > On 08/04/18 16:16, bartc wrote: >> On 08/04/2018 14:19, David Brown wrote: >>> On 07/04/18 20:31, bartc wrote: >> >>> So, here are some statistics. In the combined C files of the Linux >>> kernel - a code base of very low level code in which hex constants >>> are going to be much more common than "normal" C programming - we >>> have this: >>> >>> Total lines: 17,910,737 >>> Total lines with "0x": 34598 (about one in 517) >> >> Sorry, I don't trust your figure. I get about 1 in 20 lines looking >> only at .c files. Just look at some random .c files with your own eyes. > > First you claim 1 in 9 lines - then you distrust my check using /real/ > counting, then you claim 1 in 20 based on "random checks" by eye. 1 in 9 based on both .c and .h files. Then, since you decided to consider them separately, I measured 1 in 20 for .c, and 1 in 3 for .h. (Approx 2M lines out of 18M; 0.7M out of 14M; and 1.3M out of 3.7M.) 1 in 500 is so sparse - 2 lines in every 1000 - that you can easily disprove that my looking at a few random .c files. I may respond to your other points later. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-04-08 17:52 +0200 |
| Message-ID | <padds1$t5s$1@dont-email.me> |
| In reply to | #128948 |
On 08/04/18 16:45, bartc wrote: > On 08/04/2018 15:37, David Brown wrote: >> On 08/04/18 16:16, bartc wrote: >>> On 08/04/2018 14:19, David Brown wrote: >>>> On 07/04/18 20:31, bartc wrote: >>> >>>> So, here are some statistics. In the combined C files of the Linux >>>> kernel - a code base of very low level code in which hex constants >>>> are going to be much more common than "normal" C programming - we >>>> have this: >>>> >>>> Total lines: 17,910,737 >>>> Total lines with "0x": 34598 (about one in 517) >>> >>> Sorry, I don't trust your figure. I get about 1 in 20 lines looking >>> only at .c files. Just look at some random .c files with your own eyes. >> >> First you claim 1 in 9 lines - then you distrust my check using /real/ >> counting, then you claim 1 in 20 based on "random checks" by eye. > > 1 in 9 based on both .c and .h files. Combining the two totals gives 1 in 14 lines of all .c and .h files containing the combination "0x". (There will be a few false positives, such as printf strings with "0x%04x", but we'll ignore them.) Different versions of the Linux kernel will have slightly different numbers. The header files collections contain a large number of "device register definition" files from manufacturers. These have defined constants for huge numbers of registers, usually for each bit of each register. Such files can have over 99% of the lines containing an 0x constant. And perhaps 95% or more of these are never used in the code - they are there to form a complete set of constants for the chip. That is why I thought it made sense to consider .c and .h files separately. > > Then, since you decided to consider them separately, I measured 1 in 20 > for .c, and 1 in 3 for .h. I don't think you measured anything for the .c files - your numbers there are ridiculous for C code. I have given you my methodology - what was yours? > > (Approx 2M lines out of 18M; 0.7M out of 14M; and 1.3M out of 3.7M.) > > 1 in 500 is so sparse - 2 lines in every 1000 - that you can easily > disprove that my looking at a few random .c files. > For C code, 1 in 500 is not sparse for lines containing hex constants. For a sample embedded project of mine, I had 897 out of 68640 lines in C files - or 1 in 76.5 lines containing an 0x constant. But that is all low-level embedded hardware programming, where such things are common. Looking purely at the "kernel" or "lib" subdirectories C files, the rate is about 1 in 1000. > I may respond to your other points later. >
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-08 18:04 +0100 |
| Message-ID | <eYryC.289490$9S2.74149@fx26.am4> |
| In reply to | #128957 |
On 08/04/2018 16:52, David Brown wrote:
> On 08/04/18 16:45, bartc wrote:
>> On 08/04/2018 15:37, David Brown wrote:
>>> On 08/04/18 16:16, bartc wrote:
>>>> On 08/04/2018 14:19, David Brown wrote:
>>>>> On 07/04/18 20:31, bartc wrote:
>>>>
>>>>> So, here are some statistics. In the combined C files of the Linux
>>>>> kernel - a code base of very low level code in which hex constants
>>>>> are going to be much more common than "normal" C programming - we
>>>>> have this:
>>>>>
>>>>> Total lines: 17,910,737
>>>>> Total lines with "0x": 34598 (about one in 517)
>>>>
>>>> Sorry, I don't trust your figure. I get about 1 in 20 lines looking
>>>> only at .c files. Just look at some random .c files with your own eyes.
>>>
>>> First you claim 1 in 9 lines - then you distrust my check using
>>> /real/ counting, then you claim 1 in 20 based on "random checks" by eye.
>>
>> 1 in 9 based on both .c and .h files.
>
> Combining the two totals gives 1 in 14 lines of all .c and .h files
> containing the combination "0x". (There will be a few false positives,
> such as printf strings with "0x%04x", but we'll ignore them.)
>
> Different versions of the Linux kernel will have slightly different
> numbers.
>
> The header files collections contain a large number of "device register
> definition" files from manufacturers. These have defined constants for
> huge numbers of registers, usually for each bit of each register. Such
> files can have over 99% of the lines containing an 0x constant. And
> perhaps 95% or more of these are never used in the code - they are there
> to form a complete set of constants for the chip. That is why I thought
> it made sense to consider .c and .h files separately.
>
>>
>> Then, since you decided to consider them separately, I measured 1 in
>> 20 for .c, and 1 in 3 for .h.
>
> I don't think you measured anything for the .c files - your numbers
> there are ridiculous for C code. I have given you my methodology - what
> was yours?
Exactly the same for .h files as for .c files, running a script with
this line for every line of every file:
if "0x" in line then ++nmatches fi
Have a look at a file phy_n.c. Or nls_cp949.c. Or even 104-quad-8.c
which is the very first file, where 1 line in 23 uses 0x.
Or, better, here's a list of all 20381 files, and the numbers of lines
in each, and how many of those have "0x":
https://github.com/bartg/langs/blob/master/stats.txt
Perhaps you can compare some of these file with yours to see what the
discrepancy is. Totals are present at the end of that file. Average
ratio is one 0x line in every 21.4 lines.
(The .c files have been copied to a flat directory in a process that
will result in only the most recent version where there are any files
with duplicate names. So some files have been lost. This should not
affect the results much.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-04-08 10:35 -0700 |
| Message-ID | <e9a74b49-f930-4a40-aab6-4944bc4d97ba@googlegroups.com> |
| In reply to | #128960 |
On Sunday, April 8, 2018 at 10:04:23 AM UTC-7, Bart wrote: > On 08/04/2018 16:52, David Brown wrote: > > On 08/04/18 16:45, bartc wrote: > >> On 08/04/2018 15:37, David Brown wrote: > >>> On 08/04/18 16:16, bartc wrote: > >>>> On 08/04/2018 14:19, David Brown wrote: > >>>>> On 07/04/18 20:31, bartc wrote: > >>>> > >>>>> So, here are some statistics. In the combined C files of the Linux > >>>>> kernel - a code base of very low level code in which hex constants > >>>>> are going to be much more common than "normal" C programming - we > >>>>> have this: > >>>>> > >>>>> Total lines: 17,910,737 > >>>>> Total lines with "0x": 34598 (about one in 517) > >>>> > >>>> Sorry, I don't trust your figure. I get about 1 in 20 lines looking > >>>> only at .c files. Just look at some random .c files with your own eyes. > >>> > >>> First you claim 1 in 9 lines - then you distrust my check using > >>> /real/ counting, then you claim 1 in 20 based on "random checks" by eye. > >> > >> 1 in 9 based on both .c and .h files. > > > > Combining the two totals gives 1 in 14 lines of all .c and .h files > > containing the combination "0x". (There will be a few false positives, > > such as printf strings with "0x%04x", but we'll ignore them.) > > > > Different versions of the Linux kernel will have slightly different > > numbers. > > > > The header files collections contain a large number of "device register > > definition" files from manufacturers. These have defined constants for > > huge numbers of registers, usually for each bit of each register. Such > > files can have over 99% of the lines containing an 0x constant. And > > perhaps 95% or more of these are never used in the code - they are there > > to form a complete set of constants for the chip. That is why I thought > > it made sense to consider .c and .h files separately. > > > >> > >> Then, since you decided to consider them separately, I measured 1 in > >> 20 for .c, and 1 in 3 for .h. > > > > I don't think you measured anything for the .c files - your numbers > > there are ridiculous for C code. I have given you my methodology - what > > was yours? > > Exactly the same for .h files as for .c files, running a script with > this line for every line of every file: > > if "0x" in line then ++nmatches fi > > Have a look at a file phy_n.c. Or nls_cp949.c. Or even 104-quad-8.c > which is the very first file, where 1 line in 23 uses 0x. > > Or, better, here's a list of all 20381 files, and the numbers of lines > in each, and how many of those have "0x": > > https://github.com/bartg/langs/blob/master/stats.txt > > Perhaps you can compare some of these file with yours to see what the > discrepancy is. Totals are present at the end of that file. Average > ratio is one 0x line in every 21.4 lines. > > (The .c files have been copied to a flat directory in a process that > will result in only the most recent version where there are any files > with duplicate names. So some files have been lost. This should not > affect the results much. > > -- > bartc Someone's reverse compiled OS X with (it appears) a Markv model to produce texts which are in the form of ones from my posts. He's unmistakably flooding, he got caught and he's doing the standard role-reversal BS learned in http://stanford.io/2lh3f5e as he attempts to retain a hint of legitimacy... but it backfired. That is the problem with millennials and uneducated instructors don't care; people from smarter generations *should* know better than to fall for the New World agenda. -- This broke the Internet! https://prescottareapsychopaths.wordpress.com/shawn-ulman-psychopath Jonas Eklundh Communication AB
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-08 16:17 +0100 |
| Message-ID | <coqyC.325020$oa6.268318@fx33.am4> |
| In reply to | #128945 |
On 08/04/2018 15:37, David Brown wrote: > On 08/04/18 16:16, bartc wrote: > That is the way processing of C source is defined in the standards. You > can happily argue that it is a bit silly that it has this quirk, but you > certainly can't argue that the language is "broken" as a result. It has > worked this way since the dawn of C, as far as I know, Four of my 7 C compilers ignore the quirk. They should be lauded for ignoring this particular bit of Standard nonsense instead of keeping it going for another generation. >> If the lexer sees 00123, it can't just assume it's the octal number >> 123, or decimal 83, because it might be a macro argument that is >> pasted to form another token. So you look at: >> >> F(00123) >> >> and don't really know what that number means. > > Just use the phases described in the standards, and you'll be fine. Huh? This is about someone trying to read this bit of C code and wondering what it's up to. In how many other languages can you look at the numeric denotation 00123 and not know what it means? Even ignoring the leading zeros, just with F(123), it could be transformed into almost anything, including nothing at all. All thanks to the preprocessor. And don't say YOUR code would never do that, because the reason I know about it is because enough code does. You > only have trouble making your compiler because you refuse to read the > standards, but would rather start with a few sample programs and guess > the rules by trial and error. The preprocessor is a ******* nightmare to implement. And reading the meagre description in the standard is a waste of time. The most useful help was when someone here posted a set of tricky examples. Aided by compiling half a million lines of other people's code which showed up all the oddball examples, because just doing it with a few ambiguous pages from the standard won't cut it. > It is like having a bug in a compiler that causes a crash if given an > input file of exactly 1,491,196 bytes. Yes, it's a bug, and yes it is > illogical - but no, it does not matter in practice. Um - I think it does. Imagine if an application that processed input files - of any kind - had the same problem. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-04-07 13:13 -0700 |
| Message-ID | <lnmuyepyfu.fsf@kst-u.example.com> |
| In reply to | #128900 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> But that would be a very weird way to write the code in C. Why would
> you have a switch here?
>
> while (true) {
> c = *p++;
> if ((c >= 'A') && (c <= 'Z)) continue;
> if ((c >= '0') && (c <= '9)) continue;
> break;
> }
>
> (There are many other ways to write it - that was just one example.)
[...]
Both your version and bartc's example (in his own language) using
ranges are non-portable. The language guarantees that '0'..'9' are
contiguous, but it makes no such guarantee for 'A'..'Z' or 'a'..'z'.
And in fact in EBCDIC there are extra characters between 'A' and
'Z', and between 'a' and 'z'.
(And depending on the application you might need to deal with
letters other than the 52 Latin ones.)
Incidentally, gcc supports case ranges as an extension, but it uses
`...` rather than `..` (probably because `...` is an existing token).
And the documentation warns the programmer to put spaces around the
`...` symbol, because `1...5` would fail to parse.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-07 21:39 +0100 |
| Message-ID | <H%9yC.473572$TP2.110463@fx01.am4> |
| In reply to | #128903 |
On 07/04/2018 21:13, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> But that would be a very weird way to write the code in C. Why would
>> you have a switch here?
>>
>> while (true) {
>> c = *p++;
>> if ((c >= 'A') && (c <= 'Z)) continue;
>> if ((c >= '0') && (c <= '9)) continue;
>> break;
>> }
>>
>> (There are many other ways to write it - that was just one example.)
> [...]
>
> Both your version and bartc's example (in his own language) using
> ranges are non-portable. The language guarantees that '0'..'9' are
> contiguous, but it makes no such guarantee for 'A'..'Z' or 'a'..'z'.
> And in fact in EBCDIC there are extra characters between 'A' and
> 'Z', and between 'a' and 'z'.
The Linux kernel sources include these lines (randomly combined):
if (c >= 'a' && c <= 'z')
} else if (*esc >= 'a' && *esc <= 'z') {
if ((new_gov[i] >= 'a') && (new_gov[i] <= 'z'))
case 'a' ... 'z':
if (ch < 'a' || ch > 'z')
const int base = 'z' - 'a' + 1;
if (a<128 || a==255) return a>='a' && a<='z' ? a - 0x20 : a;
*walk = (!opts->nocase && c >= 'a' && c <= 'z') ? c -
32 : c;
if (!opts->nocase && c >= 'a' && c <= 'z')
k[1] == 'z' || k[1] == 'b' || k[1] == 'y' || k[1]
== 'a') {
#define ISLOWER(x) (((x) >= 'a') && ((x) <= 'z'))
else if ((key >= 'a') && (key <= 'z'))
else if (('a' <= *str) && (*str <= 'z')) {
if (optstr[i] != 'h' && 'a' <= optstr[i] && optstr[i]
<= 'z')
If Linux programmers don't care about EBCDIC then neither do I.
Same story with Tiny C sources. And with Seed 7 sources. And CPython.
And numerous other programs. And all mine for over 3 decades
It seems nobody cares about EBCDIC (except perhaps you). (Isn't everyone
using Unicode now anyway? The first 128 Unicode characters, and the
first 128 codes in UTF8, are ASCII.)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-04-07 13:55 -0700 |
| Message-ID | <lnin92pwh4.fsf@kst-u.example.com> |
| In reply to | #128904 |
bartc <bc@freeuk.com> writes:
> On 07/04/2018 21:13, Keith Thompson wrote:
[...]
>> Both your version and bartc's example (in his own language) using
>> ranges are non-portable. The language guarantees that '0'..'9' are
>> contiguous, but it makes no such guarantee for 'A'..'Z' or 'a'..'z'.
>> And in fact in EBCDIC there are extra characters between 'A' and
>> 'Z', and between 'a' and 'z'.
>
> The Linux kernel sources include these lines (randomly combined):
[snip]
The Linux kernel sources are not portable code. That's fine, they don't
have to be.
[...]
> If Linux programmers don't care about EBCDIC then neither do I.
>
> Same story with Tiny C sources. And with Seed 7 sources. And CPython.
> And numerous other programs. And all mine for over 3 decades
>
> It seems nobody cares about EBCDIC (except perhaps you). (Isn't everyone
> using Unicode now anyway? The first 128 Unicode characters, and the
> first 128 codes in UTF8, are ASCII.)
My point is that the C standard is designed to allow for EBCDIC. There
have been, and there still are, C implementations for EBCDIC-based
systems.
Nobody says you have to care about EBCDIC.
And since you mentioned Unicode, `c >= 'a' && c <= 'z'` does not tell
you whether c is a lower case letter unless you already know that c is
restricted to something like the ASCII character set, excluding accented
and non-Latin letters.
That may be part of the reason C doesn't have case ranges, though that's
just speculation on my part.
See also the standard islower() and isupper() functions, which have
locale-specific behavior.
Again, if *you* want to assume ASCII, you're free to do so. I merely
said your code is non-portable.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-07 22:10 +0100 |
| Message-ID | <RsayC.827802$Ml.827464@fx24.am4> |
| In reply to | #128905 |
On 07/04/2018 21:55, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: >> On 07/04/2018 21:13, Keith Thompson wrote: > [...] >>> Both your version and bartc's example (in his own language) using >>> ranges are non-portable. The language guarantees that '0'..'9' are >>> contiguous, but it makes no such guarantee for 'A'..'Z' or 'a'..'z'. >>> And in fact in EBCDIC there are extra characters between 'A' and >>> 'Z', and between 'a' and 'z'. >> >> The Linux kernel sources include these lines (randomly combined): > [snip] > > The Linux kernel sources are not portable code. That's fine, they don't > have to be. I think they are, or are the 21M lines of code specific to one platform? Linux runs on lots of machines, and is probably more portable than most applications want to be. > And since you mentioned Unicode, `c >= 'a' && c <= 'z'` does not tell > you whether c is a lower case letter unless you already know that c is > restricted to something like the ASCII character set, excluding accented > and non-Latin letters. You can just define 'lower case' to be only meaningful for 'a' to 'z'. Otherwise full Unicode handling is a complete can of worms that will make everything impossible. (I'd rather work with EBCDIC.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-04-07 15:04 -0700 |
| Message-ID | <lnefjqptaf.fsf@kst-u.example.com> |
| In reply to | #128906 |
bartc <bc@freeuk.com> writes:
> On 07/04/2018 21:55, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>>> On 07/04/2018 21:13, Keith Thompson wrote:
>> [...]
>>>> Both your version and bartc's example (in his own language) using
>>>> ranges are non-portable. The language guarantees that '0'..'9' are
>>>> contiguous, but it makes no such guarantee for 'A'..'Z' or 'a'..'z'.
>>>> And in fact in EBCDIC there are extra characters between 'A' and
>>>> 'Z', and between 'a' and 'z'.
>>>
>>> The Linux kernel sources include these lines (randomly combined):
>> [snip]
>>
>> The Linux kernel sources are not portable code. That's fine, they don't
>> have to be.
>
> I think they are, or are the 21M lines of code specific to one platform?
>
> Linux runs on lots of machines, and is probably more portable than most
> applications want to be.
Yes, it runs on lots of machines. It's not designed to work on *all*
machines that have conforming C implementations. In particular, it
apparently is not designed to work in an EBCDIC environment.
The C language is.
And as I recall, the Linux kernel uses gcc-specific extensions.
>> And since you mentioned Unicode, `c >= 'a' && c <= 'z'` does not tell
>> you whether c is a lower case letter unless you already know that c is
>> restricted to something like the ASCII character set, excluding accented
>> and non-Latin letters.
>
> You can just define 'lower case' to be only meaningful for 'a' to 'z'.
> Otherwise full Unicode handling is a complete can of worms that will
> make everything impossible. (I'd rather work with EBCDIC.)
Sure, you can do that, and it might be perfectly appropriate.
You might think about the possibility that you might need to deal
with people's names containing accented characters. If you're sure
that's not an issue, you can assume ASCII.
You seem to be assuming that when I pointed out that your code
was non-portable, I was criticizing it. I wasn't. I was merely
pointing out that it's non-portable. I've said before that one of
C's greatest strengths is its ability to support non-portable code.
I advise programmers to keep portability issues in mind while
writing code. For example, if you write (c >= 'A' && c <= 'Z')
you should at least be *aware* that it's not 100% portable, whereas
(c >= '0' && c <= '9') probably is. But that doesn't mean you
should never write such code.
My point is that the C language can't assume letters are contiguous.
What exactly was your point?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-07 23:27 +0100 |
| Message-ID | <WAbyC.254404$By2.123319@fx30.am4> |
| In reply to | #128907 |
On 07/04/2018 23:04, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: > My point is that the C language can't assume letters are contiguous. Programmers can. And do. It makes coding a little bit simpler. > What exactly was your point? That it doesn't matter. No one cares about EBCDIC. And there will be probably be many things that will be considerably more likely to render a program non-portable. (I'd like to see an app developed on Linux build effortlessly on Windows for example.) The advantage of writing 'A'...'Z' is too great to just dismiss it because it might not work on EBCDIC. Most people will never see EBCDIC in their lives and it will likely die out. Ironically, just writing 'A'...'Z' renders a program non-portable anyway, if it only works with gcc. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-04-07 16:03 -0700 |
| Message-ID | <lna7uepqk4.fsf@kst-u.example.com> |
| In reply to | #128908 |
bartc <bc@freeuk.com> writes:
> On 07/04/2018 23:04, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>
>> My point is that the C language can't assume letters are contiguous.
>
> Programmers can. And do. It makes coding a little bit simpler.
>
>> What exactly was your point?
>
> That it doesn't matter. No one cares about EBCDIC.
That is manifestly untrue. You don't have to care about it (and
I frankly don't care whether you care about it or not), but EBCDIC
still exists. If you don't have to deal with it yourself, that's
fine. If you insist on pretending it doesn't, that's your problem.
[...]
> The advantage of writing 'A'...'Z' is too great to just dismiss it
> because it might not work on EBCDIC. Most people will never see EBCDIC
> in their lives and it will likely die out.
The advantage of writing isupper(c) is even greater if you care about
letters outside the English alphabet. Imagine having accented letters
in your name and having to deal with software written by people with
your attitude. "Sorry, your name is not valid."
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-08 02:11 +0100 |
| Message-ID | <n%dyC.576568$a15.544340@fx22.am4> |
| In reply to | #128910 |
On 08/04/2018 00:03, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
> The advantage of writing isupper(c) is even greater if you care about
> letters outside the English alphabet. Imagine having accented letters
> in your name and having to deal with software written by people with
> your attitude. "Sorry, your name is not valid."
If I was involved in that these days I would make sure it worked properly.
This code doesn't work on Windows:
char s[20];
strcpy(s,"bárt");
printf("%s\n",s);
strupr(s);
printf("%s\n",s);
although the source displays correctly in Notepad and Notepad++. Whether
it's a encoding mismatch or a display problem (in printf to console, but
it seems strupr doesn't change á) or in a library or whatever it is,
these things are still full of problems unless a lot of effort is expended.
And then it may still go wrong for reasons beyond your control.
(Decades ago I was writing international apps when I was responsible for
pretty much everything including fonts, and western european characters
worked better then they seem to do now. (I remember even having to draw
accented text on a vector pen plotter. The vector font files I
'borrowed' from AutoCAD didn't have accents; I had to add them in!)
Now I'm long retired and can afford to not bother with such details.)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-04-08 02:48 +0100 |
| Message-ID | <87muye8o3b.fsf@bsb.me.uk> |
| In reply to | #128912 |
bartc <bc@freeuk.com> writes:
> On 08/04/2018 00:03, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>
>> The advantage of writing isupper(c) is even greater if you care about
>> letters outside the English alphabet. Imagine having accented letters
>> in your name and having to deal with software written by people with
>> your attitude. "Sorry, your name is not valid."
>
> If I was involved in that these days I would make sure it worked properly.
>
> This code doesn't work on Windows:
>
> char s[20];
> strcpy(s,"bárt");
> printf("%s\n",s);
> strupr(s);
> printf("%s\n",s);
Is that C's fault? strupr is not even a standard C function.
<snip>
> Now I'm long retired and can afford to not bother with such details.)
Does that mean your language can't do this?
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 8 of 16 — ← Prev page 1 … 6 7 [8] 9 10 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web