Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #394664 > unrolled thread
| Started by | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| First post | 2025-10-22 14:39 -0700 |
| Last post | 2025-10-27 11:51 -0700 |
| Articles | 20 on this page of 196 — 19 participants |
Back to article view | Back to comp.lang.c
New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-22 14:39 -0700
Re: New and improved version of cdecl Thiago Adams <thiago.adams@gmail.com> - 2025-10-22 22:19 -0300
Re: New and improved version of cdecl Ben Bacarisse <ben@bsb.me.uk> - 2025-10-23 02:42 +0100
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-23 03:04 +0000
Re: New and improved version of cdecl Ben Bacarisse <ben@bsb.me.uk> - 2025-10-23 15:05 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-23 11:36 +0100
Re: New and improved version of cdecl Thiago Adams <thiago.adams@gmail.com> - 2025-10-23 07:59 -0300
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-23 16:04 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-24 01:44 +0100
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-23 19:00 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-24 14:27 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-24 19:35 +0200
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-24 19:50 +0100
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-24 18:59 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-24 13:20 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-24 23:18 +0100
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-26 07:25 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-26 11:26 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-26 13:26 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-26 16:07 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-26 17:03 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-26 16:04 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-26 16:58 +0000
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-26 17:27 +0000
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-26 22:49 +0200
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-26 23:07 +0200
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-28 18:01 +0000
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-29 20:33 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 23:29 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-26 16:07 -0700
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-27 03:08 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-27 12:50 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-27 12:58 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-27 14:45 +0100
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-27 14:48 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-27 15:23 +0000
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-27 22:39 +0200
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 03:00 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-28 15:59 +0100
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-28 16:05 +0000
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-28 20:00 +0200
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-28 18:28 +0000
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-28 20:49 +0200
Re: New and improved version of cdecl Ben Bacarisse <ben@bsb.me.uk> - 2025-10-29 21:30 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 20:32 +0100
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 20:14 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-29 16:36 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 17:24 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-27 14:39 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-27 15:11 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 03:35 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 11:16 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-28 14:59 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 23:14 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-28 18:48 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 19:24 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-29 15:10 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 23:19 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-29 18:03 -0700
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 09:02 +0100
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-29 08:06 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 11:20 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-29 17:12 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 21:21 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 00:04 +0100
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-29 16:47 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 00:36 +0000
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-30 03:37 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-29 21:24 -0700
Re: New and improved version of cdecl vallor <vallor@vallor.earth> - 2025-10-30 04:52 +0000
Re: New and improved version of cdecl vallor <vallor@vallor.earth> - 2025-10-30 05:38 +0000
Re: New and improved version of cdecl Richard Heathfield <rjh@cpax.org.uk> - 2025-10-30 07:45 +0000
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-30 16:41 +0200
Re: New and improved version of cdecl richard@cogsci.ed.ac.uk (Richard Tobin) - 2025-10-30 16:26 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-30 17:30 +0000
Re: New and improved version of cdecl richard@cogsci.ed.ac.uk (Richard Tobin) - 2025-10-30 18:29 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-30 18:37 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-30 13:21 -0700
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-31 07:44 +0100
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-31 07:49 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 12:50 +0100
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-31 00:27 +0000
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-30 17:35 -0700
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-30 14:13 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 14:32 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-30 16:22 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 17:40 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 12:39 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-31 13:57 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 14:55 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-31 17:18 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 17:52 +0000
Re: New and improved version of cdecl tTh <tth@none.invalid> - 2025-10-30 05:00 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 11:15 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 12:07 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 16:04 +0100
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-30 18:30 +0200
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 17:49 +0000
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-30 18:59 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 23:23 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-30 16:44 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 00:15 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-30 18:16 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 01:36 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-30 19:13 -0700
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-31 13:43 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-31 13:10 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 16:34 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 23:01 +0100
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-31 00:28 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 01:22 +0000
Re: New and improved version of cdecl tTh <tth@none.invalid> - 2025-10-31 10:29 +0100
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-31 13:15 +0200
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-31 21:39 +0000
Re: New and improved version of cdecl richard@cogsci.ed.ac.uk (Richard Tobin) - 2025-10-31 11:43 +0000
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-31 22:47 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-31 13:16 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 23:40 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-31 17:14 -0700
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-31 09:31 +0100
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-30 23:11 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 23:49 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 02:14 +0000
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-31 22:01 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-11-01 11:57 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-11-01 14:56 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-30 13:37 -0700
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 23:37 +0100
Re: New and improved version of cdecl tTh <tth@none.invalid> - 2025-10-31 11:52 +0100
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-31 13:48 +0000
Re: New and improved version of cdecl vallor <vallor@vallor.earth> - 2025-10-29 23:11 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-29 06:57 +0100
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-29 14:17 +0200
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 14:40 +0000
Re: New and improved version of cdecl tTh <tth@none.invalid> - 2025-10-29 16:09 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 16:47 +0000
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-30 05:11 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 12:56 +0000
Re: New and improved version of cdecl James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-10-28 17:34 -0400
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-31 04:37 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-27 13:31 -0700
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-27 20:52 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-27 17:30 -0700
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-27 19:11 -0700
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-27 19:59 -0700
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-27 23:45 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 10:27 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 01:22 +0000
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-28 17:03 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 22:26 +0000
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-29 00:04 +0000
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-26 13:15 +0200
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-26 14:56 -0700
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-27 00:34 +0200
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-26 15:45 -0700
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-27 01:12 +0200
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-26 16:15 -0700
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-28 14:56 +0200
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 13:18 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-28 15:03 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 16:16 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-25 13:04 +0200
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-25 13:51 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-25 17:18 +0200
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-26 07:44 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-26 15:12 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-27 10:44 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-27 11:22 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-27 17:35 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-27 17:44 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 04:10 +0100
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-27 23:47 -0700
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-27 22:33 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 04:23 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-28 16:20 +0100
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-27 13:48 -0700
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 04:41 +0100
Re: New and improved version of cdecl James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-10-25 11:40 -0400
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-25 16:48 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-25 19:14 +0200
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-25 15:14 -0700
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-26 08:07 +0100
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-24 21:36 +0200
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-24 13:07 -0700
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-25 13:15 +0200
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-24 13:01 -0700
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-24 15:01 -0700
Re: New and improved version of cdecl Andrey Tarasevich <noone@noone.net> - 2025-10-26 12:09 -0700
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-26 15:36 -0700
Re: New and improved version of cdecl "Paul J. Lucas" <paul@lucasmail.org> - 2025-12-09 07:31 -0800
Re: New and improved version of cdecl Kaz Kylheku <046-301-5902@kylheku.com> - 2025-12-09 20:38 +0000
Re: New and improved version of cdecl "Paul J. Lucas" <paul@lucasmail.org> - 2025-12-09 16:46 -0800
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-09 17:51 -0800
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-26 14:44 -0700
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-26 15:38 -0700
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-27 11:51 -0700
Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-28 16:16 +0000 |
| Message-ID | <10dqq8o$257n2$1@dont-email.me> |
| In reply to | #394886 |
On 28/10/2025 15:03, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>> On 28/10/2025 12:56, Michael S wrote:
>>> On Sun, 26 Oct 2025 15:45:34 -0700
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>
>>>> Michael S <already5chosen@yahoo.com> writes:
>>>>> On Sun, 26 Oct 2025 14:56:56 -0700
>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>>> Michael S <already5chosen@yahoo.com> writes:
>>>>>>> On Fri, 24 Oct 2025 13:20:45 -0700
>>>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>>> [...]
>>>>>>>> Free software still has to be usable. cdecl is usable for most
>>>>>>>> of us.
>>>>>>>>
>>>>>>>> [...]
>>>>>>>>
>>>>>>>
>>>>>>> I'd say that it is not sufficiently usable for most of us to
>>>>>>> actually use it.
>>>>>>
>>>>>> Why do you say that?
>>>>>
>>>>> I would guess that less than 1 per cent of C programmers ever used
>>>>> it and less than 5% of those who used it once continued to use it
>>>>> regularly.
>>>>> All numbers pulled out of thin air...
>>>>
>>>> So it's about usefulness, not usability. You're not saying that
>>>> it works incorrectly or that it's difficult to use (which would be
>>>> usability issues), but that the job it performs is not useful for
>>>> most C programmers.
>>>>
>>>> (One data point: I use it occasionally.)
>>>>
>>>
>>> Few minutes ago I typed 'pacman -S cdecl' at my msys2 command prompt.
>>> Then I hit Y at suggestion to proceed with installation. After another
>>> second or three I got it installed. Then tried it and even managed to
>>> get couple of declarations properly explained.
>>> So, now I also belong to less than 1 per cent :-)
>>>
>>> In the process I finally understand why the build process is none-trivial.
>>> It's mostly because of interactivity.
>>> It's very hard to build decent interactive program in portable subset
>>> of C. Or, may be, even impossible rather than hard.
>>
>>
>> I don't understand. What's hard about interactive programs?
>>
>> The problem below, which is in standard C and runs on both Windows and
>> Linux, should give you all the interativity needed for a program like CDECL.
>>
>> It reads a line of input, and prints something based on that. In between
>> would go all the non-interactive processing that it needs to do (parse
>> the line and so on).
>>
>> So what's missing that could render this task impossible?
>>
>> (Obviously, it will need a keyboard and display!)
>>
>> ----------------------------------------
>> #include <stdio.h>
>> #include <string.h>
>>
>> int main() {
>> char buffer[1000];
>>
>> puts("Type q to quit:");
>>
>> while (1) {
>> printf("Cdecl> ");
>> fgets(buffer, sizeof(buffer), stdin);
>> if (buffer[0] == 'q') break;
>>
>> printf("Input was: %s\n", buffer);
>> }
>> }
>
> Where is the command line editing and history support
> in this trivial application?
On Windows, that seems to work anyway: you can edit and navigate within
a line, or use Up/Down to retrieve previous lines.
On WSL, only backspace works, others keys show the escape sequences.
It's the same with the RPi.
I'd never noticed before that Linux line input doesn't provide these
fundamentals.
Still, it will suffice for the simple task that Cdecl has to do.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-10-25 13:04 +0200 |
| Message-ID | <10dias4$37h93$1@dont-email.me> |
| In reply to | #394713 |
On 24/10/2025 20:50, bart wrote: > On 24/10/2025 18:35, David Brown wrote: >> On 24/10/2025 15:27, bart wrote: >>> On 24/10/2025 03:00, Keith Thompson wrote: >>>> bart <bc@freeuk.com> writes: >>>>> On 24/10/2025 00:04, Keith Thompson wrote: >>>>>> bart <bc@freeuk.com> writes: >>>> [...] >>>> >>>> I note that you've ignored the vast majority of my previous article. >>> >>> I've noted it, but chose not to reply. You have a point of view and >>> attitude which I don't share. >>> >>> Mainly that you don't care how complicated a program for even a >>> simple task is, and how laborious and OS-dependent its build process >>> is, so long as it (eventually) works. >>> >>> That it favours your own OS, leaving users of other to have to jump >>> through extra hoops, doesn't appear to bother you. >>> >> >> Why would someone care what how someone else writes their code, or >> what it does, or what systems it runs on? They guy who wrote cdecl >> gets to choose exactly how he wants to write it, and what systems it >> supports. We others get it for free - we can use it if we like and it >> if it suits our needs. But neither Keith nor anyone else paid that >> guy to do the work, or contributed anything to the task, and we have >> no right to judge what he choose to do, or how he choose to do it. > > This a curious argument: it's free software so you don't care in the > slightest how efficient it is or how user-friendly it might be to build? > If I find that installing or using software is difficult, then I would look elsewhere for alternatives that worked better for me. But unless the software author is doing some kind of harm to other people (such as knowingly or intentionally giving incorrect results from his program, or violating other people's copyrights or "stealing" their work), who am I to judge how he choices to write his software? He makes his own decisions on how to write it, and I make my own decisions on whether or not to use it. Equally, as he has chosen to publish the software under the GPL, he has no right to judge or care about how I use the software. Of course people can have opinions, and express them, but that's very different from having some sort of requirement to be bothered about something we don't feel is as good as it could be. (And in this case, I don't see that the software is too big, given what it does, and I don't see the build process as unduly difficult, given the author's preferences, interests and aims. And no doubt someone will publish an easy to install Windows build of it sooner or later.) > This is a program that reads lines of text from the terminal and > translates them into another line of text. THAT needs thirty thousand > lines of configure script?! And that's even before you start compiling > the program itself. > > I'm thinking of making available some software that does even less, but > wrap enough extra and POINTLESS levels complexity around that you'd need > to lease time on a super-computer to build it. But the software is free > so that makes it alright? > Feel free do to that if you like. If it is useful enough, people might use it - if it is not, then they won't. No one is going to complain if you publish such software. >> >>> >>> >>> Well I built cdecl too, under WSL. Jesus, that looked a lot of work! >> >> I have no experience with WSL, so I can't comment on the effort there. > > I was talking about all the stuff scrolling endlessly up to the screen > for a minute and a half while running the configure script and then > compiling the modules. > You are getting worked up about some text output that scrolled "endlessly" for a minute and a half? (Do you spot the exaggeration here?) Of course it is less of an issue for me - "./configure" took a mere 10 seconds on my ten year old machine. But even at a minute and a half, it's just a task that the computer runs, once, and it is done without effort. Try relaxing a little more, and perhaps use that minute and a half to stretch your legs or drink some coffee, rather than to build up a pointless fury. >>> That program is 2.8 MB (10 times the size of my C compiler). >> >> First, as usual, nobody cares about a couple of megabytes. Secondly, >> if you /do/ care, then you might do at least a /tiny/ bit of >> investigation. First, run "strip" on it to remove debugging symbols >> - now it is a bit over 600 KB. By running "strings" on it, I can see >> that about 100 KB is strings - messages, rules, types, keywords, etc. > > If I was directly building it myself, then I would use -s with gcc. But > since the process is automatic via makefiles, I assumed it would give me > a working, production version, not a version needing to be debugged! > Actually, on closer checking (not because /I/ care, but because /you/ apparently care) it was not debugging information, but all the linking and symbolic information that is a normal part of elf format files when they are built (allowing for incremental linking, using the files as static libraries for other programs, tracing the programs, fault-finding, etc.). Sometimes build processes strip these as part of their build or "make install" process (indeed there is a "make install-strip" option). Usually it doesn't matter much on *nix systems - after all, the extra disk space has a cost of about a microdollar and the OS won't even bother reading that part of the elf file into ram when running the program. >> It is entirely possible that your little alternative is a useful >> program and does what you personally want and need with a smaller >> executable. But cdecl does a great deal more, > > CDECL translates a single C type specification into linear LTR form. Or > vice versa. That's what nearly everyone needs it for, and why it exists. > Why, what other stuff does it do? > RTFM. > So, yes, anyone with an inquiring mind can form an idea of how much code > might be needed for such a task, and how it ought to compare with a > complete language implementations. > > In fact, people have posted algorithms here for doing exactly the same. > I don't recall that they took tens of thousands of lines to describe. > >> doing things that other people need and want (like handling C++ >> declarations - surely 100 times more effort than handling C >> declarations, especially the limited older standards you use). > > So, it's a hundred times bigger than necessary due to C++. That explains > that then. (Sorry, 20 times bigger because whoever provided the build > system decided it should include debug info to make it 5 times as big > for no reason.) It is not a program for expanding or explaining C declarations. It is a program for expanding or explaining C and C++ declarations. C++ is not "unnecessary", it is part of what it does. Feel free to imagine that you could do much better, in orders of magnitude less space. Feel free to say so. But don't feel free to berate others for "not caring", and don't feel free to post self-righteous crap that somehow blames people here for other people's code.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-25 13:51 +0100 |
| Message-ID | <10dih4v$3ano2$1@dont-email.me> |
| In reply to | #394722 |
On 25/10/2025 12:04, David Brown wrote: > On 24/10/2025 20:50, bart wrote: > You are getting worked up about some text output that scrolled > "endlessly" for a minute and a half? You don't know when it's happening how long it will end up taking. In the past, and on a slower machine with a spinning hard drive, some builds have taken the best part of an hour (one for a binary that would have been only 0.5MB). But on the same machine, my stuff still worked more or less instantly. >> If I was directly building it myself, then I would use -s with gcc. >> But since the process is automatic via makefiles, I assumed it would >> give me a working, production version, not a version needing to be >> debugged! >> > > Actually, on closer checking (not because /I/ care, but because /you/ > apparently care) it was not debugging information, but all the linking > and symbolic information that is a normal part of elf format files when > they are built (allowing for incremental linking, using the files as > static libraries for other programs, tracing the programs, fault- > finding, etc.). From looking at the C sources which are 50Kloc (68Kloc with headers), I'd expect an executable for x64 to be upwards of 500KB. I think 600KB was mentioned as the stripped size. This is one way of spotting if an executable is unreasonably large. This can be important, even if you have vast amounts of storage. For example, it might have been tampered with somehow. In any case, it is suspicious and worth investigating. >> CDECL translates a single C type specification into linear LTR form. >> Or vice versa. That's what nearly everyone needs it for, and why it >> exists. Why, what other stuff does it do? >> > > RTFM. OK, it does rather more than the --help summary suggests. It includes defining typedefs for example (I haven't tried it). For my purposes, CDECL has always been buggy in the past and not so useful (I used the online version). In any case, sometimes you want to 'explain' some complex type in someone else's code, which involves macros and/or typedefs defined 1000s of lines earlier, or in some nested header. Then you can't just extract the line and give it to CDECL. This is why my older compiler included special directives that could be temporarily inserted into the code, and would generate the info during compilation. >> So, it's a hundred times bigger than necessary due to C++. That >> explains that then. (Sorry, 20 times bigger because whoever provided >> the build system decided it should include debug info to make it 5 >> times as big for no reason.) > > It is not a program for expanding or explaining C declarations. It is a > program for expanding or explaining C and C++ declarations. C++ is not > "unnecessary", it is part of what it does. This is another matter. The CDECL docs talk about C and C++ type declarations being 'gibberish'. What do you feel about that, and the *need* for such a substantial tool to help understand or write such declarations? I would rather have put some effort into fixing the syntax so that such tools are not necessary!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-10-25 17:18 +0200 |
| Message-ID | <10dipo6$3dtld$1@dont-email.me> |
| In reply to | #394724 |
On 25/10/2025 14:51, bart wrote: > This is another matter. The CDECL docs talk about C and C++ type > declarations being 'gibberish'. > > What do you feel about that, and the *need* for such a substantial tool > to help understand or write such declarations? > > I would rather have put some effort into fixing the syntax so that such > tools are not necessary! Most C and C++ programmers don't need such tools - they are /not/ necessary. They can sometimes save a little effort when you have to deal with poorly written code from elsewhere, or when you are faced with code written in a substantially different style from what you usually see. I don't think more than a very small proportion of C or C++ programmers use cdecl (online or offline), at least not on a regular basis. Neither language requires that declarations be "gibberish" - but both language syntaxes allow people to write gibberish. The same applies to your language, and any other language. The sole reason why you think that your language's syntax is clear is because the only examples you ever see, you wrote yourself - and thus you understand them. That does not mean that I or anyone else thinks that C's syntax is "perfect" in any sense. But it is good enough, and we all understand that different programmers will have different ideas about what to "fix". The only possible way to get a language that any one person thinks is ideal and always clear and simple, is for that person to design their own language according to their own needs and preferences. And from your example, we know that even that doesn't always work - you have on multiple occasions said you don't know details of your own languages. And I'd love to hear your plan for "fixing" the syntax of C - noting that changing the syntax of C means getting the C standards committee to accept your suggestions, getting at least all major C compilers to support them, and getting the millions of C programmers to use them.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-10-26 07:44 +0100 |
| Message-ID | <10dkfvn$3rcsv$1@dont-email.me> |
| In reply to | #394725 |
On 25.10.2025 17:18, David Brown wrote: > On 25/10/2025 14:51, bart wrote: >> [...] > [...] > > And I'd love to hear your plan for "fixing" the syntax of C - noting > that changing the syntax of C means getting the C standards committee to > accept your suggestions, getting at least all major C compilers to > support them, and getting the millions of C programmers to use them. I don't think that works. - If I see what they've done (to "C" and to "C++") to fix (or add) things; it seems it's rather getting worse. And, in that light, whom do you do a favor with such changes; if you want to stay widely compatible you can't really fix it (but details). Don't forget that bart's criticism had (at least partly) touched even the heart of "C" design. - There's a reason why so many new languages appear, and some even get established. Janis
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-26 15:12 +0000 |
| Message-ID | <10dldp9$2igd$1@dont-email.me> |
| In reply to | #394725 |
On 25/10/2025 16:18, David Brown wrote:
> On 25/10/2025 14:51, bart wrote:
>
>> This is another matter. The CDECL docs talk about C and C++ type
>> declarations being 'gibberish'.
>>
>> What do you feel about that, and the *need* for such a substantial
>> tool to help understand or write such declarations?
>>
>> I would rather have put some effort into fixing the syntax so that
>> such tools are not necessary!
> And I'd love to hear your plan for "fixing" the syntax of C - noting
> that changing the syntax of C means getting the C standards committee to
> accept your suggestions, getting at least all major C compilers to
> support them, and getting the millions of C programmers to use them.
I have posted such proposals in the past (probably before 2010).
I can't remember the exact details, but I think it is possible to
superimpose LTR type syntax on top of the existing language.
It's clear however that nobody would be interested in actually doing
that. I might have done it as a proof of concept, but with little
appetite (it only fixes a fraction of what I'd like to change).
If creating such a proposal today, I think it would require two new
keywords, for example:
ref replaces '*' for pointer modifiers
func marks functions otherwise there is too much ambiguity and
confusion
The above two could be type-spec starter symbols. In addition, a '['
could also start a type-spec (we don't want a third 'array' keyword).
So, in the new scheme, either of these symbols can start a new typespec:
ref
[
A type starting with T (built-in or user-defined type) is a regular
type-spec.
'func', is normally used inside the the type for function pointer: 'ref
func'. At the start, I suppose it could be used to declare regular
non-pointer functions.
Examples:
ref int p, q, r; // int *p, *q, *r;
[N]int a, b, c; // int a[N], b[N], c[N];
ref []int p; // int (*p)[]; I think
[N]ref int q; // int *q[N];
ref func(int, int)float F // float (*F)(int,int);
ref ref[M][N]double x // pointer to pointer to array ...
If you wanted to make it CDECL-clear, then make these tweaks:
- use 'pointer to' as an alias to 'ref'
- Require 'array' before [ in my examples
- Require 'returning' after ')'
(In this scheme, parentheses only occur around parameter lists.)
Old and new can be mixed, but they need to be distinct sequences:
ref func(int*, ref int)float F
int* G(ref func()void);
So, anywhere where a type could start in the current syntax, that can be
old or new.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-10-27 10:44 +0100 |
| Message-ID | <10dneta$m9ru$1@dont-email.me> |
| In reply to | #394739 |
On 26/10/2025 16:12, bart wrote: > On 25/10/2025 16:18, David Brown wrote: >> On 25/10/2025 14:51, bart wrote: >> >>> This is another matter. The CDECL docs talk about C and C++ type >>> declarations being 'gibberish'. >>> >>> What do you feel about that, and the *need* for such a substantial >>> tool to help understand or write such declarations? >>> >>> I would rather have put some effort into fixing the syntax so that >>> such tools are not necessary! > >> And I'd love to hear your plan for "fixing" the syntax of C - noting >> that changing the syntax of C means getting the C standards committee >> to accept your suggestions, getting at least all major C compilers to >> support them, and getting the millions of C programmers to use them. > > I have posted such proposals in the past (probably before 2010). > No, you have not. What you have proposed is a different way to write types in declarations, in a different language. That's fine if you are making a different language. (For the record, I like some of your suggestions, and dislike others - my own choice for an "ideal" syntax would be different from both your syntax and C's.) I asked you if you had a plan for /fixing/ the syntax of /C/. You don't. As an analogy, suppose I invited you - as an architect and builder - to see my house, and you said you didn't like the layout of the rooms, the kitchen was too small, and you thought the cellar was pointless complexity. I ask you if you can give me a plan to fix it, and you respond by telling me your own house is nicer.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-27 11:22 +0000 |
| Message-ID | <10dnkkr$o51e$1@dont-email.me> |
| In reply to | #394779 |
On 27/10/2025 09:44, David Brown wrote:
> On 26/10/2025 16:12, bart wrote:
>> On 25/10/2025 16:18, David Brown wrote:
>>> On 25/10/2025 14:51, bart wrote:
>>>
>>>> This is another matter. The CDECL docs talk about C and C++ type
>>>> declarations being 'gibberish'.
>>>>
>>>> What do you feel about that, and the *need* for such a substantial
>>>> tool to help understand or write such declarations?
>>>>
>>>> I would rather have put some effort into fixing the syntax so that
>>>> such tools are not necessary!
>>
>>> And I'd love to hear your plan for "fixing" the syntax of C - noting
>>> that changing the syntax of C means getting the C standards committee
>>> to accept your suggestions, getting at least all major C compilers to
>>> support them, and getting the millions of C programmers to use them.
>>
>> I have posted such proposals in the past (probably before 2010).
>>
>
> No, you have not.
>
> What you have proposed is a different way to write types in
> declarations, in a different language. That's fine if you are making a
> different language. (For the record, I like some of your suggestions,
> and dislike others - my own choice for an "ideal" syntax would be
> different from both your syntax and C's.)
>
> I asked you if you had a plan for /fixing/ the syntax of /C/. You don't.
>
> As an analogy, suppose I invited you - as an architect and builder - to
> see my house, and you said you didn't like the layout of the rooms, the
> kitchen was too small, and you thought the cellar was pointless
> complexity. I ask you if you can give me a plan to fix it, and you
> respond by telling me your own house is nicer.
Where did I say anything about my own house?
I added a scheme for LTR type declarations such as you find in many
other languages (where do you think I copied mine from?).
I had to use 'ref' instead of '*' to avoid grammar ambiguities since in
C, '*' can also start an expression.
Your analogy is poor, but I would set up additional kitchen facilities
in another room, or in an extension. (My brother did exactly this.)
If my scheme was actually added and become popular, the old one could
eventually be deprecated.
And yes it does 'fix' it by not requiring the use of tools like CDECL
when writing new code: type-specs are already in LTR, more English-like
form.
CDECL might still be needed for decoding gibberish in legacy code, or
where you have to maintain such code in the same style.
> - my own choice for an "ideal" syntax would be
> different from both your syntax and C's.)
>
It sounds like it would also be different from CDECL. Perhaps you should
contact the author to tell him what he's doing wrong!
BTW on an old compiler for my language, I had a bit of fun by
implementation those ideas I mentioned for making syntax CDECL-like. So
this was legal code:
pointer to function(int, int) returning real fnptr
What's missing is having the variable name on the left (I added that as
an experiment - allowing it on left OR right - in a different version!)
However it is too long-winded and verbose; it adds too much clutter and
is too much typing. When displaying diags, the compiler represents that
type like this:
ref proc(i64 $1,i64 $2)r64
which is close to the normal syntax.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-10-27 17:35 +0100 |
| Message-ID | <10do704$1094n$1@dont-email.me> |
| In reply to | #394781 |
On 27/10/2025 12:22, bart wrote: > On 27/10/2025 09:44, David Brown wrote: >> On 26/10/2025 16:12, bart wrote: >>> On 25/10/2025 16:18, David Brown wrote: >>>> On 25/10/2025 14:51, bart wrote: >>>> >>>>> This is another matter. The CDECL docs talk about C and C++ type >>>>> declarations being 'gibberish'. >>>>> >>>>> What do you feel about that, and the *need* for such a substantial >>>>> tool to help understand or write such declarations? >>>>> >>>>> I would rather have put some effort into fixing the syntax so that >>>>> such tools are not necessary! >>> >>>> And I'd love to hear your plan for "fixing" the syntax of C - noting >>>> that changing the syntax of C means getting the C standards >>>> committee to accept your suggestions, getting at least all major C >>>> compilers to support them, and getting the millions of C programmers >>>> to use them. >>> >>> I have posted such proposals in the past (probably before 2010). >>> >> >> No, you have not. >> >> What you have proposed is a different way to write types in >> declarations, in a different language. That's fine if you are making >> a different language. (For the record, I like some of your >> suggestions, and dislike others - my own choice for an "ideal" syntax >> would be different from both your syntax and C's.) >> >> I asked you if you had a plan for /fixing/ the syntax of /C/. You don't. >> >> As an analogy, suppose I invited you - as an architect and builder - >> to see my house, and you said you didn't like the layout of the rooms, >> the kitchen was too small, and you thought the cellar was pointless >> complexity. I ask you if you can give me a plan to fix it, and you >> respond by telling me your own house is nicer. > > Where did I say anything about my own house? > In the analogy, that would your own language, and/or your own declaration syntax that has nothing to do with C - both of which you have harped on about repeatedly. Sorry, I thought that was obvious. > If my scheme was actually added and become popular, the old one could > eventually be deprecated. Is that your "plan" ? > > And yes it does 'fix' it by not requiring the use of tools like CDECL > when writing new code: type-specs are already in LTR, more English-like > form. Most C programmers don't need cdecl. The only people that do need it, either have very little knowledge and experience of C, or are faced with code written by sadists (unfortunately that is not as rare as it should be). Some others might occasionally find such a tool /useful/, but finding it useful is not "needing". And with your bizarre syntax as an alternative, just the same would apply. So you have set up a straw man, claimed to "fix" this imaginary problem, while actually doing nothing of the sort. And even if your syntax was as great as you think (IMHO it is nicer in some ways, worse in others - and I think most C programmers would agree on that while not being able to agree on which parts are nicer or worse), you still haven't shown the slightest concept of your claimed "plan" to implement it. > > - my own choice for an "ideal" syntax would be > > different from both your syntax and C's.) > > > > It sounds like it would also be different from CDECL. Perhaps you should > contact the author to tell him what he's doing wrong! Yes, my ideal would be different from the output of cdecl. No, the author is not doing something "wrong". I live in a world where programming languages are used by more than one person, and those people can have different opinions. I can have opinions on what syntax /I/ like, and equally accept that other people have different opinions. You like your choice of syntax - that's fine. I like some of it, and dislike other bits, but I certainly can't say /your/ preferences are "wrong" !
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-27 17:44 +0000 |
| Message-ID | <10dob21$12kn9$1@dont-email.me> |
| In reply to | #394799 |
On 27/10/2025 16:35, David Brown wrote:
> On 27/10/2025 12:22, bart wrote:
>> Where did I say anything about my own house?
>>
>
> In the analogy, that would your own language, and/or your own
> declaration syntax that has nothing to do with C
It is C syntax flattened to LTR form, with modifiers all moved to the
basetype, and shared by all variables declared. Function return types go
after the parameter list.
However, this will clash with existing C syntax and created ambiguities.
So I suggested using, for example, the same keyword for a leading "*"
/as is used in Algol68/; not my language, even if I borrowed it myself
from there.
>> If my scheme was actually added and become popular, the old one could
>> eventually be deprecated.
>
> Is that your "plan" ?
I don't have a plan. It was an idea for allowing a modern, saner syntax
on top of C.
>> And yes it does 'fix' it by not requiring the use of tools like CDECL
>> when writing new code: type-specs are already in LTR, more English-
>> like form.
>
> Most C programmers don't need cdecl. The only people that do need it,
> either have very little knowledge and experience of C, or are faced with
> code written by sadists (unfortunately that is not as rare as it should
> be). Some others might occasionally find such a tool /useful/, but
> finding it useful is not "needing". And with your bizarre syntax
/My syntax/ (as in my proposal) is bizarre, but actual C type syntax isn't?!
The latter is possibly the worst-designed feature of any programming
language ever, certainly of any mainstream language. This is the syntax
for a pointer to an unbounded array of function pointers that return a
pointer to int:
int *(*(*)[])()
This, is not bizarre?! Even somebody reading has to figure out which *
corresponds to which 'pointer to', and where the name might go if using
it to declare a variable.
In the LTR syntax I suggested, it would be:
ref[]ref func()ref int
The variable name goes on the right. For declaring three such variables,
it would be:
ref[]ref func()ref int a, b, c
Meanwhile, in C as it is, it would need to be something like this:
int *(*(*a)[])(), *(*(*b)[])(), *(*(*c)[])()
Or you have to use a workaround and create a named alias for the type
(what would you call it?):
typedef int *(*(*T)[])();
T a, b, c;
It's a fucking joke. And yes, I needed to use a tool to get that first
'int *(*(*)[])()', otherwise I can spend forever in a trial and error
process of figuring where all those brackets and asterisks go.
THIS IS WHY such tools are necessary, because the language syntax as it
is is not fit for purpose.
> So you have set up a straw man, claimed to "fix" this imaginary problem,
> while actually doing nothing of the sort.
So what imaginary problem does CDECL fix? There's a reason it uses the
word 'gibberish'. (I'm not even going into stuff like 'long const long
unsigned'.)
> And even if your syntax was as great as you think (IMHO it is nicer in
> some ways, worse in others
In which ways?
> - and I think most C programmers would agree
> on that while not being able to agree on which parts are nicer or
> worse), you still haven't shown the slightest concept of your claimed
> "plan" to implement it.
What needs to be implemented? It would take some hours to add to my C
compiler. Maybe it needs tweaks to fix things I hadn't forseen. But I
can't see there is much problem.
Getting anyone else (who are going to have the same attitudes as yours)
to agree to it, and starting a process to add it to the language, is the
big obstacle.
But technically there is little to it.
> Yes, my ideal would be different from the output of cdecl. No, the
> author is not doing something "wrong". I live in a world where
> programming languages are used by more than one person, and those people
> can have different opinions.
Find me one person who doesn't think that syntax like int *(*(*)[])()
is a complete joke.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-10-28 04:10 +0100 |
| Message-ID | <10dpc76$1h4oo$1@dont-email.me> |
| In reply to | #394806 |
On 27.10.2025 18:44, bart wrote: > On 27/10/2025 16:35, David Brown wrote: >> On 27/10/2025 12:22, bart wrote: > > > /My syntax/ (as in my proposal) is bizarre, What was your proposal? - Anyway, it shouldn't be "bizarre"; it's under your design-control! > but actual C type syntax isn't?! There were reasons for that choice. And the authors have explained them. - This doesn't make their choice any better, though, IMO. > > The latter is possibly the worst-designed feature of any programming > language ever, certainly of any mainstream language. This is the syntax > for a pointer to an unbounded array of function pointers that return a > pointer to int: > > int *(*(*)[])() > > This, is not bizarre?! You need to know the concept behind it. IOW, learn the language and you will get used to it. (As with other features or "monstrosities".) > Even somebody reading has to figure out which * > corresponds to which 'pointer to', and where the name might go if using > it to declare a variable. > > In the LTR syntax I suggested, it would be: > > ref[]ref func()ref int > > The variable name goes on the right. For declaring three such variables, > it would be: > > ref[]ref func()ref int a, b, c > > Meanwhile, in C as it is, it would need to be something like this: > > int *(*(*a)[])(), *(*(*b)[])(), *(*(*c)[])() > > Or you have to use a workaround and create a named alias for the type > (what would you call it?): > > typedef int *(*(*T)[])(); > > T a, b, c; > > It's a fucking joke. Actually, this is a way to (somewhat) control the declaration "mess" so that it doesn't propagate into the rest of the source code and muddy each occurrence. It's also a good design principle (also when programming in other language) to use names for [complex] types. I take that option 'typedef' as a sensible solution of this specific problem with C's underlying declaration decisions. > And yes, I needed to use a tool to get that first > 'int *(*(*)[])()', otherwise I can spend forever in a trial and error > process of figuring where all those brackets and asterisks go. > > THIS IS WHY such tools are necessary, because the language syntax as it > is is not fit for purpose. I never used 'cdecl' (as far as I recall). (I recall I was thinking sometimes that such a tool could be useful.) Myself it was sufficient to use a 'typedef' for complex cases. Constructing such expressions is often easier than reading them. > [...] > >> Yes, my ideal would be different from the output of cdecl. No, the >> author is not doing something "wrong". I live in a world where >> programming languages are used by more than one person, and those >> people can have different opinions. > > Find me one person who doesn't think that syntax like int *(*(*)[])() > is a complete joke. Maybe the authors (and all the enthusiastic adherents) of "C"? Janis
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-10-27 23:47 -0700 |
| Message-ID | <10dpoun$1n1q8$2@dont-email.me> |
| In reply to | #394855 |
On 10/27/2025 8:10 PM, Janis Papanagnou wrote: > On 27.10.2025 18:44, bart wrote: >> On 27/10/2025 16:35, David Brown wrote: >>> On 27/10/2025 12:22, bart wrote: >> >> >> /My syntax/ (as in my proposal) is bizarre, > > What was your proposal? - Anyway, it shouldn't be "bizarre"; it's > under your design-control! > >> but actual C type syntax isn't?! > > There were reasons for that choice. And the authors have explained > them. - This doesn't make their choice any better, though, IMO. > >> >> The latter is possibly the worst-designed feature of any programming >> language ever, certainly of any mainstream language. This is the syntax >> for a pointer to an unbounded array of function pointers that return a >> pointer to int: >> >> int *(*(*)[])() >> >> This, is not bizarre?! > > You need to know the concept behind it. IOW, learn the language and > you will get used to it. (As with other features or "monstrosities".) > >> Even somebody reading has to figure out which * >> corresponds to which 'pointer to', and where the name might go if using >> it to declare a variable. >> >> In the LTR syntax I suggested, it would be: >> >> ref[]ref func()ref int >> >> The variable name goes on the right. For declaring three such variables, >> it would be: >> >> ref[]ref func()ref int a, b, c >> >> Meanwhile, in C as it is, it would need to be something like this: >> >> int *(*(*a)[])(), *(*(*b)[])(), *(*(*c)[])() >> >> Or you have to use a workaround and create a named alias for the type >> (what would you call it?): >> >> typedef int *(*(*T)[])(); >> >> T a, b, c; >> >> It's a fucking joke. > > Actually, this is a way to (somewhat) control the declaration "mess" > so that it doesn't propagate into the rest of the source code and > muddy each occurrence. It's also a good design principle (also when > programming in other language) to use names for [complex] types. > > I take that option 'typedef' as a sensible solution of this specific > problem with C's underlying declaration decisions. > >> And yes, I needed to use a tool to get that first >> 'int *(*(*)[])()', otherwise I can spend forever in a trial and error >> process of figuring where all those brackets and asterisks go. >> >> THIS IS WHY such tools are necessary, because the language syntax as it >> is is not fit for purpose. > > I never used 'cdecl' (as far as I recall). (I recall I was thinking > sometimes that such a tool could be useful.) Myself it was sufficient > to use a 'typedef' for complex cases. Constructing such expressions > is often easier than reading them. > >> [...] >> >>> Yes, my ideal would be different from the output of cdecl. No, the >>> author is not doing something "wrong". I live in a world where >>> programming languages are used by more than one person, and those >>> people can have different opinions. >> >> Find me one person who doesn't think that syntax like int *(*(*)[])() >> is a complete joke. > > Maybe the authors (and all the enthusiastic adherents) of "C"? Does extern "C" tend to use cdecl?
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-10-27 22:33 +0000 |
| Message-ID | <10dorv8$34ktl$1@paganini.bofh.team> |
| In reply to | #394779 |
David Brown <david.brown@hesbynett.no> wrote:
> On 26/10/2025 16:12, bart wrote:
>> On 25/10/2025 16:18, David Brown wrote:
>>> On 25/10/2025 14:51, bart wrote:
>>>
>>>> This is another matter. The CDECL docs talk about C and C++ type
>>>> declarations being 'gibberish'.
>>>>
>>>> What do you feel about that, and the *need* for such a substantial
>>>> tool to help understand or write such declarations?
>>>>
>>>> I would rather have put some effort into fixing the syntax so that
>>>> such tools are not necessary!
>>
>>> And I'd love to hear your plan for "fixing" the syntax of C - noting
>>> that changing the syntax of C means getting the C standards committee
>>> to accept your suggestions, getting at least all major C compilers to
>>> support them, and getting the millions of C programmers to use them.
>>
>> I have posted such proposals in the past (probably before 2010).
>>
>
> No, you have not.
>
> What you have proposed is a different way to write types in
> declarations, in a different language. That's fine if you are making a
> different language. (For the record, I like some of your suggestions,
> and dislike others - my own choice for an "ideal" syntax would be
> different from both your syntax and C's.)
>
> I asked you if you had a plan for /fixing/ the syntax of /C/. You don't.
>
> As an analogy, suppose I invited you - as an architect and builder - to
> see my house, and you said you didn't like the layout of the rooms, the
> kitchen was too small, and you thought the cellar was pointless
> complexity. I ask you if you can give me a plan to fix it, and you
> respond by telling me your own house is nicer.
Sorry, "proof by analogy" is usually wrong. If you insist on
analogies the right one would be function prototypes: old style
function declarations where inherently unsafe and it was fixed
by adding new syntax for function declarations and definitions,
in parallel to old syntax. Now old style declarations are
officially retired. Bart proposed new syntax for all
declarations to be used in parallel with old ones, that is
exaclty the same fix as used to solve unsafety of old
function declarations.
IMO the worst C problem is standard process. Basically, once
a large vendor manages to subvert the language it gets
legitimized and part of the standard. OTOH old warts are
preserved for long time. Worse, new warts are introduced.
As an example, VMT-s were big opportunity to make array access
safer. But version which is in the standard skilfully
sabotages potential compiler attempts to increase safety.
If you look carefuly, there is several places in the standard
that effectively forbid static or dynamic error checks. Once
you add extra safety checks your implementation is
noncompilant.
It is likely that any standarized language is eventually
doomed to failure. This is pretty visible with Cobol,
but C seem to be on similar trajectory (but in much earlier
stage).
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-10-28 04:23 +0100 |
| Message-ID | <10dpcvm$1hd2h$1@dont-email.me> |
| In reply to | #394825 |
On 27.10.2025 23:33, Waldek Hebisch wrote: > David Brown <david.brown@hesbynett.no> wrote: >> [...] > > Sorry, "proof by analogy" is usually wrong. If you insist on > analogies the right one would be function prototypes: old style > function declarations where inherently unsafe and it was fixed > by adding new syntax for function declarations and definitions, > in parallel to old syntax. Now old style declarations are > officially retired. Bart proposed new syntax for all > declarations to be used in parallel with old ones, that is > exaclty the same fix as used to solve unsafety of old > function declarations. As far as I recall, Dennis Ritchie has written about the practical problem with "C" compilers having to support two different versions [of the function declaration topic] for compatibility reasons. Early and central "misdesigns" are not easy to address; it hurts. (That's one difference between the often discredited "design by committee" and a more casual growing design from a single person or interest group.) Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-10-28 16:20 +0100 |
| Message-ID | <10dqn0g$23lj0$1@dont-email.me> |
| In reply to | #394825 |
On 27/10/2025 23:33, Waldek Hebisch wrote: > David Brown <david.brown@hesbynett.no> wrote: >> On 26/10/2025 16:12, bart wrote: >>> On 25/10/2025 16:18, David Brown wrote: >>>> On 25/10/2025 14:51, bart wrote: >>>> >>>>> This is another matter. The CDECL docs talk about C and C++ type >>>>> declarations being 'gibberish'. >>>>> >>>>> What do you feel about that, and the *need* for such a substantial >>>>> tool to help understand or write such declarations? >>>>> >>>>> I would rather have put some effort into fixing the syntax so that >>>>> such tools are not necessary! >>> >>>> And I'd love to hear your plan for "fixing" the syntax of C - noting >>>> that changing the syntax of C means getting the C standards committee >>>> to accept your suggestions, getting at least all major C compilers to >>>> support them, and getting the millions of C programmers to use them. >>> >>> I have posted such proposals in the past (probably before 2010). >>> >> >> No, you have not. >> >> What you have proposed is a different way to write types in >> declarations, in a different language. That's fine if you are making a >> different language. (For the record, I like some of your suggestions, >> and dislike others - my own choice for an "ideal" syntax would be >> different from both your syntax and C's.) >> >> I asked you if you had a plan for /fixing/ the syntax of /C/. You don't. >> >> As an analogy, suppose I invited you - as an architect and builder - to >> see my house, and you said you didn't like the layout of the rooms, the >> kitchen was too small, and you thought the cellar was pointless >> complexity. I ask you if you can give me a plan to fix it, and you >> respond by telling me your own house is nicer. > > Sorry, "proof by analogy" is usually wrong. I agree - I wasn't trying to "prove" anything. Analogies can be illustrative. Bart had claimed to have a "plan to fix C", without understanding what that could mean, and I was trying to find a way to show him how absurd that was. (That is, his claim to have a plan to fix C was absurd, not necessarily his alternative syntaxes for declarations.) > If you insist on > analogies the right one would be function prototypes: old style > function declarations where inherently unsafe and it was fixed > by adding new syntax for function declarations and definitions, > in parallel to old syntax. Now old style declarations are > officially retired. Bart proposed new syntax for all > declarations to be used in parallel with old ones, that is > exaclty the same fix as used to solve unsafety of old > function declarations. > The function prototype syntax was an enhancement to the existing syntax, and could be used happily in parallel with it. And it was developed within the community of the C language developers and implementers (it was before ANSI/ISO standardisation). Bart's suggestion turns existing C syntax upside down, is incompatible with everything - in particular, incompatible with the philosophy and intention behind C's syntax - and is the product of one person whose motivation seems to be hating C and whining about it. So it is a very different situation. > IMO the worst C problem is standard process. Basically, once > a large vendor manages to subvert the language it gets > legitimized and part of the standard. OTOH old warts are > preserved for long time. Worse, new warts are introduced. > Backwards compatibility is simultaneously the best part of C, and the worst part of C. > As an example, VMT-s were big opportunity to make array access > safer. But version which is in the standard skilfully > sabotages potential compiler attempts to increase safety. > > If you look carefuly, there is several places in the standard > that effectively forbid static or dynamic error checks. Once > you add extra safety checks your implementation is > noncompilant. > I certainly have no problem finding countless things in C that I would have preferred to be done differently. I don't know any serious C programmer who could not do the same - but they would all come up with different points (with plenty of overlap). > It is likely that any standarized language is eventually > doomed to failure. This is pretty visible with Cobol, > but C seem to be on similar trajectory (but in much earlier > stage). > It takes a /very/ broad definition of "failure" to encompass C! But I think Stroustrup was spot-on with his comment "There are two kinds of programming languages - the ones everyone complains about, and the ones nobody uses".
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-10-27 13:48 -0700 |
| Message-ID | <87cy68136w.fsf@example.invalid> |
| In reply to | #394739 |
bart <bc@freeuk.com> writes:
> On 25/10/2025 16:18, David Brown wrote:
[...]
>> And I'd love to hear your plan for "fixing" the syntax of C - noting
>> that changing the syntax of C means getting the C standards
>> committee to accept your suggestions, getting at least all major C
>> compilers to support them, and getting the millions of C programmers
>> to use them.
>
> I have posted such proposals in the past (probably before 2010).
>
> I can't remember the exact details, but I think it is possible to
> superimpose LTR type syntax on top of the existing language.
[...]
If I understand correctly (you haven't been entirely clear about it),
your proposal is to create a new friendlier declaration syntax for C,
and have a new version of C support both the existing syntax and your
new syntax. So in your hypothetical future C, one might have:
int *const *p1;
p1: pointer to const pointer to int;
in the same program.
I haven't seen a *concrete* proposal. If I thought the whole thing
were a good idea, I'd encourage you to write one.
In my personal opinion, C's declaration syntax, cleverly based
on a somewhat loose "declaration follows use" principle, is a not
entirely successful experiment that has caught on extraordinarily
well, probably due to C's other advantages as a systems programming
language. I would have preferred a different syntax **if** it had
been used in the original C **instead of** the current syntax.
I do not think C's syntax is any kind of "joke", as you do.
It's entirely consistent and well defined.
All else being equal, I would prefer a C-like language with clear
left-to-right declaration syntax to C as it's currently defined.
But all else is not at all equal.
And I think that a future C that supports *both* the existing
syntax and your new syntax would be far worse than C as it is now.
Programmers would have to learn both. Existing code would not
be updated. Most new code, written by experienced C programmers,
would continue to use the old syntax. Your plan to deprecate the
existing syntax would fail.
And that's why it will never happen. The ISO C committee would never
consider this kind of radical change, even if it were shoehorned
into the syntax in a way that somehow doesn't break existing code.
You have spent years complaining here about C's syntax (to people
who are not in a position to do anything about it). If you had
spent half that time learning how it works, you'd be a world-class
expert by now, and you could teach others how to use it rather than
deliberately confusing them with contrived examples.
You can of course create your own language with a cleaner syntax.
Apparently you've done so, but not in a way that's useful to most
of us -- not that you're obligated to make it useful to anyone else.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-10-28 04:41 +0100 |
| Message-ID | <10dpe0s$1i2kb$1@dont-email.me> |
| In reply to | #394821 |
On 27.10.2025 21:48, Keith Thompson wrote: > bart <bc@freeuk.com> writes: >> [...] > [...] > > In my personal opinion, C's declaration syntax, cleverly based > on a somewhat loose "declaration follows use" principle, IMO that was the idea, and I would object to the word "cleverly". When I spoke with students, newbie "C" users, about that they were quite confused, not only by the "same" placement as in expressions but also by using the same symbol for conceptually different things. Personally I always found it better comprehensible where languages use something like, say, REF sometype x; and y = DEREF x in the first place. If you explain things that way people much easier understand it, as far as my experience goes. > is a not > entirely successful experiment that has caught on extraordinarily > well, probably due to C's other advantages as a systems programming > language. I would have preferred a different syntax **if** it had > been used in the original C **instead of** the current syntax. [...] > All else being equal, I would prefer a C-like language with clear > left-to-right declaration syntax to C as it's currently defined. > But all else is not at all equal. Indeed. > > And I think that a future C that supports *both* the existing > syntax and your new syntax would be far worse than C as it is now. > Programmers would have to learn both. Existing code would not > be updated. Most new code, written by experienced C programmers, > would continue to use the old syntax. Your plan to deprecate the > existing syntax would fail. Yes. > And that's why it will never happen. The ISO C committee would never > consider this kind of radical change, even if it were shoehorned > into the syntax in a way that somehow doesn't break existing code. But interestingly, as far as I recall, the C committee did exactly that with the function declaration syntax option (back then when going from K&R to a standard). Sure, they might handle that now differently since it's their standard to change (and not the K&R origin [or quasi standard]). Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-10-25 11:40 -0400 |
| Message-ID | <10dir1d$2a745$1@dont-email.me> |
| In reply to | #394724 |
On 25/10/2025 14:51, bart wrote: > This is another matter. The CDECL docs talk about C and C++ type > declarations being 'gibberish'. > > What do you feel about that, and the *need* for such a substantial tool > to help understand or write such declarations? > > I would rather have put some effort into fixing the syntax so that such > tools are not necessary! They aren't. I've never needed them and have only rarely used them - and never found the results worth the trouble. For me, converting a C type into cdecl format has a feeling similar to what I feel when a C expression statement is translated into COBOL - lots of unnecessary extra verbiage that gets in the way of my understanding, it doesn't aid it. C declaration syntax builds upon a simple principle: declaration reflects use. It then adds some unavoidable complications on that principle. There's multiple ways that any given identifier can be used, but there's one particular one that is the model for the declaration. A given way of using an identifier can be used by identifiers of several different types, but at most one of those types is the one that id declared using a declaration that mirrors that particular usage.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-25 16:48 +0100 |
| Message-ID | <10dirfi$3ek8r$1@dont-email.me> |
| In reply to | #394722 |
On 25/10/2025 12:04, David Brown wrote: > On 24/10/2025 20:50, bart wrote: >> I was talking about all the stuff scrolling endlessly up to the screen >> for a minute and a half while running the configure script and then >> compiling the modules. >> > > You are getting worked up about some text output that scrolled > "endlessly" for a minute and a half? (Do you spot the exaggeration > here?) Of course it is less of an issue for me - "./configure" took a > mere 10 seconds on my ten year old machine. But even at a minute and a > half, it's just a task that the computer runs, once, and it is done > without effort. Try relaxing a little more, and perhaps use that minute > and a half to stretch your legs or drink some coffee, rather than to > build up a pointless fury. The point about the minute and a half is that a fast compiler even on my machine could translate tens of millions of lines of source code in that time. If the app was actually that size (say, a web browser) then fine. But the C source is only 0.07Mloc. So what TF is going on? It appears that this is one of those apps that is superfically written in 'C' but it actually relies on a plethora of other languages, files, tools and myriad kinds of options. You can't just go into ./src and do 'gcc *.c'. Even the makefile has to first be generated. There are files with .in, .am and .m4 extensions. The eventual 'makefile' has 2000 lines of gobbledygook, to build 49 C modules. (My projects are also around 40 modules; the build info comprises, funnily enough, some 40 lines.) So this is a complicated build process! Unfortunately it is typical of such products originating from Unix-Linux (you really want one term that you can use for both). This is not specific to CDECL; it's nearly everything that comes of Unix-Linux. But this came up and I had a look. But let me ask then about this particularly app (an interactive text-based program where performance is irrelevant; it could have been written in Python): do you think it would have been possible to distribute this as a set of 100% *standard* C source files, with the only dependency being *any* C compiler?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-10-25 19:14 +0200 |
| Message-ID | <10dj0i5$3fkgn$1@dont-email.me> |
| In reply to | #394727 |
On 25/10/2025 17:48, bart wrote: > On 25/10/2025 12:04, David Brown wrote: >> On 24/10/2025 20:50, bart wrote: > >>> I was talking about all the stuff scrolling endlessly up to the >>> screen for a minute and a half while running the configure script and >>> then compiling the modules. >>> >> >> You are getting worked up about some text output that scrolled >> "endlessly" for a minute and a half? (Do you spot the exaggeration >> here?) Of course it is less of an issue for me - "./configure" took a >> mere 10 seconds on my ten year old machine. But even at a minute and >> a half, it's just a task that the computer runs, once, and it is done >> without effort. Try relaxing a little more, and perhaps use that >> minute and a half to stretch your legs or drink some coffee, rather >> than to build up a pointless fury. > > The point about the minute and a half is that a fast compiler even on my > machine could translate tens of millions of lines of source code in that > time. If the app was actually that size (say, a web browser) then fine. > > But the C source is only 0.07Mloc. So what TF is going on? > > It appears that this is one of those apps that is superfically written > in 'C' but it actually relies on a plethora of other languages, files, > tools and myriad kinds of options. You can't just go into ./src and do > 'gcc *.c'. > It uses yacc and lex for generating the parsing code. Fair enough - that's what those tools are for. > Even the makefile has to first be generated. There are files > with .in, .am and .m4 extensions. The eventual 'makefile' has 2000 lines > of gobbledygook, to build 49 C modules. (My projects are also around 40 > modules; the build info comprises, funnily enough, some 40 lines.) > > So this is a complicated build process! Unfortunately it is typical of > such products originating from Unix-Linux (you really want one term that > you can use for both). Lots of people use *nix, or POSIX, or unix-like as single terms. Most software that is for "big" systems (rather than small embedded ones), and is not Windows or Mac only, is *nix and works on various Unix systems, Solaris, AIX, BSD, Linux, and a wide variety of related systems - including *nix layers on Windows (msys2, cygwin, WSL, etc.). On of the reasons why such a lot of software is so widely portable is the widespread use of autotools - with the common "./configure && make -j && make install" combination for building the software. The "configure" part handles the details and differences between the systems so that the software is portable. Now, everyone who has ever used this can see potential for improvement. There are large numbers of checks that autotools does that are always "yes" on most systems from the last decade. But there are also people who want to use software on their ancient Sun workstations, or their big-endian MIPS machines. And there are lots of people who want to compile software on their machines but haven't installed various libraries that are essential or potentially useful - configure will see that and tell them about it. So the autotools systems is very useful, and helps keep things highly portable - but there is certainly a potential for improvement with caching the results of the tests. Maybe someday someone will feel bothered enough by the 10 second configure that they will make such improvements. Yes, the whole thing is complicated. But the complications are hidden, so for the people using autotools builds, and who have some basic familiarity with them, the process is simple and almost all automatic. We can all be curious about what is going on behind the scenes, but you can also just do the build and use the program without bothering about these details. Life is too short to try to understand /everything/. > > This is not specific to CDECL; it's nearly everything that comes of > Unix-Linux. But this came up and I had a look. > > But let me ask then about this particularly app (an interactive text- > based program where performance is irrelevant; it could have been > written in Python): do you think it would have been possible to > distribute this as a set of 100% *standard* C source files, with the > only dependency being *any* C compiler? > Would it have been possible? Yes, of course. Would it have been the real source here? No - the author used source generator tools like yacc and lex to generate C code. Would it have made the build process easier or faster for normal users of the source code? No - the typical person who is interested in such software and is keen enough on getting the very latest version, can build it in a couple of minutes at most. Would it help people who just want a binary for normal usage? No, most would just get cdecl from their package manager. Generally speaking, if you want binaries for such a program for Windows, you can google for it - if an open source program is useful, someone will have made a windows build. Unfortunately in this case, googling for "windows cdecl binary" is going to give you results for the "cdecl" calling convention for MSVC, swamping any useful results. Still, googling for "msys2 cdecl" does fine. I can appreciate that the way this program is written, and the way the build process works, is awkward for /you/. But I think you are a very unique person, and the program and its build system are absolutely fine for the vast majority of people who would want to get the source from the github page.
[toc] | [prev] | [next] | [standalone]
Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web