Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #172354 > unrolled thread
| Started by | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| First post | 2023-08-16 00:31 -0700 |
| Last post | 2023-08-17 03:42 -0700 |
| Articles | 20 on this page of 287 — 19 participants |
Back to article view | Back to comp.lang.c
C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-16 00:31 -0700
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-16 11:14 +0100
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-17 00:23 +0100
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-16 21:38 -0700
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-17 12:19 +0100
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-17 07:53 -0700
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-19 00:15 +0100
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-18 16:33 -0700
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-19 21:46 +0100
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-19 03:04 -0700
Re: C vs Haskell for XML parsing Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-08-19 13:19 +0000
Re: C vs Haskell for XML parsing scott@slp53.sl.home (Scott Lurndal) - 2023-08-19 14:48 +0000
Re: C vs Haskell for XML parsing Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-08-19 15:09 +0000
Re: C vs Haskell for XML parsing Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-08-19 15:17 +0000
Re: C vs Haskell for XML parsing scott@slp53.sl.home (Scott Lurndal) - 2023-08-19 21:05 +0000
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-19 21:05 +0100
Re: C vs Haskell for XML parsing scott@slp53.sl.home (Scott Lurndal) - 2023-08-19 21:07 +0000
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-19 22:31 +0100
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-19 22:04 -0700
Re: C vs Haskell for XML parsing Richard Damon <Richard@Damon-Family.org> - 2023-08-20 07:41 -0400
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-20 17:00 +0100
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-20 11:20 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-20 14:45 -0700
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-21 00:05 +0100
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-20 19:45 -0700
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-21 14:51 +0100
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-21 11:28 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-21 02:59 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-21 15:17 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-21 23:03 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-22 14:09 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-22 05:38 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-22 15:31 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-22 06:51 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-22 19:19 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-22 21:59 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-23 09:57 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-23 07:48 -0700
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-23 16:05 +0100
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-23 08:21 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-23 19:30 +0200
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-23 18:50 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-23 10:49 -0700
Re: C vs Haskell for XML parsing scott@slp53.sl.home (Scott Lurndal) - 2023-08-23 18:08 +0000
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-23 21:28 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-23 20:53 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-24 15:15 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-24 07:50 -0700
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-24 16:48 +0100
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-24 17:35 +0000
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-24 18:09 +0000
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-25 09:59 +0200
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-25 09:46 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-25 01:37 -0700
Re: C vs Haskell for XML parsing Spiros Bousbouras <spibou@gmail.com> - 2023-08-25 08:50 +0000
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-25 01:53 -0700
Underscores in type names (was : C vs Haskell for XML parsing) Spiros Bousbouras <spibou@gmail.com> - 2023-08-25 09:17 +0000
Re: Underscores in type names (was : C vs Haskell for XML parsing) Richard Harnden <richard.nospam@gmail.com> - 2023-08-25 11:35 +0100
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-25 13:42 +0200
Re: C vs Haskell for XML parsing scott@slp53.sl.home (Scott Lurndal) - 2023-08-25 13:59 +0000
Re: C vs Haskell for XML parsing candycane@f172.n1.z21.fsxnet (candycane) - 2023-08-26 00:45 +1300
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-25 19:50 +0100
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-26 02:55 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-26 19:21 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-27 03:05 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-27 18:28 +0200
Re: C vs Haskell for XML parsing scott@slp53.sl.home (Scott Lurndal) - 2023-08-28 14:01 +0000
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-28 16:07 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-29 09:16 +0200
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-29 19:22 +0000
Re: C vs Haskell for XML parsing scott@slp53.sl.home (Scott Lurndal) - 2023-08-29 19:38 +0000
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-29 20:11 +0000
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-29 21:59 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-30 00:43 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-30 12:30 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-30 05:04 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-30 17:50 +0200
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-30 19:41 +0000
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-31 11:18 +0200
Re: C vs Haskell for XML parsing Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-08-30 14:40 +0000
Re: C vs Haskell for XML parsing scott@slp53.sl.home (Scott Lurndal) - 2023-08-30 15:03 +0000
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-30 12:00 -0700
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-30 20:50 -0700
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-31 08:12 +0000
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-01 11:51 -0700
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-27 00:55 +0100
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-28 16:17 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-25 04:31 -0700
Re: C vs Haskell for XML parsing scott@slp53.sl.home (Scott Lurndal) - 2023-08-25 14:06 +0000
Re: C vs Haskell for XML parsing Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-08-25 15:35 +0000
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-25 11:45 -0700
Re: C vs Haskell for XML parsing Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-08-25 20:06 +0000
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-25 19:35 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-25 19:55 -0700
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-25 20:26 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-26 19:24 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-26 02:52 -0700
Re: C vs Haskell for XML parsing scott@slp53.sl.home (Scott Lurndal) - 2023-08-26 14:10 +0000
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-26 22:54 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-27 18:39 +0200
Re: C vs Haskell for XML parsing James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-08-27 15:56 -0400
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-28 00:42 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-28 10:39 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-28 02:03 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-28 13:29 +0200
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-28 16:35 +0000
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-28 10:11 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-28 19:40 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-28 12:31 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-28 22:39 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-28 14:22 -0700
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-28 16:02 -0700
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-28 16:21 +0000
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-28 10:05 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-28 14:50 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-28 14:50 -0700
Re: C vs Haskell for XML parsing scott@slp53.sl.home (Scott Lurndal) - 2023-08-28 14:13 +0000
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-26 19:31 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-26 23:08 -0700
Re: C vs Haskell for XML parsing "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-26 23:23 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-27 18:41 +0200
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-25 13:38 +0200
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-25 11:59 -0700
Re: C vs Haskell for XML parsing Richard Damon <Richard@Damon-Family.org> - 2023-08-25 19:34 -0400
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-25 17:12 -0700
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-26 01:44 +0100
Re: C vs Haskell for XML parsing Richard Damon <Richard@Damon-Family.org> - 2023-08-25 22:18 -0400
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-25 19:58 -0700
Re: C vs Haskell for XML parsing Richard Damon <Richard@Damon-Family.org> - 2023-08-25 23:07 -0400
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-25 21:17 -0700
Re: C vs Haskell for XML parsing Richard Damon <Richard@Damon-Family.org> - 2023-08-26 10:12 -0400
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-26 15:13 -0700
Re: C vs Haskell for XML parsing Richard Damon <Richard@Damon-Family.org> - 2023-08-26 19:47 -0400
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-26 19:09 -0700
Re: C vs Haskell for XML parsing Richard Damon <Richard@Damon-Family.org> - 2023-08-26 22:27 -0400
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-27 18:55 +0200
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-26 02:16 +0100
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-25 18:39 -0700
Re: C vs Haskell for XML parsing Richard Damon <Richard@Damon-Family.org> - 2023-08-25 22:26 -0400
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-26 11:07 +0100
Re: C vs Haskell for XML parsing Richard Damon <Richard@Damon-Family.org> - 2023-08-26 10:33 -0400
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-26 16:27 +0100
Re: C vs Haskell for XML parsing Richard Damon <Richard@Damon-Family.org> - 2023-08-26 11:57 -0400
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-26 17:11 +0100
Re: C vs Haskell for XML parsing Richard Damon <Richard@Damon-Family.org> - 2023-08-26 12:35 -0400
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-26 18:24 +0100
Re: C vs Haskell for XML parsing Richard Damon <Richard@Damon-Family.org> - 2023-08-26 13:35 -0400
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-26 20:11 +0100
Re: C vs Haskell for XML parsing Richard Damon <Richard@Damon-Family.org> - 2023-08-26 17:07 -0400
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-26 22:40 +0100
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-26 23:32 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-27 03:02 -0700
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-27 13:25 +0100
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-26 14:37 -0700
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-26 19:49 +0000
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-26 22:00 +0100
Re: C vs Haskell for XML parsing Richard Damon <Richard@Damon-Family.org> - 2023-08-26 17:31 -0400
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-26 15:28 -0700
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-27 04:24 +0000
Re: C vs Haskell for XML parsing "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-26 21:59 -0700
Re: C vs Haskell for XML parsing candycane@f172.n1.z21.fsxnet (candycane) - 2023-08-27 02:42 +1300
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-27 11:23 +0100
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-27 22:45 +0000
Re: C vs Haskell for XML parsing Richard Damon <Richard@Damon-Family.org> - 2023-08-27 19:06 -0400
Re: C vs Haskell for XML parsing James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-08-28 02:18 -0400
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-27 16:21 -0700
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-28 00:00 +0000
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-27 19:36 -0700
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-28 03:00 +0000
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-28 06:58 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-28 15:22 -0700
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-28 16:49 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-28 17:11 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-29 16:06 +0200
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-29 08:27 -0700
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-29 01:36 +0100
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-29 01:22 +0000
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-29 10:40 +0100
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-29 02:53 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-29 03:00 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-29 16:18 +0200
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-29 13:06 -0700
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-29 22:14 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-30 01:32 -0700
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-30 21:09 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-30 12:44 +0200
Re: C vs Haskell for XML parsing James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-08-30 12:32 -0400
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-30 11:44 -0700
Re: C vs Haskell for XML parsing James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-09-09 01:15 -0400
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-31 04:47 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-30 11:42 -0700
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-30 23:36 -0700
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-31 08:15 +0000
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-01 11:48 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-03 03:55 -0700
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-03 11:44 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-03 16:20 -0700
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-03 16:47 -0700
Re: C vs Haskell for XML parsing Richard Damon <Richard@Damon-Family.org> - 2023-09-03 17:24 -0700
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-10-03 03:16 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-03 17:26 -0700
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-10-03 03:19 -0700
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-29 19:43 +0000
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-29 13:23 -0700
Re: C vs Haskell for XML parsing Bobby Moore <bobbymoore018@gmail.com> - 2023-08-29 13:54 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-29 11:41 +0200
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-29 08:29 -0700
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-29 16:54 +0100
Re: Named function arguments (Was : C vs Haskell for XML parsing) Spiros Bousbouras <spibou@gmail.com> - 2023-08-30 19:30 +0000
Re: Named function arguments (Was : C vs Haskell for XML parsing) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-30 19:53 +0000
Re: Named function arguments (Was : C vs Haskell for XML parsing) Spiros Bousbouras <spibou@gmail.com> - 2023-08-30 20:07 +0000
Re: Named function arguments (Was : C vs Haskell for XML parsing) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-30 20:42 +0000
Re: Named function arguments (Was : C vs Haskell for XML parsing) Richard Harnden <richard.nospam@gmail.com> - 2023-08-30 23:15 +0100
Re: Named function arguments (Was : C vs Haskell for XML parsing) Spiros Bousbouras <spibou@gmail.com> - 2023-08-31 18:41 +0000
Re: Named function arguments (Was : C vs Haskell for XML parsing) David Brown <david.brown@hesbynett.no> - 2023-08-31 12:43 +0200
Re: Named function arguments (Was : C vs Haskell for XML parsing) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-30 20:40 -0700
Re: C vs Haskell for XML parsing scott@slp53.sl.home (Scott Lurndal) - 2023-08-28 14:15 +0000
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-28 15:53 +0100
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-28 18:41 +0200
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-28 18:01 +0100
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-28 20:01 +0200
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-28 20:14 +0100
Re: C vs Haskell for XML parsing scott@slp53.sl.home (Scott Lurndal) - 2023-08-28 19:27 +0000
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-28 16:09 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-28 21:53 +0200
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-28 20:37 +0000
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-28 23:39 +0100
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-29 00:23 +0000
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-29 01:01 -0700
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-29 19:28 +0000
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-29 11:08 +0100
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-28 01:31 +0100
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-25 20:18 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-27 18:50 +0200
Re: C vs Haskell for XML parsing Richard Harnden <richard.nospam@gmail.com> - 2023-08-27 19:18 +0100
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-27 21:19 +0200
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-27 20:33 +0100
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-27 14:14 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-27 13:56 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-28 11:00 +0200
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-28 15:12 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-29 16:32 +0200
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-29 13:12 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-30 12:50 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-25 23:38 -0700
Re: C vs Haskell for XML parsing scott@slp53.sl.home (Scott Lurndal) - 2023-08-26 14:09 +0000
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-27 00:44 +0100
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-27 00:18 -0700
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-27 17:56 +0100
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-27 19:20 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-27 11:18 -0700
Re: C vs Haskell for XML parsing kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-08-27 18:34 +0000
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-28 00:32 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-28 11:14 +0200
Re: C vs Haskell for XML parsing scott@slp53.sl.home (Scott Lurndal) - 2023-08-28 14:10 +0000
Re: C vs Haskell for XML parsing kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-08-29 10:47 +0000
Re: C vs Haskell for XML parsing Michael S <already5chosen@yahoo.com> - 2023-08-29 04:53 -0700
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-29 06:35 -0700
Re: C vs Haskell for XML parsing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-28 16:12 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-28 08:24 +0200
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-28 22:17 +0100
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-28 14:35 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-28 14:38 -0700
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-28 01:00 +0100
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-28 11:24 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-28 03:29 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-28 14:01 +0200
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-28 08:40 -0700
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-27 19:11 +0200
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-25 14:49 +0100
Re: C vs Haskell for XML parsing David Brown <david.brown@hesbynett.no> - 2023-08-25 19:59 +0200
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-25 18:31 +0000
Re: C vs Haskell for XML parsing Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-25 20:03 -0700
Re: C vs Haskell for XML parsing Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-23 14:54 -0700
Re: C vs Haskell for XML parsing scott@slp53.sl.home (Scott Lurndal) - 2023-08-22 14:57 +0000
Re: C vs Haskell for XML parsing Bart <bc@freeuk.com> - 2023-08-22 14:10 +0100
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-21 13:46 +0100
Re: C vs Haskell for XML parsing fir <profesor.fir@gmail.com> - 2023-08-16 17:32 -0700
Re: C vs Haskell for XML parsing fir <profesor.fir@gmail.com> - 2023-08-16 17:47 -0700
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-17 00:37 +0000
Re: C vs Haskell for XML parsing fir <profesor.fir@gmail.com> - 2023-08-16 17:40 -0700
Re: C vs Haskell for XML parsing Michael S <already5chosen@yahoo.com> - 2023-08-17 02:37 -0700
Re: C vs Haskell for XML parsing Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-17 13:50 +0000
Re: C vs Haskell for XML parsing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-17 00:07 +0100
Re: C vs Haskell for XML parsing fir <profesor.fir@gmail.com> - 2023-08-16 17:25 -0700
Re: C vs Haskell for XML parsing fir <profesor.fir@gmail.com> - 2023-08-17 03:32 -0700
Re: C vs Haskell for XML parsing fir <profesor.fir@gmail.com> - 2023-08-17 03:42 -0700
Page 2 of 15 — ← Prev page 1 [2] 3 4 … 15 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-08-20 17:00 +0100 |
| Message-ID | <87jztpu2iu.fsf@bsb.me.uk> |
| In reply to | #172568 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Saturday, 19 August 2023 at 22:31:28 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>> > On Saturday, 19 August 2023 at 00:15:25 UTC+1, Ben Bacarisse wrote:
>> >>
>> >> It turns out that if you want to be 100% conforming you need to be able
>> >> to detect both UCS-4 and (eye roll) EBCDIC.
>> >>
>> > I had a go at ECBDIC.
>> >
>> > If anyone has an EBCDIC XML file they'd like to test, please post a
>> > link.
>> You can make your own by (a) setting the encoding="..." attribute in the
>> declaration (EBCDIC-INT is a good one) and then running iconv.
>> > Of course the next challenge is to support ECBDIC as the execution
>> > character set. This means all the if (ch == '<') statements have to
>> > come out and be replaced by if (ch == ASCII_LESSTHEN). And the strings
>> > have to be replaced with hex codes.
>> Do you have a user who wants to compile your program on a system that
>> does not support ASCII C source?
>>
> Who knows. The code is publicly available to whoever wants it.
It was a somewhat rhetorical question. EBCDIC data is, I would venture,
far more common that non-ASCII C compilers.
>> > Here's where the Baby X resource compiler shows its power. Simply set
>> > up the input
>> > <BabyXRC>
>> > <utf8 name="cdata"><CDATA</utf8>
>> > </BabyXRC>
>> You've lost me. That does not parse.
Without a parse for that supposed document, I can't work out what you
are saying. You refer to XML CDATA sections below, but <CDATA is not
such a section.
>> > And so on, and you get all the strings in hex-encoded UTF-8, ready to
>> > cut and paste.
>> What strings? And why hex -- nothing in the XML suggests hex? I
>> usually want UTF-8 strings as UTF-8 strings in the source, but I
>> understand your user base does not include me.
>>
> XML documents contain a tag called "CDATA".
No, CDATA sections are not tags, not is the syntax, <[CDATA[, that or a
tag.
> So the natural thing is
> to write
> if (!strcmp(tag, "CDATA") /* check for CDATA and process it. */
I can't stop you parsing <[CDATA[ and putting "CDATA" in a variable tag,
but it's not a good name.
> This will work on a program which accepts data in the execution character
> set and only in the execution character set. However the XML parser
> accepts data in ASCII, UTF-8, UTF-16 (two flavours) and, now, EBCDIC.
> It does this by converting to a common format via a conversion function
> passed to the lexer, and the common format is UTF-8.
Er... yes. I don't see how this us going to explain the bit that had me
perplexed but I'll keep reading.
> So "tag" will be in UTF-8. If the execution character set is ASCII, then
> the comparison will still work, and that is what I have done. But if it is
> EBCDIC, it will fail.
Use u8"CDATA"?
> Instead we need to write
>
> /* CDATA in UTF-8 */
> char *cdata = {0x43, 0x44, 0x54, 0x41, 0x00}:
I think you mean {0x43, 0x44, 0x41, 0x54, 0x41, 0x00};
> if (!strcmp(tag, cdata)) /* check for CDATA and process it */
You don't /need/ to, but it's one way.
> This is where the Baby X resource compiler comes to our rescue. It will
> convert ASCII to that form, with the utf-8 tag.
It comes into it's own for people using EBCDIC for C source code?
That's a tiny user base. I am now completely lost. On other machines,
converting ASCII to UTF-8 is a no-op.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-20 11:20 -0700 |
| Message-ID | <610a41a0-a3a3-4e01-a9a7-8b5e1fe31ec0n@googlegroups.com> |
| In reply to | #172586 |
On Sunday, 20 August 2023 at 17:01:14 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > On Saturday, 19 August 2023 at 22:31:28 UTC+1, Ben Bacarisse wrote:
> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>
> >> > On Saturday, 19 August 2023 at 00:15:25 UTC+1, Ben Bacarisse wrote:
> >> >>
> >> >> It turns out that if you want to be 100% conforming you need to be able
> >> >> to detect both UCS-4 and (eye roll) EBCDIC.
> >> >>
> >> > I had a go at ECBDIC.
> >> >
> >> > If anyone has an EBCDIC XML file they'd like to test, please post a
> >> > link.
> >> You can make your own by (a) setting the encoding="..." attribute in the
> >> declaration (EBCDIC-INT is a good one) and then running iconv.
> >> > Of course the next challenge is to support ECBDIC as the execution
> >> > character set. This means all the if (ch == '<') statements have to
> >> > come out and be replaced by if (ch == ASCII_LESSTHEN). And the strings
> >> > have to be replaced with hex codes.
> >> Do you have a user who wants to compile your program on a system that
> >> does not support ASCII C source?
> >>
> > Who knows. The code is publicly available to whoever wants it.
> It was a somewhat rhetorical question. EBCDIC data is, I would venture,
> far more common that non-ASCII C compilers.
> >> > Here's where the Baby X resource compiler shows its power. Simply set
> >> > up the input
> >> > <BabyXRC>
> >> > <utf8 name="cdata"><CDATA</utf8>
> >> > </BabyXRC>
> >> You've lost me. That does not parse.
> Without a parse for that supposed document, I can't work out what you
> are saying. You refer to XML CDATA sections below, but <CDATA is not
> such a section.
> >> > And so on, and you get all the strings in hex-encoded UTF-8, ready to
> >> > cut and paste.
> >> What strings? And why hex -- nothing in the XML suggests hex? I
> >> usually want UTF-8 strings as UTF-8 strings in the source, but I
> >> understand your user base does not include me.
> >>
> > XML documents contain a tag called "CDATA".
> No, CDATA sections are not tags, not is the syntax, <[CDATA[, that or a
> tag.
> > So the natural thing is
> > to write
> > if (!strcmp(tag, "CDATA") /* check for CDATA and process it. */
> I can't stop you parsing <[CDATA[ and putting "CDATA" in a variable tag,
> but it's not a good name.
>
Oh, there's a typo. A stray '<'. So of course the load would fail. That's why I'm writing
another XML parser. The main motive is to get better error reports.
>
> > This will work on a program which accepts data in the execution character
> > set and only in the execution character set. However the XML parser
> > accepts data in ASCII, UTF-8, UTF-16 (two flavours) and, now, EBCDIC.
> > It does this by converting to a common format via a conversion function
> > passed to the lexer, and the common format is UTF-8.
> Er... yes. I don't see how this us going to explain the bit that had me
> perplexed but I'll keep reading.
> > So "tag" will be in UTF-8. If the execution character set is ASCII, then
> > the comparison will still work, and that is what I have done. But if it is
> > EBCDIC, it will fail.
> Use u8"CDATA"?
>
Apparently it opens a can of worms because it makes the string a char8_t * instead
of a char *.
> > Instead we need to write
> >
> > /* CDATA in UTF-8 */
> > char *cdata = {0x43, 0x44, 0x54, 0x41, 0x00}:
> I think you mean {0x43, 0x44, 0x41, 0x54, 0x41, 0x00};
> > if (!strcmp(tag, cdata)) /* check for CDATA and process it */
> You don't /need/ to, but it's one way.
> > This is where the Baby X resource compiler comes to our rescue. It will
> > convert ASCII to that form, with the utf-8 tag.
> It comes into it's own for people using EBCDIC for C source code?
> That's a tiny user base. I am now completely lost. On other machines,
> converting ASCII to UTF-8 is a no-op.
>
Yes. Instead of converting strings to UTF-8 by hand, which is error prone, the
Baby X resource compiler will do it for you automatically. The "utf8" tag says
"output this string as a hex dump in UTF-8 format".
As you say, on ASCII machines it tends not to be much of an issue if the UTF-8
string is in the common subset of ASCII and UTF-8, because the encoding is
also the same. It's only important if you need the extended UTF-8 characters
but your source character set is strictly ASCII only.
The number of people with EBCDIC C compilers is very small. But they tend to be
dealing with machines worth many millions of pounds and data of incalculably
high value.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-20 14:45 -0700 |
| Message-ID | <87v8d9gzhc.fsf@nosuchdomain.example.com> |
| In reply to | #172594 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> The number of people with EBCDIC C compilers is very small. But they tend to be
> dealing with machines worth many millions of pounds and data of incalculably
> high value.
And, I suspect, they have a lot of experience converting data to and
from EBCDIC -- or they do all their work on EBCDIC-based systems and
don't need to convert anything.
I'm only guessing, but I suspect the intersection of people who could
use BabyX and people who use EBCDIC is small, possibly empty.
The XML specification <https://www.w3.org/TR/xml/> does discuss EBCDIC,
but if BabyX's XML processor didn't handle EBCDIC, I'd be surprised if
anyone were inconvenienced.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-08-21 00:05 +0100 |
| Message-ID | <87350dtive.fsf@bsb.me.uk> |
| In reply to | #172594 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Sunday, 20 August 2023 at 17:01:14 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>> > On Saturday, 19 August 2023 at 22:31:28 UTC+1, Ben Bacarisse wrote:
>> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>> >>
>> >> > On Saturday, 19 August 2023 at 00:15:25 UTC+1, Ben Bacarisse wrote:
>> >> >>
>> >> >> It turns out that if you want to be 100% conforming you need to be able
>> >> >> to detect both UCS-4 and (eye roll) EBCDIC.
>> >> >>
>> >> > I had a go at ECBDIC.
>> >> >
>> >> > If anyone has an EBCDIC XML file they'd like to test, please post a
>> >> > link.
>> >> You can make your own by (a) setting the encoding="..." attribute in the
>> >> declaration (EBCDIC-INT is a good one) and then running iconv.
>> >> > Of course the next challenge is to support ECBDIC as the execution
>> >> > character set. This means all the if (ch == '<') statements have to
>> >> > come out and be replaced by if (ch == ASCII_LESSTHEN). And the strings
>> >> > have to be replaced with hex codes.
>> >> Do you have a user who wants to compile your program on a system that
>> >> does not support ASCII C source?
>> >>
>> > Who knows. The code is publicly available to whoever wants it.
>> It was a somewhat rhetorical question. EBCDIC data is, I would venture,
>> far more common that non-ASCII C compilers.
>> >> > Here's where the Baby X resource compiler shows its power. Simply set
>> >> > up the input
>> >> > <BabyXRC>
>> >> > <utf8 name="cdata"><CDATA</utf8>
>> >> > </BabyXRC>
>> >> You've lost me. That does not parse.
>> Without a parse for that supposed document, I can't work out what you
>> are saying. You refer to XML CDATA sections below, but <CDATA is not
>> such a section.
>> >> > And so on, and you get all the strings in hex-encoded UTF-8, ready to
>> >> > cut and paste.
>> >> What strings? And why hex -- nothing in the XML suggests hex? I
>> >> usually want UTF-8 strings as UTF-8 strings in the source, but I
>> >> understand your user base does not include me.
>> >>
>> > XML documents contain a tag called "CDATA".
>> No, CDATA sections are not tags, not is the syntax, <[CDATA[, that or a
>> tag.
>> > So the natural thing is
>> > to write
>> > if (!strcmp(tag, "CDATA") /* check for CDATA and process it. */
>> I can't stop you parsing <[CDATA[ and putting "CDATA" in a variable tag,
>> but it's not a good name.
>>
> Oh, there's a typo. A stray '<'. So of course the load would
> fail. That's why I'm writing another XML parser. The main motive is to
> get better error reports.
So you intended to write
<utf8 name="cdata">CDATA</utf8>
and CDATA had nothing to do with XML CDATA sections. What's the
reference to "a tag called 'CDATA'" then?
>> > This will work on a program which accepts data in the execution character
>> > set and only in the execution character set. However the XML parser
>> > accepts data in ASCII, UTF-8, UTF-16 (two flavours) and, now, EBCDIC.
>> > It does this by converting to a common format via a conversion function
>> > passed to the lexer, and the common format is UTF-8.
>> Er... yes. I don't see how this us going to explain the bit that had me
>> perplexed but I'll keep reading.
>> > So "tag" will be in UTF-8. If the execution character set is ASCII, then
>> > the comparison will still work, and that is what I have done. But if it is
>> > EBCDIC, it will fail.
>> Use u8"CDATA"?
>>
> Apparently it opens a can of worms because it makes the string a
> char8_t * instead of a char *.
Is the can of worms really there? The "apparently" makes me worry it's
hearsay and FUD. In C11 it's a char[], but in C23 just cast to char *
or unsigned char *. Where are the worms?
But if I were writing such a program, I'd put effort into allowing
different C standard outputs rather than dealing with EBCDIC source
code. Someone who uses C23 will prefer
char8_t *cdata = u8"CDATA";
>> > Instead we need to write
>> >
>> > /* CDATA in UTF-8 */
>> > char *cdata = {0x43, 0x44, 0x54, 0x41, 0x00}:
>> I think you mean {0x43, 0x44, 0x41, 0x54, 0x41, 0x00};
>> > if (!strcmp(tag, cdata)) /* check for CDATA and process it */
>> You don't /need/ to, but it's one way.
>> > This is where the Baby X resource compiler comes to our rescue. It will
>> > convert ASCII to that form, with the utf-8 tag.
>> It comes into it's own for people using EBCDIC for C source code?
>> That's a tiny user base. I am now completely lost. On other machines,
>> converting ASCII to UTF-8 is a no-op.
>>
> Yes. Instead of converting strings to UTF-8 by hand, which is error prone, the
> Baby X resource compiler will do it for you automatically.
It performs the no-op automatically and comes into its own only on
EBCDIC compilers, or was the "yes" a typo?
> The "utf8" tag says
> "output this string as a hex dump in UTF-8 format".
> As you say, on ASCII machines it tends not to be much of an issue if the UTF-8
> string is in the common subset of ASCII and UTF-8, because the encoding is
> also the same. It's only important if you need the extended UTF-8 characters
> but your source character set is strictly ASCII only.
So it does not convert ASCII to UTF-8. In fact, it usually does the
opposite: it converts UTF-8 to ASCII -- specifically the ASCII C source
to represent the string using hex integer constants. That makes much
more sense.
> The number of people with EBCDIC C compilers is very small. But they
> tend to be dealing with machines worth many millions of pounds and
> data of incalculably high value.
The value of the machines and data don't have much to do with whether
it's worth your while supporting EBCDIC. Will there be even one such
user of the system? Will that user really not know how to pipe their
data through, say, xmllint first?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-20 19:45 -0700 |
| Message-ID | <ec66ec3c-67b6-49fc-a4bd-5acc85ff3335n@googlegroups.com> |
| In reply to | #172603 |
On Monday, 21 August 2023 at 00:05:42 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> >> > if (!strcmp(tag, "CDATA") /* check for CDATA and process it. */
> >> I can't stop you parsing <[CDATA[ and putting "CDATA" in a variable tag,
> >> but it's not a good name.
> >>
> > Oh, there's a typo. A stray '<'. So of course the load would
> > fail. That's why I'm writing another XML parser. The main motive is to
> > get better error reports.
> So you intended to write
> <utf8 name="cdata">CDATA</utf8>
> and CDATA had nothing to do with XML CDATA sections. What's the
> reference to "a tag called 'CDATA'" then?
>
The Baby X resource compiler accepts a script file written in XML as its
main input. (The script file usually contains paths to other input files). At
the moment, it contains a simple XML parser which will adequately parse
the subset of XML used for the script files, but isn't goo enough to be a
general purpose XML parser. Also, it doesn't have good error reporting. Which
is a practical problem with XML scripts written by hand.
So I need a new XML parser, which I'm writing at the moment. However the
Baby X resource compiler, in its current state, can be used to assist the
writing of the next generation of XML parser.
>
> > Apparently it opens a can of worms because it makes the string a
> > char8_t * instead of a char *.
> Is the can of worms really there? The "apparently" makes me worry it's
> hearsay and FUD. In C11 it's a char[], but in C23 just cast to char *
> or unsigned char *. Where are the worms?
>
A major advantage of UTF-8 is that it is transparent to UTF-8 naive programs,
as long as they accept strings in ASCII and don't try to play with the top
bit. If you use a different type for char and UTF-8 characters, you lose that
interoperability. In C++
std::cout << " <Greek UTF-8> "
and
std::cout << u8" <Greek UTF-8> "
can do different things, replacing <Greek UTF-8> with extended UTF-8 characters.
In C, it's more subtle.
>
> But if I were writing such a program, I'd put effort into allowing
> different C standard outputs rather than dealing with EBCDIC source
> code. Someone who uses C23 will prefer
>
I'm writing the XML parser component of the program at the moment. The XML
parser always produces output in UTF-8. The current version only accepts XML
input in UTF-8. But the instructions say to accept UTF-16, and with the current
design, that's not too hard to do.
However there could be attribute on the utf8 tag in the script files to say "output
UTF-8 in human-readable form using the u8 prefix". That would be useful.
>
> char8_t *cdata = u8"CDATA";
> >> > Instead we need to write
> >> >
> >> > /* CDATA in UTF-8 */
> >> > char *cdata = {0x43, 0x44, 0x54, 0x41, 0x00}:
> >> I think you mean {0x43, 0x44, 0x41, 0x54, 0x41, 0x00};
> >> > if (!strcmp(tag, cdata)) /* check for CDATA and process it */
> >> You don't /need/ to, but it's one way.
> >> > This is where the Baby X resource compiler comes to our rescue. It will
> >> > convert ASCII to that form, with the utf-8 tag.
> >> It comes into it's own for people using EBCDIC for C source code?
> >> That's a tiny user base. I am now completely lost. On other machines,
> >> converting ASCII to UTF-8 is a no-op.
> >>
> > Yes. Instead of converting strings to UTF-8 by hand, which is error prone, the
> > Baby X resource compiler will do it for you automatically.
> It performs the no-op automatically and comes into its own only on
> EBCDIC compilers, or was the "yes" a typo?
>
You can freely mix ASCII and UTF-8 (as long as you don't use the u8 modifier),
in C. So ASCII string are also UTF-8 strings and there's no point in representing
them in hex. So on an ASCII system, if you have a string which is constrained
to be ASCII< there's not much point using the utf8 tag.
On an EBCDIC system it is different. The strings are no long ASCII. So if you use
the Baby X resource compiler's "string" tag to add a string to the source code,
and compile it with a compiler whose execution character set is EBCDIC, you'll
get a string in EBCDIC. Which is usually what you want, but not always.
>
> > The "utf8" tag says
> > "output this string as a hex dump in UTF-8 format".
> > As you say, on ASCII machines it tends not to be much of an issue if the UTF-8
> > string is in the common subset of ASCII and UTF-8, because the encoding is
> > also the same. It's only important if you need the extended UTF-8 characters
> > but your source character set is strictly ASCII only.
> So it does not convert ASCII to UTF-8. In fact, it usually does the
> opposite: it converts UTF-8 to ASCII -- specifically the ASCII C source
> to represent the string using hex integer constants. That makes much
> more sense.
>
That's right.
On an ASCII system, the utf8 tag in the Baby X resource compiler is useful if
either your compiler or your editor won't accept non-ASCII characters, or
interprets them as ANSI 8 bit codes, because it converts UTF-8 to ASCIII-
encoded hex.
>
> > The number of people with EBCDIC C compilers is very small. But they
> > tend to be dealing with machines worth many millions of pounds and
> > data of incalculably high value.
> The value of the machines and data don't have much to do with whether
> it's worth your while supporting EBCDIC. Will there be even one such
> user of the system? Will that user really not know how to pipe their
> data through, say, xmllint first?
>
Well it does. If you've got only one user who is a hobbyist and does a bit of
bedroom programming for casual games with a tiny circulation, then I think
you'd say that was a disappointment.If you've got only one user who is a mainframe
programmer and says that the program has been invaluable in helping him
process data worth millions of pounds, then I think you'd say that the effort
has been worthwhile.
It's likely that a user interested in EBCDIC would browse available parsers
and choose one that supported EBCDIC. With speculative development, you write
the program first and then hope the customers see it, decide it would be useful, and
come to you. You don't get a user first and then ask him what he needs.
xmllint might well be a better solution than reading the data in EBCDIC. But the
instructions say that a parser should accept EBCDIC.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-08-21 14:51 +0100 |
| Message-ID | <878ra4sdtx.fsf@bsb.me.uk> |
| In reply to | #172610 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Monday, 21 August 2023 at 00:05:42 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>> >> > if (!strcmp(tag, "CDATA") /* check for CDATA and process it. */
>> >> I can't stop you parsing <[CDATA[ and putting "CDATA" in a variable tag,
>> >> but it's not a good name.
>> >>
>> > Oh, there's a typo. A stray '<'. So of course the load would
>> > fail. That's why I'm writing another XML parser. The main motive is to
>> > get better error reports.
>> So you intended to write
>> <utf8 name="cdata">CDATA</utf8>
>> and CDATA had nothing to do with XML CDATA sections. What's the
>> reference to "a tag called 'CDATA'" then?
>>
> The Baby X resource compiler accepts a script file written in XML as its
> main input. (The script file usually contains paths to other input files). At
> the moment, it contains a simple XML parser which will adequately parse
> the subset of XML used for the script files, but isn't goo enough to be a
> general purpose XML parser. Also, it doesn't have good error reporting. Which
> is a practical problem with XML scripts written by hand.
> So I need a new XML parser, which I'm writing at the moment. However the
> Baby X resource compiler, in its current state, can be used to assist the
> writing of the next generation of XML parser.
I can't see an answer to my question, but it was not really important.
I just wanted to know what you were saying.
>> > Apparently it opens a can of worms because it makes the string a
>> > char8_t * instead of a char *.
>> Is the can of worms really there? The "apparently" makes me worry it's
>> hearsay and FUD. In C11 it's a char[], but in C23 just cast to char *
>> or unsigned char *. Where are the worms?
>>
> A major advantage of UTF-8 is that it is transparent to UTF-8 naive programs,
> as long as they accept strings in ASCII and don't try to play with the top
> bit. If you use a different type for char and UTF-8 characters, you lose that
> interoperability.
So you ignored my suggestion and continued to insist that there is some
mysterious problem. Nothing in the type (other than, ironically, const
which you refuse to use) can prevent problems in a program the fiddles
with the top bit so that's a red-herring.
I don't use this stuff at the moment so I'd really like to know the
problems, not at the level of description you are using.
> In C++
> std::cout << " <Greek UTF-8> "
> and
> std::cout << u8" <Greek UTF-8> "
>
> can do different things, replacing <Greek UTF-8> with extended UTF-8
> characters.
I thought you were generating C. A flag to generate C++ strings would
be a better option for C++ output would it not? Especially as C++ is
moving away from supporting such C-style strings in ostream.
Anyway, I see no permission in C++ to mess with the characters in the
string. The C++ wording seems to be almost the same as the C wording.
What compiler does this?
> In C, it's more subtle.
That's even less precise. Where are the worms?
>> But if I were writing such a program, I'd put effort into allowing
>> different C standard outputs rather than dealing with EBCDIC source
>> code. Someone who uses C23 will prefer
>>
> I'm writing the XML parser component of the program at the moment. The
> XML parser always produces output in UTF-8. The current version only
> accepts XML input in UTF-8. But the instructions say to a ccept
> UTF-16, and with the current design, that's not too hard to do.
> However there could be attribute on the utf8 tag in the script files
> to say "output UTF-8 in human-readable form using the u8 prefix". That
> would be useful.
I think it would. And const could be an option too, especially if these
can be defaulted (otherwise it might well be easier just to add const to
the output oneself).
>> char8_t *cdata = u8"CDATA";
>> >> > Instead we need to write
>> >> >
>> >> > /* CDATA in UTF-8 */
>> >> > char *cdata = {0x43, 0x44, 0x54, 0x41, 0x00}:
>> >> I think you mean {0x43, 0x44, 0x41, 0x54, 0x41, 0x00};
>> >> > if (!strcmp(tag, cdata)) /* check for CDATA and process it */
>> >> You don't /need/ to, but it's one way.
>> >> > This is where the Baby X resource compiler comes to our rescue. It will
>> >> > convert ASCII to that form, with the utf-8 tag.
>> >> It comes into it's own for people using EBCDIC for C source code?
>> >> That's a tiny user base. I am now completely lost. On other machines,
>> >> converting ASCII to UTF-8 is a no-op.
>> >>
>> > Yes. Instead of converting strings to UTF-8 by hand, which is error prone, the
>> > Baby X resource compiler will do it for you automatically.
>> It performs the no-op automatically and comes into its own only on
>> EBCDIC compilers, or was the "yes" a typo?
>>
> You can freely mix ASCII and UTF-8 (as long as you don't use the u8
> modifier), in C. So ASCII string are also UTF-8 strings and there's
> no point in representing them in hex.
> So on an ASCII system, if you have a string which is constrained to be
> ASCII there's not much point using the utf8 tag. On an EBCDIC system
> it is different. The strings are no long ASCII. So if you use the Baby
> X resource compiler's "string" tag to add a string to the source code,
> and compile it with a compiler whose execution character set is
> EBCDIC, you'll get a string in EBCDIC. Which is usually what you want,
> but not always.
I'm going to back out of this exchange. I can't seem to get a straight
answer.
>> > The number of people with EBCDIC C compilers is very small. But they
>> > tend to be dealing with machines worth many millions of pounds and
>> > data of incalculably high value.
>> The value of the machines and data don't have much to do with whether
>> it's worth your while supporting EBCDIC. Will there be even one such
>> user of the system? Will that user really not know how to pipe their
>> data through, say, xmllint first?
>>
> Well it does. If you've got only one user who is a hobbyist and does a
> bit of bedroom programming for casual games with a tiny circulation,
> then I think you'd say that was a disappointment.If you've got only
> one user who is a mainframe programmer and says that the program has
> been invaluable in helping him process data worth millions of pounds,
> then I think you'd say that the effort has been worthwhile.
I see we have different value systems.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-21 11:28 +0200 |
| Message-ID | <ubvan6$1rb3s$1@dont-email.me> |
| In reply to | #172603 |
On 21/08/2023 01:05, Ben Bacarisse wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > >> Apparently it opens a can of worms because it makes the string a >> char8_t * instead of a char *. > > Is the can of worms really there? The "apparently" makes me worry it's > hearsay and FUD. In C11 it's a char[], but in C23 just cast to char * > or unsigned char *. Where are the worms? > > But if I were writing such a program, I'd put effort into allowing > different C standard outputs rather than dealing with EBCDIC source > code. Someone who uses C23 will prefer > > char8_t *cdata = u8"CDATA"; > Is there any reason not to write : const char8_t * cdata = u8"CDATA"; ? If you are dealing with old code that takes non-const pointers even there is no write access through the pointers, then it might be more convenient to have non-const pointers to pass to these functions. But for new code, I prefer const pointers as much as possible.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-21 02:59 -0700 |
| Message-ID | <3c87ec37-8fe1-4171-9500-609fad6701b7n@googlegroups.com> |
| In reply to | #172617 |
On Monday, 21 August 2023 at 10:28:28 UTC+1, David Brown wrote: > On 21/08/2023 01:05, Ben Bacarisse wrote: > > Malcolm McLean <malcolm.ar...@gmail.com> writes: > > > > >> Apparently it opens a can of worms because it makes the string a > >> char8_t * instead of a char *. > > > > Is the can of worms really there? The "apparently" makes me worry it's > > hearsay and FUD. In C11 it's a char[], but in C23 just cast to char * > > or unsigned char *. Where are the worms? > > > > But if I were writing such a program, I'd put effort into allowing > > different C standard outputs rather than dealing with EBCDIC source > > code. Someone who uses C23 will prefer > > > > char8_t *cdata = u8"CDATA"; > > > Is there any reason not to write : > > const char8_t * cdata = u8"CDATA"; > > ? > > If you are dealing with old code that takes non-const pointers even > there is no write access through the pointers, then it might be more > convenient to have non-const pointers to pass to these functions. But > for new code, I prefer const pointers as much as possible. > Baby X has a const-free policy in its API. That's partly because a lot of functions take opaque pointers, but do not in fact change state. However that's because of the details of the Baby X implementation and might change if Baby X is ported to a different platform. So "const" is misleading. Partly it's to avoid visual clutter. Strings are a partial exception. The bbx_utf8* functions take const char * so that they can be used with code which uses const. const makes sense in embedded systems where you need to mark data which is stored in physically read-only memory. But Baby X isn't designed for those systems, and all memory is expected to be in RAM chips. But C string literals are non-const by default, even though they are not writeable. Someone might pass data intended as input to a parameter intended for output, but such a mistake would almost always be caught very early in testing.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-21 15:17 +0200 |
| Message-ID | <ubvo4d$1tm0p$1@dont-email.me> |
| In reply to | #172618 |
On 21/08/2023 11:59, Malcolm McLean wrote:
> On Monday, 21 August 2023 at 10:28:28 UTC+1, David Brown wrote:
>> On 21/08/2023 01:05, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>
>>>> Apparently it opens a can of worms because it makes the string a
>>>> char8_t * instead of a char *.
>>>
>>> Is the can of worms really there? The "apparently" makes me worry it's
>>> hearsay and FUD. In C11 it's a char[], but in C23 just cast to char *
>>> or unsigned char *. Where are the worms?
>>>
>>> But if I were writing such a program, I'd put effort into allowing
>>> different C standard outputs rather than dealing with EBCDIC source
>>> code. Someone who uses C23 will prefer
>>>
>>> char8_t *cdata = u8"CDATA";
>>>
>> Is there any reason not to write :
>>
>> const char8_t * cdata = u8"CDATA";
>>
>> ?
>>
>> If you are dealing with old code that takes non-const pointers even
>> there is no write access through the pointers, then it might be more
>> convenient to have non-const pointers to pass to these functions. But
>> for new code, I prefer const pointers as much as possible.
>>
> Baby X has a const-free policy in its API.
That would be a reason not to use "const" in the definition, but it is
just kicking the can down the road.
> That's partly because a lot of functions take opaque pointers, but do not in fact
> change state.
Functions that take const pointers are guaranteeing (baring bugs) that
they do not change the data pointed at, at least not via that pointer.
This is an extremely useful feature and make using an API and reasoning
about it significantly easier. Throwing out that feature is a huge step
backwards for the users of your toolkit.
Proper use of "const" also allows several extra compiler checks, both in
the users' code, and in the implementation of the library. Only a fool
thinks they write such perfect code that they don't take advantage of
such cheap and simple checks.
If I am evaluating a piece of code, and I see it does not have "const"
for pointers that do not change data (at the very least, for function
parameters), I will assume the code is either ancient or written by
someone who does not really understand how to use the language. It's
not an absolute, of course, but it is a big red flag - much like lack of
"static" on file-local functions.
I would have no use of a "resource compiler" that did not declare the
resources as "const".
> However that's because of the details of the Baby X implementation
> and might change if Baby X is ported to a different platform. So "const" is
> misleading.
No, it is not.
If the function in question might change the data, it should be
non-const. If it will not change the data, it should be a const
pointer. That gives the user vital information.
If I see an API function "void show_string(char * p);", I have to assume
it may change the data pointed to. I have to assume I can't write
"show_string("Hello, world!");", but instead must make a copy to a
writeable array and send a pointer to that.
> Partly it's to avoid visual clutter.
Do you also use K&R-style implicit int to avoid clutter?
IMHO - and this is very much just my opinion - you'd be better off
changing your function naming conventions to avoid clutter, and keeping
things that provide important and useful information.
> Strings are a partial exception. The bbx_utf8* functions take const char * so that
> they can be used with code which uses const.
> const makes sense in embedded systems where you need to mark data which
> is stored in physically read-only memory. But Baby X isn't designed for those
> systems, and all memory is expected to be in RAM chips.
"const" makes sense everywhere that you have something you don't want to
change.
It has extra relevance for small embedded systems, but it is certainly
not limited to such systems.
>
> But C string literals are non-const by default, even though they are not writeable.
>
You do know that you can safely assign a pointer-to-non-const expression
to a pointer-to-const? The historical fact that C string literals
predate the "const" keyword in C does not mean you can't use const
pointers to point to C string literals.
> Someone might pass data intended as input to a parameter intended for output,
> but such a mistake would almost always be caught very early in testing.
And we all know that "almost always caught in testing" is /so/ much more
helpful than "always caught at compile time".
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-21 23:03 -0700 |
| Message-ID | <e9853969-42ce-48db-81e1-d37c8e4da59dn@googlegroups.com> |
| In reply to | #172626 |
On Monday, 21 August 2023 at 14:17:16 UTC+1, David Brown wrote:
>
> If the function in question might change the data, it should be
> non-const. If it will not change the data, it should be a const
> pointer. That gives the user vital information.
>
We have to document what the function does and what the parameters
mean anyway. const can help, but it isn't the main source of information,
and it isn't "vital". If it was "vital" then K and R C wouldn't have been a
viable programming language.
> If I see an API function "void show_string(char * p);", I have to assume
> it may change the data pointed to. I have to assume I can't write
> "show_string("Hello, world!");", but instead must make a copy to a
> writeable array and send a pointer to that.
>
No, you read the documentation. A function called strtoupper() pretty obviously
is designed to change the string passed to it. But it can't make just any change.
The changes it does make have to be described. Similarly "show_string" may,
fr some reason, corrupt the string and leave it in an indeterminate state, but
that's part of the API contract.
>
> > Partly it's to avoid visual clutter.
> Do you also use K&R-style implicit int to avoid clutter?
>
I don't, but there's a strong case for making int the default integer type and
making the use of other types special purpose and rare. Implicit int was an
attempt to do that, and the idea was good. But the problem was that the
pattern "typename ... variable or functioname" was too intutitive.
>
> It has extra relevance for small embedded systems, but it is certainly
> not limited to such systems.
>
Generally data is physically writeable on large systems. So "const" is an
artificial restriction.
>
> > But C string literals are non-const by default, even though they are not writeable.
> >
> You do know that you can safely assign a pointer-to-non-const expression
> to a pointer-to-const? The historical fact that C string literals
> predate the "const" keyword in C does not mean you can't use const
> pointers to point to C string literals.
>
You can. But it's only a safe thing to do "in the small". In the large, tainting
mutable data with const can mean that efficiency improvements become
impossible. A common situation is that the operation doens't notionally
change the state (it returns a node in the tree, leaving the tree unaltered),
however in reality it's seldom used for random access, but to iterate through
all the nodes sequentially. So you can convert an O(log N) operation to an
O(1) operation by cacheing the last access. But not if you've const-poisoned the
tree.
>
> > Someone might pass data intended as input to a parameter intended for output,
> > but such a mistake would almost always be caught very early in testing.
> And we all know that "almost always caught in testing" is /so/ much more
> helpful than "always caught at compile time".
>
It's not an absolute. Sometimes using const will help to catch a bug. But it's a
fairly slight advantage. The main reason is that switiching input and output
parameters will almost always be caught on the first test. But the other
reason is that, whilst the low-level function takes const, the data in caller
will usually be mutable. Occasionally you see
strcpy(name, "Fred");
but far more often it's
strcpy(name, employee->name);
const will catch strcpy("Fred", name). (Except it won't, but never mind).
but not
strcpy(employee->name, name);
which is a far more likely bug.
So yes, there are few situations in which const might help you catch bugs, but
it's not a big help, and they aren't very common.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-22 14:09 +0200 |
| Message-ID | <uc28id$2dc7f$1@dont-email.me> |
| In reply to | #172652 |
On 22/08/2023 08:03, Malcolm McLean wrote:
> On Monday, 21 August 2023 at 14:17:16 UTC+1, David Brown wrote:
>>
>> If the function in question might change the data, it should be
>> non-const. If it will not change the data, it should be a const
>> pointer. That gives the user vital information.
>>
> We have to document what the function does and what the parameters
> mean anyway. const can help, but it isn't the main source of information,
> and it isn't "vital". If it was "vital" then K and R C wouldn't have been a
> viable programming language.
C90 was a vast improvement over K&R C (and C99 another huge improvement
- changes after that have been relatively minor).
You can argue that every programming feature that is not in a Turing
Machine is not "vital". The reality, however, is that some features are
very useful for helping writing clear and correct programs. "const" is
one of these. It is no surprise that many modern languages make
everything "const" by default and require explicit keywords to support
modifiable data.
Arguing that you could get by without "const" when programming 35 years
ago is just nonsense.
This is, of course, your program and your decision - all I can do is
give you advice, and it is up to you to take it or leave it.
>
>> If I see an API function "void show_string(char * p);", I have to assume
>> it may change the data pointed to. I have to assume I can't write
>> "show_string("Hello, world!");", but instead must make a copy to a
>> writeable array and send a pointer to that.
>>
> No, you read the documentation.
The declaration, the types used, and the name of the function are part
of the documentation. They are particularly important parts of the
documentation, since they are the only parts that are guaranteed to be
in sync with the code. It is good practice to never put something in
comments or extra documentation if it can be expressed clearly in code -
that way it is always correct, often enforceable or checked by the
compiler and other automated checking tools, and automatically correct
in the documentation if you use tools such as doxygen.
I fully agree that the documentation is important and should be read. I
know that in practice, many people do not read documentation
sufficiently - and many people do not write sufficient documentation
(and many others fail to update and maintain it correctly).
Even the best documentation is no excuse for poor code.
> A function called strtoupper() pretty obviously
> is designed to change the string passed to it.
I disagree - it would depend on the signature and the way your API
works. If you have a type "String" that is a managed string type, and
you had a signature :
String strtoupper(String s);
then I would expect it to return a new String and leave all the caller's
data unaffected. (It would be a "Malcolm-function".)
If it were declared :
const char * strtoupper(const char * s);
then I would again expect the function to allocate new space and leave
the original string unchanged.
But if it were declared :
void strtoupper(char * s);
/then/ I would expect it to change the original string.
Mistakenly assuming that users will make correct "obvious assumptions"
about behaviour based on function names is a recipe for disaster.
> But it can't make just any change.
> The changes it does make have to be described. Similarly "show_string" may,
> fr some reason, corrupt the string and leave it in an indeterminate state, but
> that's part of the API contract.
I would suggest that anything that leaves data "corrupted and in an
indeterminate state" is a poor choice of API - even if it is documented.
(If the function is clearly a "data sink", and perhaps frees the
string's memory, that's a different matter.)
However, nothing of this gives any justification for not using "const"
on pointers when the function does not change the data.
>>
>>> Partly it's to avoid visual clutter.
>> Do you also use K&R-style implicit int to avoid clutter?
>>
> I don't, but there's a strong case for making int the default integer type and
> making the use of other types special purpose and rare. Implicit int was an
> attempt to do that, and the idea was good. But the problem was that the
> pattern "typename ... variable or functioname" was too intutitive.
The question was rhetorical. I thought that was obvious.
> >
>> It has extra relevance for small embedded systems, but it is certainly
>> not limited to such systems.
>>
> Generally data is physically writeable on large systems. So "const" is an
> artificial restriction.
RAM is generally writeable, and thus "const" is a hugely important and
useful restriction.
>>
>>> But C string literals are non-const by default, even though they are not writeable.
>>>
>> You do know that you can safely assign a pointer-to-non-const expression
>> to a pointer-to-const? The historical fact that C string literals
>> predate the "const" keyword in C does not mean you can't use const
>> pointers to point to C string literals.
>>
> You can. But it's only a safe thing to do "in the small".
Rubbish.
> In the large, tainting
> mutable data with const can mean that efficiency improvements become
> impossible.
Rubbish.
> A common situation is that the operation doens't notionally
> change the state (it returns a node in the tree, leaving the tree unaltered),
> however in reality it's seldom used for random access, but to iterate through
> all the nodes sequentially. So you can convert an O(log N) operation to an
> O(1) operation by cacheing the last access. But not if you've const-poisoned the
> tree.
You are talking about a very rare situation. The issue does arise - it
is the reason for the "mutable" keyword in C++. But it is rare, and
certainly not a rational justification for not using "const".
We are all aware that "const" can sometimes be unclear - in particular,
for complex objects, it does not pass through to objects indirectly
accessed through the higher level object. (i.e., if a type "String" is
a struct holding a length and a pointer to data, a "const String *"
pointer can still be used to modify the data pointed to by the String
object.)
That is a reason to be clear in your API design, types and
documentation. It is not a reason to abandon "const".
>>
>>> Someone might pass data intended as input to a parameter intended for output,
>>> but such a mistake would almost always be caught very early in testing.
>> And we all know that "almost always caught in testing" is /so/ much more
>> helpful than "always caught at compile time".
>>
> It's not an absolute.
It is absolutely an absolute (and obviously sarcasm). If an error can
be caught at compile time, that is better than hoping to catch it in
testing. And compile time checks do not preclude testing as well.
> Sometimes using const will help to catch a bug. But it's a
> fairly slight advantage. The main reason is that switiching input and output
> parameters will almost always be caught on the first test. But the other
> reason is that, whilst the low-level function takes const, the data in caller
> will usually be mutable. Occasionally you see
> strcpy(name, "Fred");
> but far more often it's
> strcpy(name, employee->name);
>
> const will catch strcpy("Fred", name). (Except it won't, but never mind).
> but not
> strcpy(employee->name, name);
> which is a far more likely bug.
So what?
Are you trying to claim that because "const" will not catch all bugs, it
is useless?
>
> So yes, there are few situations in which const might help you catch bugs, but
> it's not a big help, and they aren't very common.
I'm sorry, but I think you are completely wrong here. You are wrong
about the practice, you are wrong about the user experience. You are
wrong about how to write APIs and the role of declarations and
documentation. You've given no reasonable justification for not using
"const" - at least, not any justification I consider significant or that
comes close to outweighing the advantages of "const".
I consider the lack of appropriate use of "const" as a major red flag on
the quality of code, and that would affect my choice of code to use.
That's my opinion, and you are of course entirely free to disagree.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-22 05:38 -0700 |
| Message-ID | <b21393a6-c4f5-436a-9975-8ffedd6bf20bn@googlegroups.com> |
| In reply to | #172660 |
On Tuesday, 22 August 2023 at 13:10:11 UTC+1, David Brown wrote: > > I would suggest that anything that leaves data "corrupted and in an > indeterminate state" is a poor choice of API - even if it is documented. > (If the function is clearly a "data sink", and perhaps frees the > string's memory, that's a different matter.) > I just wrote a function to calculate a determinant by Gaussian elimination. Because of the way it works, the matrix is diagonalised in place. You could of course take a copy, but that woud be a memory allocation, and the main benefit of Gaussian elimination is that it is extremely fast. Or you could make the matrix a const * and pass in a workspace, but them that's not as intuitive (though I might in fact modify the function to do that). > > > A common situation is that the operation doens't notionally > > change the state (it returns a node in the tree, leaving the tree unaltered), > > however in reality it's seldom used for random access, but to iterate through > > all the nodes sequentially. So you can convert an O(log N) operation to an > > O(1) operation by cacheing the last access. But not if you've const-poisoned the > > tree. > You are talking about a very rare situation. The issue does arise - it > is the reason for the "mutable" keyword in C++. But it is rare, and > certainly not a rational justification for not using "const". > It's rare "in the small".A function to calculate the employees' average salary can take a const * and it's most unlikely to be rewritten to use the array as scratch memory space. A function that takes the "world" as a parameter but doesn't change the world's external state (maybe it renders it to a buffer) is a different matter. There might well be a tree traversal in there. > > We are all aware that "const" can sometimes be unclear - in particular, > for complex objects, it does not pass through to objects indirectly > accessed through the higher level object. (i.e., if a type "String" is > a struct holding a length and a pointer to data, a "const String *" > pointer can still be used to modify the data pointed to by the String > object.) > > That is a reason to be clear in your API design, types and > documentation. It is not a reason to abandon "const". > It is a reason to abandon const. If const * is giving a miselading message, because the pointer is in fact ebeing used to access mutable data via nested members, then I'd say you shouldn't use const qualification. > > Are you trying to claim that because "const" will not catch all bugs, it > is useless? > I said it will catch some bugs. But a limited subset of bugs, the vast majority of which are not dangerous because they mean than input and output parameters have been switched, and that will almost always come out on the first test run. But you can probably come up with a real example where that isn't the case. So it's of limited value, but not of zero value. It's not that there is no case for it a rational person could make at all. > > > > So yes, there are few situations in which const might help you catch bugs, but > > it's not a big help, and they aren't very common. > I'm sorry, but I think you are completely wrong here. You are wrong > about the practice, you are wrong about the user experience. You are > wrong about how to write APIs and the role of declarations and > documentation. You've given no reasonable justification for not using > "const" - at least, not any justification I consider significant or that > comes close to outweighing the advantages of "const". > > I consider the lack of appropriate use of "const" as a major red flag on > the quality of code, and that would affect my choice of code to use. > It appeals to a certain mindset. I agree. > > That's my opinion, and you are of course entirely free to disagree. > Baby X makes heavy use of opaque pointers and callbacks. The callbacks all take a void * for context. A lot of the time, the context data won't be modiifed, but it can't be a const void *, because the context pointer is free for the callback function to use as it sees fit. So those are two cases where data might be constant, but const is inappropriate.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-22 15:31 +0200 |
| Message-ID | <uc2dbv$2e4tg$1@dont-email.me> |
| In reply to | #172662 |
On 22/08/2023 14:38, Malcolm McLean wrote: > On Tuesday, 22 August 2023 at 13:10:11 UTC+1, David Brown wrote: >>> I would suggest that anything that leaves data "corrupted and in an >> indeterminate state" is a poor choice of API - even if it is documented. >> (If the function is clearly a "data sink", and perhaps frees the >> string's memory, that's a different matter.) >> > I just wrote a function to calculate a determinant by Gaussian elimination. > Because of the way it works, the matrix is diagonalised in place. You could > of course take a copy, but that woud be a memory allocation, and the > main benefit of Gaussian elimination is that it is extremely fast. Or you > could make the matrix a const * and pass in a workspace, but them that's > not as intuitive (though I might in fact modify the function to do that). That is a function that modifies its argument in an appropriate way, for good reason. It does not leave it in a corrupted and indeterminate state. So I do not understand your point. >> >>> A common situation is that the operation doens't notionally >>> change the state (it returns a node in the tree, leaving the tree unaltered), >>> however in reality it's seldom used for random access, but to iterate through >>> all the nodes sequentially. So you can convert an O(log N) operation to an >>> O(1) operation by cacheing the last access. But not if you've const-poisoned the >>> tree. >> You are talking about a very rare situation. The issue does arise - it >> is the reason for the "mutable" keyword in C++. But it is rare, and >> certainly not a rational justification for not using "const". >> > It's rare "in the small".A function to calculate the employees' average salary can take > a const * and it's most unlikely to be rewritten to use the array as scratch memory > space. A function that takes the "world" as a parameter but doesn't change the > world's external state (maybe it renders it to a buffer) is a different matter. There might > well be a tree traversal in there. So don't use "const" on world-changing functions. Use "const" on functions that don't change the thing being pointed at. > > >> We are all aware that "const" can sometimes be unclear - in particular, >> for complex objects, it does not pass through to objects indirectly >> accessed through the higher level object. (i.e., if a type "String" is >> a struct holding a length and a pointer to data, a "const String *" >> pointer can still be used to modify the data pointed to by the String >> object.) >> >> That is a reason to be clear in your API design, types and >> documentation. It is not a reason to abandon "const". >> > It is a reason to abandon const. Don't be so defeatist. > If const * is giving a miselading message, because > the pointer is in fact ebeing used to access mutable data via nested members, then > I'd say you shouldn't use const qualification. If you want, it is a reason not to use "const" in that particular case - it is no reason not to use "const" in other cases. (You might consider using it even in such cases, as long as there is no logical change to the user-visible data - that is how "const" is interpreted in the C++ world. Use whatever is clearest for the users of your API.) > >> >> Are you trying to claim that because "const" will not catch all bugs, it >> is useless? >> > I said it will catch some bugs. But a limited subset of bugs, the vast majority of > which are not dangerous because they mean than input and output parameters have > been switched, and that will almost always come out on the first test run. But > you can probably come up with a real example where that isn't the case. So it's > of limited value, but not of zero value. It's not that there is no case for it a rational > person could make at all. I think we see things differently here. We agree that "const" is not perfect or a magic cure for all kinds of bugs. I see the aid to the user and the implementer as being a reason to use "const" despite its limitations - you apparently see its limitations as a reason never to use it. I simply can't understand why you think that way. >>> >>> So yes, there are few situations in which const might help you catch bugs, but >>> it's not a big help, and they aren't very common. >> I'm sorry, but I think you are completely wrong here. You are wrong >> about the practice, you are wrong about the user experience. You are >> wrong about how to write APIs and the role of declarations and >> documentation. You've given no reasonable justification for not using >> "const" - at least, not any justification I consider significant or that >> comes close to outweighing the advantages of "const". >> >> I consider the lack of appropriate use of "const" as a major red flag on >> the quality of code, and that would affect my choice of code to use. >> > It appeals to a certain mindset. I agree. >> >> That's my opinion, and you are of course entirely free to disagree. >> > Baby X makes heavy use of opaque pointers and callbacks. The callbacks all > take a void * for context. A lot of the time, the context data won't be modiifed, > but it can't be a const void *, because the context pointer is free for the callback > function to use as it sees fit. > So those are two cases where data might be constant, but const is inappropriate. If it might be changed, don't use "const". No one suggested using "const" on all pointers - merely on those where there will be no change.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-22 06:51 -0700 |
| Message-ID | <d734d616-b18e-4e67-b858-f0eb0a636a87n@googlegroups.com> |
| In reply to | #172666 |
On Tuesday, 22 August 2023 at 14:32:01 UTC+1, David Brown wrote: > On 22/08/2023 14:38, Malcolm McLean wrote: > > That is a function that modifies its argument in an appropriate way, for > good reason. It does not leave it in a corrupted and indeterminate state. > If you write determinant() in the obvious way, using the recursive definition, then you wouldn't modify the matrix. If you use Gaussian elimination you diagonalise it. And it's not necessarily caller's business which algorithm is used. So it's probably better to say that, on fucntion exit, the matrix is indeterminate. (If you've got a zero on the diagonal, the elimination method will produce a divide by zero, so you have to resort to the recursive method). > > > It's rare "in the small".A function to calculate the employees' average salary can take > > a const * and it's most unlikely to be rewritten to use the array as scratch memory > > space. A function that takes the "world" as a parameter but doesn't change the > > world's external state (maybe it renders it to a buffer) is a different matter. There might > > well be a tree traversal in there. > So don't use "const" on world-changing functions. Use "const" on > functions that don't change the thing being pointed at. > Image *render(WORLD * world).is not a world-changing function, at least notionally. Nothing about the world should change as a result of a render, all the baddies and lihgts and cameras and so on should behave exactly as they did before the function was called. However in reality you are probably caching quite a lot of state. So is world a const * or not? > > > If const * is giving a miselading message, because > > the pointer is in fact ebeing used to access mutable data via nested members, then > > I'd say you shouldn't use const qualification. > If you want, it is a reason not to use "const" in that particular case - > it is no reason not to use "const" in other cases. (You might consider > using it even in such cases, as long as there is no logical change to > the user-visible data - that is how "const" is interpreted in the C++ > world. Use whatever is clearest for the users of your API.) > C+ is a different lanugage. In particular, you rarely pass const pointers, but you do pass const references. In fact you shouldn't pass non-const references at all, because then it's not obvious in caller that a variable might be modiifed. You should pass a non-const pointer. const works in a different way in C++. > > I think we see things differently here. We agree that "const" is not > perfect or a magic cure for all kinds of bugs. I see the aid to the > user and the implementer as being a reason to use "const" despite its > limitations - you apparently see its limitations as a reason never to > use it. I simply can't understand why you think that way. > Because in C const adds visual clutter. It's harder to simply glance at a function prototype and take in what it does, if it is decorated with all sorts of qualifiers. So you introduce errors as a result of code being harder to read. > > > Baby X makes heavy use of opaque pointers and callbacks. The callbacks all > > take a void * for context. A lot of the time, the context data won't be modiifed, > > but it can't be a const void *, because the context pointer is free for the callback > > function to use as it sees fit. > > So those are two cases where data might be constant, but const is inappropriate. > If it might be changed, don't use "const". No one suggested using > "const" on all pointers - merely on those where there will be no change. > With an opaque pointer, there often is no change. However if you specify that in the function interface, then it's no longer an opaque pointer.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-22 19:19 +0200 |
| Message-ID | <uc2qnl$2gh96$1@dont-email.me> |
| In reply to | #172667 |
On 22/08/2023 15:51, Malcolm McLean wrote: > On Tuesday, 22 August 2023 at 14:32:01 UTC+1, David Brown wrote: >> On 22/08/2023 14:38, Malcolm McLean wrote: >> >> That is a function that modifies its argument in an appropriate way, for >> good reason. It does not leave it in a corrupted and indeterminate state. >> > If you write determinant() in the obvious way, using the recursive definition, > then you wouldn't modify the matrix. If you use Gaussian elimination you > diagonalise it. And it's not necessarily caller's business which algorithm is > used. So it's probably better to say that, on fucntion exit, the matrix is indeterminate. I for one would not be happy with a "determinant" function that might or might not trash my matrix. If the matrix is big enough that Gaussian elimination is the best algorithm, copying it locally is negligible overhead and makes the code much easier to use. > (If you've got a zero on the diagonal, the elimination method will produce a divide > by zero, so you have to resort to the recursive method). (That is incorrect, but off-topic here. I refer you to Wikipedia, google, or any maths book on the topic.) >> >>> It's rare "in the small".A function to calculate the employees' average salary can take >>> a const * and it's most unlikely to be rewritten to use the array as scratch memory >>> space. A function that takes the "world" as a parameter but doesn't change the >>> world's external state (maybe it renders it to a buffer) is a different matter. There might >>> well be a tree traversal in there. >> So don't use "const" on world-changing functions. Use "const" on >> functions that don't change the thing being pointed at. >> > Image *render(WORLD * world).is not a world-changing function, at least notionally. > Nothing about the world should change as a result of a render, all the baddies and > lihgts and cameras and so on should behave exactly as they did before the function > was called. However in reality you are probably caching quite a lot of state. So is > world a const * or not? That's up to you. But whatever you decide, it does not stop "const" being useful other places. >> >>> If const * is giving a miselading message, because >>> the pointer is in fact ebeing used to access mutable data via nested members, then >>> I'd say you shouldn't use const qualification. >> If you want, it is a reason not to use "const" in that particular case - >> it is no reason not to use "const" in other cases. (You might consider >> using it even in such cases, as long as there is no logical change to >> the user-visible data - that is how "const" is interpreted in the C++ >> world. Use whatever is clearest for the users of your API.) >> > C+ is a different lanugage. In particular, you rarely pass const pointers, but you > do pass const references. In fact you shouldn't pass non-const references at > all, because then it's not obvious in caller that a variable might be modiifed. You > should pass a non-const pointer. > const works in a different way in C++. C++ is a different language, yes - but that does not mean you should not use "const" in C. "bool" in C++ and C are somewhat different too - does that mean you should not use "bool" in C ? >> >> I think we see things differently here. We agree that "const" is not >> perfect or a magic cure for all kinds of bugs. I see the aid to the >> user and the implementer as being a reason to use "const" despite its >> limitations - you apparently see its limitations as a reason never to >> use it. I simply can't understand why you think that way. >> > Because in C const adds visual clutter. What you call "visual clutter", other people call useful information. > It's harder to simply glance at a > function prototype and take in what it does, if it is decorated with all sorts > of qualifiers. So you introduce errors as a result of code being harder to read. This is from the person who thinks "thisfunctionhasaperfectlygoodname" is easy to read? Surely you are joking. >> >>> Baby X makes heavy use of opaque pointers and callbacks. The callbacks all >>> take a void * for context. A lot of the time, the context data won't be modiifed, >>> but it can't be a const void *, because the context pointer is free for the callback >>> function to use as it sees fit. >>> So those are two cases where data might be constant, but const is inappropriate. >> If it might be changed, don't use "const". No one suggested using >> "const" on all pointers - merely on those where there will be no change. >> > With an opaque pointer, there often is no change. However if you specify that in > the function interface, then it's no longer an opaque pointer. As long as you use "void *" pointers, they are opaque, whether "const" or not. (I'm not keen on "void *" - it is often an excuse not to give more informative and safer types. But it has its uses sometimes.)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-22 21:59 -0700 |
| Message-ID | <d651e08e-033d-4a90-8477-6a5fa13d30f3n@googlegroups.com> |
| In reply to | #172684 |
On Tuesday, 22 August 2023 at 18:20:05 UTC+1, David Brown wrote: > On 22/08/2023 15:51, Malcolm McLean wrote: > > On Tuesday, 22 August 2023 at 14:32:01 UTC+1, David Brown wrote: > >> On 22/08/2023 14:38, Malcolm McLean wrote: > >> > >> That is a function that modifies its argument in an appropriate way, for > >> good reason. It does not leave it in a corrupted and indeterminate state. > >> > > If you write determinant() in the obvious way, using the recursive definition, > > then you wouldn't modify the matrix. If you use Gaussian elimination you > > diagonalise it. And it's not necessarily caller's business which algorithm is > > used. So it's probably better to say that, on fucntion exit, the matrix is indeterminate. > I for one would not be happy with a "determinant" function that might or > might not trash my matrix. If the matrix is big enough that Gaussian > elimination is the best algorithm, copying it locally is negligible > overhead and makes the code much easier to use. > No, that's not the case. These sorts of calculation tend to be in the inner algorithmic core of the application. > > (If you've got a zero on the diagonal, the elimination method will produce a divide > > by zero, so you have to resort to the recursive method). > (That is incorrect, but off-topic here. I refer you to Wikipedia, > google, or any maths book on the topic.) > No, it's a known problem. > > "bool" in C++ and C are somewhat different too - does that mean you > should not use "bool" in C ? > No, you shouldn't use bool in C. In C we use zero as false, non-zero as true, and that doesn't play well with a boolean type. There is a case for returning "bool" from a function, but it's deeply problematic to pass a bool as a parameter. The reason is that drawpath(mypath, false); is meaningless to a person reading the code. It should be drawpath(mypath, PATH_OPEN) ; Now we've at least some idea what the parameter means. So it needs to be an enum or a defined integer constnat, not a bool. So bool is pretty useless and we're better off without it. > > > It's harder to simply glance at a > > function prototype and take in what it does, if it is decorated with all sorts > > of qualifiers. So you introduce errors as a result of code being harder to read. > This is from the person who thinks "thisfunctionhasaperfectlygoodname" > is easy to read? Surely you are joking. > You've got the highighting paradox. THIS IS BIG is easy to read. But text larded with lots of capitals is far harder to read. Similarly one camelCase or under_score is easy to read, when embedded in lower case text, but when you have many such names, the text becomes quite hard to read Your example refutes itself, and the text is quite easy to read. In fact, as you are obviously not aware, scripto continua was the norm for ancient manuscripts.. > > > With an opaque pointer, there often is no change. However if you specify that in > > the function interface, then it's no longer an opaque pointer. > As long as you use "void *" pointers, they are opaque, whether "const" > or not. (I'm not keen on "void *" - it is often an excuse not to give > more informative and safer types. But it has its uses sometimes.) > A const void * is not an opaque pointer. We can say something about how the called function will handle the data it points to.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-23 09:57 +0200 |
| Message-ID | <uc4e4t$2rdlt$1@dont-email.me> |
| In reply to | #172690 |
On 23/08/2023 06:59, Malcolm McLean wrote: > On Tuesday, 22 August 2023 at 18:20:05 UTC+1, David Brown wrote: >> On 22/08/2023 15:51, Malcolm McLean wrote: >>> On Tuesday, 22 August 2023 at 14:32:01 UTC+1, David Brown wrote: >>>> On 22/08/2023 14:38, Malcolm McLean wrote: >>>> >>>> That is a function that modifies its argument in an appropriate way, for >>>> good reason. It does not leave it in a corrupted and indeterminate state. >>>> >>> If you write determinant() in the obvious way, using the recursive definition, >>> then you wouldn't modify the matrix. If you use Gaussian elimination you >>> diagonalise it. And it's not necessarily caller's business which algorithm is >>> used. So it's probably better to say that, on fucntion exit, the matrix is indeterminate. >> I for one would not be happy with a "determinant" function that might or >> might not trash my matrix. If the matrix is big enough that Gaussian >> elimination is the best algorithm, copying it locally is negligible >> overhead and makes the code much easier to use. >> > No, that's not the case. These sorts of calculation tend to be in the inner algorithmic > core of the application. Experience in this group has taught me that your ideas of how things "tend to be" is usually different from other people's. (Equally, I do not expect you to give much credence to vague and unreferenced assertions from me.) All I can tell you here is that /I/ would not expect a "determinant" function to trash the matrix I pass to it. If /I/ were writing a determinate function, I would do so in a way that did not trash the caller's data, and did not take noticeably longer. And if I were convinced that some operations, such as this one, were significantly more efficient without copying, and destruction was fine for a significant proportion of use-cases, I'd make an explicit "determinant_destructive" version. The non-destructive version would, of course, take a const pointer. In no circumstances would I make a function that left the caller's data "corrupt" or "indeterminate". (Oh, and I'd write it in C++ to give a much better user API here. C's great for some things - but it's not the best choice for everything.) >>> (If you've got a zero on the diagonal, the elimination method will produce a divide >>> by zero, so you have to resort to the recursive method). >> (That is incorrect, but off-topic here. I refer you to Wikipedia, >> google, or any maths book on the topic.) >> > No, it's a known problem. I note you haven't actually looked at references for it. It is a known /consideration/ - not a known /problem/. When you hit a row with a zero on the diagonal, you simply swap it with a row further down that does not have zero in that column. Swapping rows multiplies the determinant by -1. If there is no such row, the determinant is 0. (In fact, it is common to swap rows for Gaussian elimination anyway to improve numerical stability. But that is definitely off-topic here.) >> >> "bool" in C++ and C are somewhat different too - does that mean you >> should not use "bool" in C ? >> > No, you shouldn't use bool in C. In C we use zero as false, non-zero as true, > and that doesn't play well with a boolean type. There is a case for returning > "bool" from a function, but it's deeply problematic to pass a bool as a parameter. Sorry, but that again is /utter/ bollocks. _Bool has been a type in C since C99, and is a far more natural choice than "int" for true/false indications. > The reason is that > > drawpath(mypath, false); > > is meaningless to a person reading the code. > It should be > > drawpath(mypath, PATH_OPEN) ; > > Now we've at least some idea what the parameter means. So it needs to be an enum > or a defined integer constnat, not a bool. Do you really believe you are making a sound argument here? Or do you realise that you are conflating completely different concepts? I'm trying to think of a single example in this thread where you have actually addressed the question, and actually justified your decisions. But it's just a field of straw men fishing for red herrings. > > So bool is pretty useless and we're better off without it. No, bool is pretty useful and we are better off having it. It does not replace "enum", it replaces a 0/1 int. >> >>> It's harder to simply glance at a >>> function prototype and take in what it does, if it is decorated with all sorts >>> of qualifiers. So you introduce errors as a result of code being harder to read. >> This is from the person who thinks "thisfunctionhasaperfectlygoodname" >> is easy to read? Surely you are joking. >> > You've got the highighting paradox. I note that when you try to join multiple words together without any kind of separation, you make spelling mistakes. Normally I would not comment on typos in a Usenet post, but surely you see the irony? You want to use ridiculous names for your API functions, yet regularly fail to spot errors in longer words in your prose. > THIS IS BIG is easy to read. But text larded > with lots of capitals is far harder to read. Similarly one camelCase or under_score > is easy to read, when embedded in lower case text, but when you have many > such names, the text becomes quite hard to read > > Your example refutes itself, and the text is quite easy to read. Are you /seriously/ suggesting that "readfilefromdisk" is easy to read? Better than, say, "read_file_from_disk" or "readFileFromDisk" ? (Not that I think the camel-case version is particularly easy to read here - but it is a world better than your choice of jumble.) > In fact, as you > are obviously not aware, scripto continua was the norm for ancient manuscripts.. I am entirely aware of that. I have not studied such things academically, but I have a far above average interest in history and writing systems. Are you aware of /why/ ancient manuscripts (and other old writing) was regularly written without spacing? I'll give you a clue - it was /not/ in order to make the text easier to read. >> >>> With an opaque pointer, there often is no change. However if you specify that in >>> the function interface, then it's no longer an opaque pointer. >> As long as you use "void *" pointers, they are opaque, whether "const" >> or not. (I'm not keen on "void *" - it is often an excuse not to give >> more informative and safer types. But it has its uses sometimes.) >> > A const void * is not an opaque pointer. We can say something about how the > called function will handle the data it points to. Yes - that's a good thing.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-23 07:48 -0700 |
| Message-ID | <1e79f8a1-b707-4074-b272-ce4327ee7bc0n@googlegroups.com> |
| In reply to | #172692 |
On Wednesday, 23 August 2023 at 08:57:32 UTC+1, David Brown wrote: > On 23/08/2023 06:59, Malcolm McLean wrote: > > All I can tell you here is that /I/ would not expect a "determinant" > function to trash the matrix I pass to it. If /I/ were writing a > determinate function, I would do so in a way that did not trash the > caller's data, and did not take noticeably longer. And if I were > convinced that some operations, such as this one, were significantly > more efficient without copying, and destruction was fine for a > significant proportion of use-cases, I'd make an explicit > "determinant_destructive" version. The non-destructive version would, > of course, take a const pointer. I don't need the matrix after taking the determinant. And at the moment, I don't have another use for the function. There's a trade-off between speed and good interfaces, and I might change it to retain the matrix. There might also be a faster way of obtaining the information I need. My own mathematical ability is also a constraint. > > In no circumstances would I make a function that left the caller's data > "corrupt" or "indeterminate". > > (Oh, and I'd write it in C++ to give a much better user API here. C's > great for some things - but it's not the best choice for everything.) > No, it's far better in C. In C++ it would pull in a "Matrix" class, and then it's totally unusable in another program unless someone wants to take that entire apparatus. > > > No, it's a known problem. > I note you haven't actually looked at references for it. It is a known > /consideration/ - not a known /problem/. When you hit a row with a zero > on the diagonal, you simply swap it with a row further down that does > not have zero in that column. Swapping rows multiplies the determinant > by -1. If there is no such row, the determinant is 0. (In fact, it is > common to swap rows for Gaussian elimination anyway to improve numerical > stability. But that is definitely off-topic here.) > My matrix will occasionally have a zero in the top left hand cell. (It's a Sylvester matrix giving the coefficients of two simulataneous equations, and the determinant represents the product of the difference of the roots, plus a term based on the highest coefficents. If the determiant is zero or so close to zero that it represents machine precision problems, then the equations have a root in common, which is what I'm interested in. However because of the factor based on the highest coefficients, it's useless to me if the top left is zero. However I have to do something. > > Do you really believe you are making a sound argument here? Or do you > realise that you are conflating completely different concepts? I'm > trying to think of a single example in this thread where you have > actually addressed the question, and actually justified your decisions. > But it's just a field of straw men fishing for red herrings. > If you provide aboolean type then you encourage people to write functions that take boolean parameters. Of course intelligent people like you and I can see, as soon as the problem is pointed out, that this isn't a good idea, and will have the self-discipline to write enums. But a lot of people won't. So it's better not to have a boolean type. Of course they can still pass "1" or "0" in an int, but at least this isn't beign actively encouraged. > > So bool is pretty useless and we're better off without it. > No, bool is pretty useful and we are better off having it. > It's useful where a function returns a boolean true / false value whose meaning is obvious from the function definition. And it is useful in marking fields of structures which are logically true / false (though here it can be a rather extravagant use of memory and you might be better off with bitfields). But these are minor aids to readability, whilst boolean parameters are major impediments to readability. The there's the if (value == true) problem. > > Are you /seriously/ suggesting that "readfilefromdisk" is easy to read? > Better than, say, "read_file_from_disk" or "readFileFromDisk" ? (Not > that I think the camel-case version is particularly easy to read here - > but it is a world better than your choice of jumble.) > In programs, yes. Because you have many identifiers all jostling for attention. As a single word in flowing lowercase text, the decorated version is maybe easier to read. > > In fact, as you > > are obviously not aware, scripto continua was the norm for ancient manuscripts.. > I am entirely aware of that. I have not studied such things > academically, but I have a far above average interest in history and > writing systems. Are you aware of /why/ ancient manuscripts (and other > old writing) was regularly written without spacing? I'll give you a > clue - it was /not/ in order to make the text easier to read. > I'm not arguing that text without spaces is easier to read than text with spaces. However spaces in C identifiers are not allowed. The fact that for many hundereds of years people wrote text without spaces tells you that, though it's less readable than text with spaces, it's not that difficult to read. > > > A const void * is not an opaque pointer. We can say something about how the > > called function will handle the data it points to. > Yes - that's a good thing. But it's not an opaque pointer any more.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-23 16:05 +0100 |
| Message-ID | <uc5783$2vd55$1@dont-email.me> |
| In reply to | #172697 |
On 23/08/2023 15:48, Malcolm McLean wrote: > On Wednesday, 23 August 2023 at 08:57:32 UTC+1, David Brown wrote: >> On 23/08/2023 06:59, Malcolm McLean wrote: > I'm not arguing that text without spaces is easier to read than text with > spaces. However spaces in C identifiers are not allowed. The fact that > for many hundereds of years people wrote text without spaces Where did they do that? I guess you'd not talking about programming syntax. tells you > that, though it's less readable than text with spaces, it's not that difficult > to read. It can sometimes lead to ambiguities when word boundaries are not marked. Eg. #amazonshitcarshow
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-23 08:21 -0700 |
| Message-ID | <af0dbbdb-3f59-46e3-9d61-36c327a7d141n@googlegroups.com> |
| In reply to | #172698 |
On Wednesday, 23 August 2023 at 16:05:55 UTC+1, Bart wrote: > On 23/08/2023 15:48, Malcolm McLean wrote: > > On Wednesday, 23 August 2023 at 08:57:32 UTC+1, David Brown wrote: > >> On 23/08/2023 06:59, Malcolm McLean wrote: > > > I'm not arguing that text without spaces is easier to read than text with > > spaces. However spaces in C identifiers are not allowed. The fact that > > for many hundereds of years people wrote text without spaces > Where did they do that? I guess you'd not talking about programming syntax. > tells you > The modern system of separating words by spaces was only introduced in about the seventh century, by Irish monks. The earliest classical texts we have use dots or lines to separate words, but fairly soon that was dropped and all the words were simply run together. That was in use for about 2,000 years. > > that, though it's less readable than text with spaces, it's not that difficult > > to read. > It can sometimes lead to ambiguities when word boundaries are not marked. > > Eg. #amazonshitcarshow > Yes. Spaces are better. Although spoken language doesn't usually have pauses between words. The question is what to do for C identifiers, where spaces are not allowed. The scriptio continua system was used for a very long time, so it must have at least something going for it.
[toc] | [prev] | [next] | [standalone]
Page 2 of 15 — ← Prev page 1 [2] 3 4 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web