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 1 of 10 [1] 2 3 … 10 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-10-22 14:39 -0700 |
| Subject | New and improved version of cdecl |
| Message-ID | <87bjlyobts.fsf@example.invalid> |
This is cross-posted to comp.lang.c and comp.lang.c++.
Consider redirecting followups as appropriate.
cdecl, along with c++decl, is a tool that translates C or C++
declaration syntax into English, and vice versa. For example :
$ cdecl
Type `help' or `?' for help
cdecl> explain const char *foo[42]
declare foo as array 42 of pointer to const char
cdecl> declare bar as pointer to function (void) returning int
int (*bar)(void )
It's also available via the web site <https://cdecl.org/>.
The original version of cdecl was posted on comp.sources.unix, probably
in the 1980s.
"ridiculous_fish" added support for Apple's blocks syntax. That
version, 2.5, is the one that's most widely available (it's provided by
the "cdecl" package on Debian and Ubuntu) and used by the cdecl.org
website.
There's a newer fork of cdecl, available in source code at
https://github.com/paul-j-lucas/cdecl/
It supports newer versions of C and C++ and adds a number of
new features. See the README.md file, visible at the above URL,
for more information. (It doesn't support Apple's block syntax.)
There doesn't seem to be a binary distribution, but the latest
source tarball is at
https://github.com/paul-j-lucas/cdecl/releases/download/cdecl-18.5/cdecl-18.5.tar.gz
It can be built on Unix-like systems with the usual "./configure;
make; make install" sequence. To build from a copy of the git repo,
run "./bootstrap" first to generate the "configure" script.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2025-10-22 22:19 -0300 |
| Message-ID | <10dbvqs$12d0f$1@dont-email.me> |
| In reply to | #394664 |
Em 22/10/2025 18:39, Keith Thompson escreveu: > This is cross-posted to comp.lang.c and comp.lang.c++. > Consider redirecting followups as appropriate. > > cdecl, along with c++decl, is a tool that translates C or C++ > declaration syntax into English, and vice versa. For example : > > $ cdecl > Type `help' or `?' for help > cdecl> explain const char *foo[42] > declare foo as array 42 of pointer to const char > cdecl> declare bar as pointer to function (void) returning int > int (*bar)(void ) > > It's also available via the web site <https://cdecl.org/>. This one does not work: void (*f(int i))(void)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2025-10-23 02:42 +0100 |
| Message-ID | <87bjlypf58.fsf@bsb.me.uk> |
| In reply to | #394667 |
Thiago Adams <thiago.adams@gmail.com> writes: > Em 22/10/2025 18:39, Keith Thompson escreveu: >> This is cross-posted to comp.lang.c and comp.lang.c++. >> Consider redirecting followups as appropriate. >> cdecl, along with c++decl, is a tool that translates C or C++ >> declaration syntax into English, and vice versa. For example : >> $ cdecl >> Type `help' or `?' for help >> cdecl> explain const char *foo[42] >> declare foo as array 42 of pointer to const char >> cdecl> declare bar as pointer to function (void) returning int >> int (*bar)(void ) >> It's also available via the web site <https://cdecl.org/>. > > This one does not work: > > void (*f(int i))(void) Right. But the new version Keith was posting about does work with that declaration. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-10-23 03:04 +0000 |
| Message-ID | <20251022194951.914@kylheku.com> |
| In reply to | #394668 |
On 2025-10-23, Ben Bacarisse <ben@bsb.me.uk> wrote: > Thiago Adams <thiago.adams@gmail.com> writes: > >> Em 22/10/2025 18:39, Keith Thompson escreveu: >>> This is cross-posted to comp.lang.c and comp.lang.c++. >>> Consider redirecting followups as appropriate. >>> cdecl, along with c++decl, is a tool that translates C or C++ >>> declaration syntax into English, and vice versa. For example : >>> $ cdecl >>> Type `help' or `?' for help >>> cdecl> explain const char *foo[42] >>> declare foo as array 42 of pointer to const char >>> cdecl> declare bar as pointer to function (void) returning int >>> int (*bar)(void ) >>> It's also available via the web site <https://cdecl.org/>. >> >> This one does not work: >> >> void (*f(int i))(void) > > Right. But the new version Keith was posting about does work with that > declaration. A cdecl in Unbuntu, accompanied by a 1996 dated man page, handles this: cdecl> explain void (*signal(int, void (*)(int)))(int); declare signal as function (int, pointer to function (int) returning void) returning pointer to function (int) returning void But chokes if we add parameter names to the function being declared: cdecl> explain void (*signal(int sig, void (*)(int)))(int); syntax error cdecl> explain void (*signal(int, void (*handler)(int)))(int); syntax error Or to the function pointer being passed in: cdecl> explain void (*signal(int, void (*)(int sig)))(int); syntax error Or to the one being returned: cdecl> explain void (*signal(int, void (*)(int)))(int sig); syntax error I'm astonished that every cdecl out there would not have cases covering this: function with a function pointer param, returning a function pointer param, with and without param names. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2025-10-23 15:05 +0100 |
| Message-ID | <875xc5pvce.fsf@bsb.me.uk> |
| In reply to | #394671 |
Kaz Kylheku <643-408-1753@kylheku.com> writes: > On 2025-10-23, Ben Bacarisse <ben@bsb.me.uk> wrote: >> Thiago Adams <thiago.adams@gmail.com> writes: >> >>> Em 22/10/2025 18:39, Keith Thompson escreveu: >>>> This is cross-posted to comp.lang.c and comp.lang.c++. >>>> Consider redirecting followups as appropriate. >>>> cdecl, along with c++decl, is a tool that translates C or C++ >>>> declaration syntax into English, and vice versa. For example : >>>> $ cdecl >>>> Type `help' or `?' for help >>>> cdecl> explain const char *foo[42] >>>> declare foo as array 42 of pointer to const char >>>> cdecl> declare bar as pointer to function (void) returning int >>>> int (*bar)(void ) >>>> It's also available via the web site <https://cdecl.org/>. >>> >>> This one does not work: >>> >>> void (*f(int i))(void) >> >> Right. But the new version Keith was posting about does work with that >> declaration. > > A cdecl in Unbuntu, accompanied by a 1996 dated man page, handles this: > > cdecl> explain void (*signal(int, void (*)(int)))(int); > declare signal as function (int, pointer to function (int) returning void) > returning pointer to function (int) returning void > > But chokes if we add parameter names to the function being declared: > > cdecl> explain void (*signal(int sig, void (*)(int)))(int); > syntax error > cdecl> explain void (*signal(int, void (*handler)(int)))(int); > syntax error Thanks. Yes, it seems it's having "int i" rather than "int" that causes the issue. > Or to the function pointer being passed in: > > cdecl> explain void (*signal(int, void (*)(int sig)))(int); > syntax error > > Or to the one being returned: > > cdecl> explain void (*signal(int, void (*)(int)))(int sig); > syntax error > > I'm astonished that every cdecl out there would not have cases > covering this: function with a function pointer param, returning > a function pointer param, with and without param names. Indeed. Although declarations might often omit the parameter names, if you copy and paste from a function definition the names with be there! -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-23 11:36 +0100 |
| Message-ID | <10dd0fj$1jbcv$1@dont-email.me> |
| In reply to | #394667 |
On 23/10/2025 02:19, Thiago Adams wrote: > Em 22/10/2025 18:39, Keith Thompson escreveu: >> This is cross-posted to comp.lang.c and comp.lang.c++. >> Consider redirecting followups as appropriate. >> >> cdecl, along with c++decl, is a tool that translates C or C++ >> declaration syntax into English, and vice versa. For example : >> >> $ cdecl >> Type `help' or `?' for help >> cdecl> explain const char *foo[42] >> declare foo as array 42 of pointer to const char >> cdecl> declare bar as pointer to function (void) returning int >> int (*bar)(void ) >> >> It's also available via the web site <https://cdecl.org/>. > > This one does not work: > > void (*f(int i))(void) KT said the newer version is only available by building from source code, which must be done under some Linux-compatible system. I've had a look: it comprises 32Kloc of configure script, and 68Kloc of C sources, so 100Kloc just to decode declarations! (A bit longer than the 2-page version in K&R2.) (There's a further 30Kloc of what looks like C library code. So is this a complete C compiler, or does it still only do declarations?) Regarding your example, my old C compiler (which is a fraction the size of this new Cdecl) 'explains' it as: 'ref proc(int)ref proc()void' (Not quite English, more Algol68-ish.)
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2025-10-23 07:59 -0300 |
| Message-ID | <10dd1qh$3totj$1@dont-email.me> |
| In reply to | #394677 |
On 10/23/2025 7:36 AM, bart wrote: > On 23/10/2025 02:19, Thiago Adams wrote: >> Em 22/10/2025 18:39, Keith Thompson escreveu: >>> This is cross-posted to comp.lang.c and comp.lang.c++. >>> Consider redirecting followups as appropriate. >>> >>> cdecl, along with c++decl, is a tool that translates C or C++ >>> declaration syntax into English, and vice versa. For example : >>> >>> $ cdecl >>> Type `help' or `?' for help >>> cdecl> explain const char *foo[42] >>> declare foo as array 42 of pointer to const char >>> cdecl> declare bar as pointer to function (void) returning int >>> int (*bar)(void ) >>> >>> It's also available via the web site <https://cdecl.org/>. >> >> This one does not work: >> >> void (*f(int i))(void) > > KT said the newer version is only available by building from source > code, which must be done under some Linux-compatible system. > > I've had a look: it comprises 32Kloc of configure script, and 68Kloc of > C sources, so 100Kloc just to decode declarations! (A bit longer than > the 2-page version in K&R2.) > > (There's a further 30Kloc of what looks like C library code. So is this > a complete C compiler, or does it still only do declarations?) > > Regarding your example, my old C compiler (which is a fraction the size > of this new Cdecl) 'explains' it as: > > 'ref proc(int)ref proc()void' > > (Not quite English, more Algol68-ish.) > This algorithm can be done is ~300 lines.. it is present at the c programming language 2 edition.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-10-23 16:04 -0700 |
| Message-ID | <87jz0l2pal.fsf@example.invalid> |
| In reply to | #394677 |
bart <bc@freeuk.com> writes:
> On 23/10/2025 02:19, Thiago Adams wrote:
>> Em 22/10/2025 18:39, Keith Thompson escreveu:
>>> This is cross-posted to comp.lang.c and comp.lang.c++.
>>> Consider redirecting followups as appropriate.
>>>
>>> cdecl, along with c++decl, is a tool that translates C or C++
>>> declaration syntax into English, and vice versa. For example :
>>>
>>> $ cdecl
>>> Type `help' or `?' for help
>>> cdecl> explain const char *foo[42]
>>> declare foo as array 42 of pointer to const char
>>> cdecl> declare bar as pointer to function (void) returning int
>>> int (*bar)(void )
>>>
>>> It's also available via the web site <https://cdecl.org/>.
>> This one does not work:
>> void (*f(int i))(void)
>
> KT said the newer version is only available by building from source
> code, which must be done under some Linux-compatible system.
As far as I know, it should build on just about any Unix-like system,
not just ones that happen to use the Linux kernel. Perhaps that's what
you mean by "Linux-compatible"? If so, I suggest "Unix-like" would be
clearer. (I'm building it under Cygwin as I write this.)
> I've had a look: it comprises 32Kloc of configure script, and 68Kloc
> of C sources, so 100Kloc just to decode declarations! (A bit longer
> than the 2-page version in K&R2.)
Yes, and neither you nor I had to write any of it. I cloned the repo,
ran one command (my wrapper script for builds like this), and it works.
I wonder how many lines of code are required for the specification of
the x86_64 CPU in the computer I'm using to write this. But really,
it doesn't matter to me, since that work has been done, and all I
have to do is use it.
The configure script is automatically generated (I mentioned the
"bootstrap" script that generates it if you build from the git repo).
I suppose building it under Windows (without some Unix-like layer
like MinGW or Cygwin) would be more difficult. That's true of
a lot of tools that are primarily used on Unix-like systems.
It's likely that the author of the code doesn't care about Windows.
I agree that it can be a problem that a lot of code developed for
Unix-like systems is difficult to build on Windows. For a lot
of users, an emulation layer like Cygwin, MinGW, or WSL is a good
enough solution. If it isn't for you, perhaps you could help solve
the problem. Perhaps the GNU autotools could be updated with better
Windows support. I wouldn't know how to do that; perhaps you would.
"Don't use autotools" is not a good solution, since there are so
many software packages that depend on it, often maintained by people
who don't care about Windows.
> (There's a further 30Kloc of what looks like C library code. So is
> this a complete C compiler, or does it still only do declarations?)
I haven't looked at the source code (I haven't needed to), but the man
page indicates that this version of cdecl recognizes a number of types
defined in the standard library, such as FILE, clock_t, and
std::partial_ordering (remember that it includes C++ support).
I don't know whether all this could be done in fewer lines of code, and
frankly I don't much care. The tool works and is useful, and I didn't
have to write it.
Have you tried using it? I'm sure you have some system where you could
build it.
> Regarding your example, my old C compiler (which is a fraction the
> size of this new Cdecl) 'explains' it as:
>
> 'ref proc(int)ref proc()void'
>
> (Not quite English, more Algol68-ish.)
Can I run your old C compiler on my Ubuntu system?
--
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 | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-24 01:44 +0100 |
| Message-ID | <10dei5s$28h93$1@dont-email.me> |
| In reply to | #394692 |
On 24/10/2025 00:04, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:
>> On 23/10/2025 02:19, Thiago Adams wrote:
>>> Em 22/10/2025 18:39, Keith Thompson escreveu:
>>>> This is cross-posted to comp.lang.c and comp.lang.c++.
>>>> Consider redirecting followups as appropriate.
>>>>
>>>> cdecl, along with c++decl, is a tool that translates C or C++
>>>> declaration syntax into English, and vice versa. For example :
>>>>
>>>> $ cdecl
>>>> Type `help' or `?' for help
>>>> cdecl> explain const char *foo[42]
>>>> declare foo as array 42 of pointer to const char
>>>> cdecl> declare bar as pointer to function (void) returning int
>>>> int (*bar)(void )
>>>>
>>>> It's also available via the web site <https://cdecl.org/>.
>>> This one does not work:
>>> void (*f(int i))(void)
>>
>> KT said the newer version is only available by building from source
>> code, which must be done under some Linux-compatible system.
>
> As far as I know, it should build on just about any Unix-like system,
> not just ones that happen to use the Linux kernel. Perhaps that's what
> you mean by "Linux-compatible"? If so, I suggest "Unix-like" would be
> clearer. (I'm building it under Cygwin as I write this.)
>
>> I've had a look: it comprises 32Kloc of configure script, and 68Kloc
>> of C sources, so 100Kloc just to decode declarations! (A bit longer
>> than the 2-page version in K&R2.)
>
> Yes, and neither you nor I had to write any of it. I cloned the repo,
> ran one command (my wrapper script for builds like this), and it works.
>
> I wonder how many lines of code are required for the specification of
> the x86_64 CPU in the computer I'm using to write this. But really,
> it doesn't matter to me, since that work has been done, and all I
> have to do is use it.
>
> The configure script is automatically generated (I mentioned the
> "bootstrap" script that generates it if you build from the git repo).
>
> I suppose building it under Windows (without some Unix-like layer
> like MinGW or Cygwin) would be more difficult. That's true of
> a lot of tools that are primarily used on Unix-like systems.
> It's likely that the author of the code doesn't care about Windows.
>
> I agree that it can be a problem that a lot of code developed for
> Unix-like systems is difficult to build on Windows. For a lot
> of users, an emulation layer like Cygwin, MinGW, or WSL is a good
> enough solution. If it isn't for you, perhaps you could help solve
> the problem. Perhaps the GNU autotools could be updated with better
> Windows support. I wouldn't know how to do that; perhaps you would.
>
> "Don't use autotools" is not a good solution, since there are so
> many software packages that depend on it, often maintained by people
> who don't care about Windows.
>
>> (There's a further 30Kloc of what looks like C library code. So is
>> this a complete C compiler, or does it still only do declarations?)
>
> I haven't looked at the source code (I haven't needed to), but the man
> page indicates that this version of cdecl recognizes a number of types
> defined in the standard library, such as FILE, clock_t, and
> std::partial_ordering (remember that it includes C++ support).
>
> I don't know whether all this could be done in fewer lines of code, and
> frankly I don't much care. The tool works and is useful, and I didn't
> have to write it.
>
> Have you tried using it? I'm sure you have some system where you could
> build it.
>
>> Regarding your example, my old C compiler (which is a fraction the
>> size of this new Cdecl) 'explains' it as:
>>
>> 'ref proc(int)ref proc()void'
>>
>> (Not quite English, more Algol68-ish.)
>
> Can I run your old C compiler on my Ubuntu system?
>
The old one needed a tweak to bring it up-to-date for my newer C
transpiler. So it was easier to port the feature to the newer product.
Download https://github.com/sal55/langs/blob/master/ccu.c
(Note: 86Kloc/2MB file; this is poor quality, linear C generated from
intermediate language.)
Build instructions are at the top. Although this targets Win64, it works
enough to demonstrate the feature above. Create this C file (say test.c):
int main(void) {
void (*f(int i))(void);
$showmode f;
}
Run as follows (if built as 'ccu'):
./ccu -s test
It will display the type during compilation.
Obviously this is not a dedicated product (and doing the reverse needs a
separate program), but I only needed to add about 10 lines of code to
support '$showmode'.
Original source, omitting the unneeded output options, would be 2/3 the
size of that configure script.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-10-23 19:00 -0700 |
| Message-ID | <8734792h4y.fsf@example.invalid> |
| In reply to | #394697 |
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.
>>> Regarding your example, my old C compiler (which is a fraction the
>>> size of this new Cdecl) 'explains' it as:
>>>
>>> 'ref proc(int)ref proc()void'
>>>
>>> (Not quite English, more Algol68-ish.)
>> Can I run your old C compiler on my Ubuntu system?
>>
>
> The old one needed a tweak to bring it up-to-date for my newer C
> transpiler. So it was easier to port the feature to the newer product.
>
> Download https://github.com/sal55/langs/blob/master/ccu.c
>
> (Note: 86Kloc/2MB file; this is poor quality, linear C generated from
> intermediate language.)
>
> Build instructions are at the top. Although this targets Win64, it
> works enough to demonstrate the feature above. Create this C file (say
> test.c):
>
> int main(void) {
> void (*f(int i))(void);
> $showmode f;
> }
>
> Run as follows (if built as 'ccu'):
>
> ./ccu -s test
>
> It will display the type during compilation.
>
> Obviously this is not a dedicated product (and doing the reverse needs
> a separate program), but I only needed to add about 10 lines of code
> to support '$showmode'.
>
> Original source, omitting the unneeded output options, would be 2/3
> the size of that configure script.
OK, I was able to compile and run your ccu.c, and at least on this
example it works as you've described it. It looks interesting,
but I personally don't find it particularly useful, given that I
already have cdecl, I prefer its syntax, and it's easier to use
(and I almost literally could not care less about the number of
lines of code needed to implement cdecl).
--
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 | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-24 14:27 +0100 |
| Message-ID | <10dfusd$2k0q4$1@dont-email.me> |
| In reply to | #394698 |
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.
The actual task in this case must be one of the most OS-agnostic tasks
there is: read some text, write some text.
(The ccu.c file I posted was configured for Linux, but an OS-agnostic
version is possible too. The file mcc.c on the same site, will build on
both Windows and Linux, but it lacks the '$showmode' feature.)
>
>>>> Regarding your example, my old C compiler (which is a fraction the
>>>> size of this new Cdecl) 'explains' it as:
>>>>
>>>> 'ref proc(int)ref proc()void'
>>>>
>>>> (Not quite English, more Algol68-ish.)
>>> Can I run your old C compiler on my Ubuntu system?
>>>
>>
>> The old one needed a tweak to bring it up-to-date for my newer C
>> transpiler. So it was easier to port the feature to the newer product.
>>
>> Download https://github.com/sal55/langs/blob/master/ccu.c
>>
>> (Note: 86Kloc/2MB file; this is poor quality, linear C generated from
>> intermediate language.)
>>
>> Build instructions are at the top. Although this targets Win64, it
>> works enough to demonstrate the feature above. Create this C file (say
>> test.c):
>>
>> int main(void) {
>> void (*f(int i))(void);
>> $showmode f;
>> }
>>
>> Run as follows (if built as 'ccu'):
>>
>> ./ccu -s test
>>
>> It will display the type during compilation.
>>
>> Obviously this is not a dedicated product (and doing the reverse needs
>> a separate program), but I only needed to add about 10 lines of code
>> to support '$showmode'.
>>
>> Original source, omitting the unneeded output options, would be 2/3
>> the size of that configure script.
>
> OK, I was able to compile and run your ccu.c, and at least on this
> example it works as you've described it. It looks interesting,
> but I personally don't find it particularly useful, given that I
> already have cdecl, I prefer its syntax, and it's easier to use
> (and I almost literally could not care less about the number of
> lines of code needed to implement cdecl).
Well I built cdecl too, under WSL. Jesus, that looked a lot of work!
However, it took me a while to find where it put the executable, as the
make process doesn't directly tell you that. It seems it puts it inside
the src directory, which is unusual. It further appears that you have to
do 'make install' to be able to run it without a path.
(Yes, I did glance at the readme, but it is a .md file which I didn't
notice, and in plain text it looked unreadable.)
When I did run it, then while it had a fair number of options, it didn't
appear to do much beyond converting C declarations to and from an
English description.
That program is 2.8 MB (10 times the size of my C compiler).
I guess you don't care about that either. But surely, you must be
curious about WHY it is so big? You must surely know, with your decades
of experience, that this is 100 times bigger than necessary for such a task?
I decided to make my own mini-cdecl. It took 20 minutes and works like this:
c:\cx>qq cdecl
Mycdecl> explain void (*f(int i))(void);
f = proc(i32)ref proc()void
Mycdecl> q
It relies on a new feature of my C compiler, an extra linkage kind to go
with 'typedef' and 'static', called '$showtype'. When used, it displays
the type of the name being declared, and then stops compilation.
That allows me to invoke it from the script shown below. It doesn't do
'declare' though.
-----------------------------------------
do
print "Mycdecl> "
readln cmd:"n", rest:"l"
case cmd
when "explain" then
explaintype(rest)
when "x", "q", "exit" then
stop
else
println "?"
esac
od
proc explaintype(ctype)=
writestrfile("$temp.c", "$showtype "+ctype+";")
if system("cc $temp.c >result") = 0 then
println readtextfile("result")[2]
else
println "Error"
fi
end
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-10-24 19:35 +0200 |
| Message-ID | <10dgdc7$2of3m$1@dont-email.me> |
| In reply to | #394705 |
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. > > > 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. For my own use on a Linux system, I had to install a package (apt-get install libreadline-dev), but that's neither difficult to do, or time-consuming, and it was not hard to see what was needed. Of course, a non-programmer might not have realised that was needed, but if you are stumped on a configure script error "readline.h header not found, use --without-readline" and can't figure out how to get "readline.h" or configure the program to avoid using it, and can't at least google for help, then you are probably not the target audience for cdecl. > > However, it took me a while to find where it put the executable, as the > make process doesn't directly tell you that. It seems it puts it inside > the src directory, which is unusual. It further appears that you have to > do 'make install' to be able to run it without a path. > I agree that putting the executable in "src" is a little odd. But running "make install" is hardly unusual - it is as standard as it gets. (And of course there are a dozen other different ways you can arrange to run the programs without a path if you don't like "make install".) > (Yes, I did glance at the readme, but it is a .md file which I didn't > notice, and in plain text it looked unreadable.) > I agree that this README.md file is unusually clumsy when viewed as plain text - part of the point of Markdown is that it can be easily read and written as plain text. But github shows the readme in nicely rendered html, so it's hardly a big issue. > When I did run it, then while it had a fair number of options, it didn't > appear to do much beyond converting C declarations to and from an > English description. > It seems to be quite a flexible program, with a number of options. > 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. Considering that it supports C from the dark ages up to C23, C++ up to C++26 (with each standard along the way), lots of extensions - including MS stuff - as well as macro expansion tracing, I don't think the program sounds at all excessive in size. > > I guess you don't care about that either. But surely, you must be > curious about WHY it is so big? You must surely know, with your decades > of experience, that this is 100 times bigger than necessary for such a > task? Were you not curious, or did you just pull random sizes out of thin air as an excuse to complain again about any program written by anyone else but you? 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, 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).
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-24 19:50 +0100 |
| Message-ID | <10dghp5$2q30g$1@dont-email.me> |
| In reply to | #394711 |
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? 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? > >> >> >> 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. >> 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! >> I guess you don't care about that either. But surely, you must be >> curious about WHY it is so big? You must surely know, with your >> decades of experience, that this is 100 times bigger than necessary >> for such a task? > > Were you not curious, or did you just pull random sizes out of thin air > as an excuse to complain again about any program written by anyone else > but you? I have a version of Algol68 Genie which is nearly 4MB on Windows. Apparently the Linux version is 1-2MB only. You may recall this coming up on comp.lang.c. The point is, this is an implementation of an entire language, not just printing some type info. And maybe it includes debugging info, and the true size is even smaller; who knows? While Tiny C, even if you don't care for its abilities, still HAS to be able to decode full C99 type declarations. So understanding such types has to be accomplished within its 200KB size. > 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? 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.)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-10-24 18:59 +0000 |
| Message-ID | <p0QKQ.563989$Fe_d.359459@fx09.iad> |
| In reply to | #394713 |
bart <bc@freeuk.com> writes: >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? >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? Your antique ideas of "efficient", which rely on unsuitable metrics like executable size (which you apparently don't understand sufficiently to realize that the bulk of the content of the executable is optional and can easily be removed if you are so tight on disk space that a couple hundred kilobytes matters). $ man strip The strip command has been part of unix for a half century. But instead of accepting David's opinion as just that, David's opinion, you continue to criticize his opinion, the C language, the build system (make, autotools), and by proxy, the universe of developers and users that rely on that particular build system. > >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. You're repeating yourself. Your outrage won't change anyone's mind.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-10-24 13:20 -0700 |
| Message-ID | <87h5vo1276.fsf@example.invalid> |
| In reply to | #394713 |
bart <bc@freeuk.com> writes:
> 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?
Its efficiency is not a great concern. I've seen no perceptible delay
between issuing a command to cdecl and seeing the result. No, I don't
much care what it does behind the scenes. If I did care, I might look
through the sources and try to think of ways to improve it. But the
effort to do so would vastly exceed any time I might save running it.
The build and installation process for cdecl is very user-friendly. It
matches the process for thousands of other software packages that are
distributed in source. I can see that the process might be confusing if
you're not accustomed to it. If you *asked* rather than just
complaining, you might learn something.
The stripped executable occupies about 0.000008% of my hard drive.
> 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.
The configure script is automatically generated from "configure.ac",
which is 343 lines, 241 lines if comments and blank lines are
deleted. I've never written a configure.ac file myself, but most
of it looks like boilerplate. It would probably be fairly easy
(with some experience) to create one by modifying an existing one
from another project.
> 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?
Free software still has to be usable. cdecl is usable for most of us.
[...]
> 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.
Why is that a problem? If you like, you can redirect the output of
"./configure" and "make" to a file, and take a look at the output later
if you need to (you probably won't).
[...]
--
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 | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-24 23:18 +0100 |
| Message-ID | <10dgtvv$2tkdu$1@dont-email.me> |
| In reply to | #394718 |
On 24/10/2025 21:20, Keith Thompson wrote: > bart <bc@freeuk.com> writes: >> 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? 'Efficiency' is about lots of different aspects. If you use a metric which compares the scale of the actual task (compile a small, interactive console-based program into an executable) with what actually needs to be done here, it is wildly out of proportion. As one consequence of that, it is impossible to build on pure Windows. > Its efficiency is not a great concern. I've seen no perceptible delay > between issuing a command to cdecl and seeing the result. No, I don't > much care what it does behind the scenes. If I did care, I might look > through the sources and try to think of ways to improve it. But the > effort to do so would vastly exceed any time I might save running it. > > The build and installation process for cdecl is very user-friendly. Unless you're on Windows, because it is designed for Linux and Unix systems ONLY. Even on the latter, nobody messes with it because it is so complicated. Just cross your fingers and hope nothing goes wrong otherwise you're f***ed. > It > matches the process for thousands of other software packages that are > distributed in source. I can see that the process might be confusing if > you're not accustomed to it. If you *asked* rather than just > complaining, you might learn something. > > The stripped executable occupies about 0.000008% of my hard drive. > >> 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. > > The configure script is automatically generated from "configure.ac", > which is 343 lines, 241 lines if comments and blank lines are > deleted. I've never written a configure.ac file myself, but most > of it looks like boilerplate. It would probably be fairly easy > (with some experience) to create one by modifying an existing one > from another project. Or you could scrap the configure script completely. How about that? >> 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. > > Why is that a problem? If you like, you can redirect the output of > "./configure" and "make" to a file, and take a look at the output later > if you need to (you probably won't). It's a problem because I can see all the stupid crap it wastes time doing. Does it really need to test whether 'stdio.h' is available, and what happens if it isn't? Wouldn't you find out as soon as you try to compile anything? (I remember trying to build A68G, an interpreter, on Windows, and the 'configure' step was a major obstacle. But I was willing to isolate the 12 C source files involved, then it was built in one second. I did of course try building it in Linux too, and it took about 5 minutes that I recall, using a spinnning hard drive, mostly spent running through that configure script. Utterly pointless. And if I'd wanted to build another application on the same machine, it would have to do all the tests again! What on earth could have changed? If you say that the environment /could/ change between those two builds, then equally it could have changed during the minute or so between the configure tests, and starting to compile code.) > > [...] >
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-10-26 07:25 +0100 |
| Message-ID | <10dkesj$3r64j$1@dont-email.me> |
| In reply to | #394720 |
(This reply is not meant for bart, but rather for all interested folks who should not get repelled by his FUD posts.) On 25.10.2025 00:18, bart wrote: > [...] > > (I remember trying to build A68G, an interpreter, on Windows, and the > 'configure' step was a major obstacle. But I was willing to isolate the > 12 C source files involved, then it was built in one second. > > I did of course try building it in Linux too, and it took about 5 > minutes that I recall, using a spinnning hard drive, mostly spent > running through that configure script. (I don't know what system or system configuration the poster runs. I'm well aware that if you are using the Windows platform you may suffer from many things; but the platform choice is your decision! But maybe he's just misremembering; and nonetheless spreading FUD.) I've a quite old (~16+ years old) Linux system that was back these days when I bought it already at the _very low performance range_. With this old system the ./configure needs less than 10 seconds, and the build process with make about _half a minute_ for the whole a68g Genie system. - The whole procedure, from software download, extraction, configure/make, and start an Algol application, needs one minute! (Make that two minutes if you are typing v_e_r_y slowly or have a slow download link. Or just put the necessary commands in a shell file; just did that and it needed (including the download) less than 45 seconds, and ready to run.) Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-26 11:26 +0000 |
| Message-ID | <10dl0g9$3venf$1@dont-email.me> |
| In reply to | #394732 |
On 26/10/2025 06:25, Janis Papanagnou wrote:
> (This reply is not meant for bart, but rather for all interested
> folks who should not get repelled by his FUD posts.)
>
> On 25.10.2025 00:18, bart wrote:
>> [...]
>>
>> (I remember trying to build A68G, an interpreter, on Windows, and the
>> 'configure' step was a major obstacle. But I was willing to isolate the
>> 12 C source files involved, then it was built in one second.
>>
>> I did of course try building it in Linux too, and it took about 5
>> minutes that I recall, using a spinnning hard drive, mostly spent
>> running through that configure script.
>
> (I don't know what system or system configuration the poster runs.
> I'm well aware that if you are using the Windows platform you may
> suffer from many things; but the platform choice is your decision!
> But maybe he's just misremembering; and nonetheless spreading FUD.)
>
> I've a quite old (~16+ years old) Linux system that was back these
> days when I bought it already at the _very low performance range_.
> With this old system the ./configure needs less than 10 seconds,
> and the build process with make about _half a minute_ for the whole
> a68g Genie system. - The whole procedure, from software download,
> extraction, configure/make, and start an Algol application, needs
> one minute! (Make that two minutes if you are typing v_e_r_y slowly
> or have a slow download link. Or just put the necessary commands in
> a shell file; just did that and it needed (including the download)
> less than 45 seconds, and ready to run.)
The 5 minutes I quoted may have been for CPython. It would be for some
Linux running under VirtualBox on a 2010 cheapest-in-the-shop PC.
If I try A68G now, under WSL, using a 2021 second-cheapest PC but with
SSD, I get:
./configure 20 seconds
make 90 seconds
Trying CDECL again (I've done it several times after deleting the folder):
./configure 35 seconds
make 49 seconds
However the A68G configure script is 11000 lines; the CDECL one 31600 lines.
(I wonder why the latter needs 20000 more lines? I guess nobody is
curious - or they simply don't care. OK, let's make 100,000 and see if
anyone complains! Is it possible this is some elaborate joke on the part
of auto-conf to discover just how trusting and tolerant people can be?)
Anyway, I then tried this new 3.10 A68G on the Fannkuch(9) benchmark:
a68g fann.a68 5 seconds
./fann 3+3 seconds (via a68g --compile -O3 fann.a68)
I then tried it under my scripting language (not statically typed):
qq fann 0.4 seconds (qq built with my non-optimising compiler)
'qq' takes about 0.1 seconds to build - under Windows which is
considered slow for development. So, 1000 times faster to build, and it
runs this program at least, 10 times faster, despite being dynamically
typed.
This is the vast difference between my world and yours.
>The whole procedure, from software download,
> extraction, configure/make, and start an Algol application, needs
> one minute!
Only one minute; impressive! How about this:
c:\qx>tm mm -r \mx\mm -r qq hello
Hello World
TM: 0.21
This runs my systems language /from source code/, whch then runs my
interpreter /from source code/ (ie. compiles into memory and runs
immediately) then runs that test program.
In 1/5th of a second (or 1/300th of a minute). This is equivalent to
first compiling gcc from source (and all those extra utilities you seem
to need) before using it/them to build a68g. I guess that would take a
bit more than a minute.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-26 13:26 +0000 |
| Message-ID | <10dl7hh$12lf$1@dont-email.me> |
| In reply to | #394736 |
On 26/10/2025 11:26, bart wrote:
> On 26/10/2025 06:25, Janis Papanagnou wrote:
>> (This reply is not meant for bart, but rather for all interested
>> folks who should not get repelled by his FUD posts.)
>>
>> On 25.10.2025 00:18, bart wrote:
>>> [...]
>>>
>>> (I remember trying to build A68G, an interpreter, on Windows, and the
>>> 'configure' step was a major obstacle. But I was willing to isolate the
>>> 12 C source files involved, then it was built in one second.
>>>
>>> I did of course try building it in Linux too, and it took about 5
>>> minutes that I recall, using a spinnning hard drive, mostly spent
>>> running through that configure script.
>>
>> (I don't know what system or system configuration the poster runs.
>> I'm well aware that if you are using the Windows platform you may
>> suffer from many things; but the platform choice is your decision!
>> But maybe he's just misremembering; and nonetheless spreading FUD.)
>>
>> I've a quite old (~16+ years old) Linux system that was back these
>> days when I bought it already at the _very low performance range_.
>> With this old system the ./configure needs less than 10 seconds,
>> and the build process with make about _half a minute_ for the whole
>> a68g Genie system. - The whole procedure, from software download,
>> extraction, configure/make, and start an Algol application, needs
>> one minute! (Make that two minutes if you are typing v_e_r_y slowly
>> or have a slow download link. Or just put the necessary commands in
>> a shell file; just did that and it needed (including the download)
>> less than 45 seconds, and ready to run.)
>
>
> The 5 minutes I quoted may have been for CPython. It would be for some
> Linux running under VirtualBox on a 2010 cheapest-in-the-shop PC.
>
> If I try A68G now, under WSL, using a 2021 second-cheapest PC but with
> SSD, I get:
>
> ./configure 20 seconds
> make 90 seconds
> Only one minute; impressive! How about this:
>
> c:\qx>tm mm -r \mx\mm -r qq hello
> Hello World
> TM: 0.21
>
> This runs my systems language /from source code/, whch then runs my
> interpreter /from source code/ (ie. compiles into memory and runs
> immediately) then runs that test program.
TBF, all such tests need to be from 'cold'. I don't normally do that,
because in routine compilation, you are building something that was just
edited, or just compiled, just generated, or even just downloaded and
extracted. So any files involved will already be cached.
So the following are after a restart of my PC:
Build CDECL under WSL (files were extracted before the restart):
60/56 seconds instead 35/49 seconds for configure/make
My demo above running both compiler and interpreter from source:
0.31 seconds instead of 0.21 seconds
New test of gcc compiling hello.c:
1 second, settling down to 0.23 seconds on subsequent builds
So gcc on Windows still takes longer longer to build a 4-line C program,
than it takes my tools to build an entire compiler and interpreter.
This further emphasises the mismatch between my own everyday experience
and that of most others here.
To be clear, the speed of my tools is 99% due to massive advances in
hardware over decades, rather than my own efforts; I didn't have to do much!
However all those other tools run on the exact same hardware....
Sometimes it pays to be on the ball, to question everything, and to be
intolerant. Something takes even 2 seconds to some task; it's not a long
time, but ... why IS it taking 10 times as long as necessary?
Paradoxically, huge efforts are expended in getting the fastest possible
code from these large compilers, and sometimes the smallest code.
Well, perhaps it's to try and keep up with users writing ever more
inefficient programs! Maybe that 2-second program would have taken 10
seconds.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-10-26 16:07 +0000 |
| Message-ID | <XGrLQ.764130$80J6.356555@fx12.iad> |
| In reply to | #394737 |
bart <bc@freeuk.com> writes: >On 26/10/2025 11:26, bart wrote: >> On 26/10/2025 06:25, Janis Papanagnou wrote: > >So the following are after a restart of my PC: > > Build CDECL under WSL (files were extracted before the restart): > 60/56 seconds instead 35/49 seconds for configure/make > > My demo above running both compiler and interpreter from source: > 0.31 seconds instead of 0.21 seconds > > New test of gcc compiling hello.c: > 1 second, settling down to 0.23 seconds on subsequent builds Get back to us when your "build + compiler" system will successfully build all the software that currently builds with autoconf, make and gcc.
[toc] | [prev] | [next] | [standalone]
Page 1 of 10 [1] 2 3 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web