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 | 16 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 10 of 10 — ← Prev page 1 … 8 9 [10]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-10-25 15:14 -0700 |
| Message-ID | <87a51e1ve9.fsf@example.invalid> |
| In reply to | #394727 |
bart <bc@freeuk.com> writes:
> 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.
Yes, the build process is *internally* complicated. When I type
the three or so commands needed to build and install the tool from
source, it uses a lot of non-C input files, and generates some large
intermediate files. None of that bothers me when I install it on
a Unix-like system. There's no particular reason for me to care.
It obviously bothers you, particularly if you want to install it
on pure Windows. So what are you going to do about it? So far,
you've been complaining *for years* to a group of people who are
not in a position to do anything about it. I am not a GNU autotools
maintainer, and as far as I know nobody else here is either.
Maybe GNU autotools could be modernized, not bothering to check for
language and library features that are now universally supported.
Maybe it could be updated to work better on pure Windows, without
Cygwin or WSL or MSYS. Maybe that's something useful you could
work on. That kind of work could make hundreds or thousands of
existing software tools easier to build and install.
Or if you only want to talk about it, maybe it would be more
productive to do so on one of the GNU mailing lists. (If you do,
be aware that a lot of the people you'll be talking to don't care
about MS Windows.)
> 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?
I haven't studied the source. Maybe you're right. Maybe *you* could
work on it. If you can adapt the existing cdecl program into, say,
a single portable C source file, so it can easily be built either
on Unix-like systems or on Windows, that could actually be useful.
It's GPL licensed, so you can create your own forked version, just
as the current maintainer has. (I would ask that you at least
retain the option to use GNU readline, so there would have to be
*some* configuration.)
--
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-26 08:07 +0100 |
| Message-ID | <10dkhb5$3rlvo$1@dont-email.me> |
| In reply to | #394727 |
On 25.10.2025 17:48, bart wrote: > > [...] Unfortunately it is typical of such products originating from > Unix-Linux (you really want one term that you can use for both). There are such terms. - I've used since decades (and it's meanwhile also widely used!) the term Unix for the family of UNIX-like systems. I suggest using that term. (But you find also other terms, like *nix, that I personally don't like much, but that is also well and widely understood.) For complaining and bloviating about that OS-family any of these terms might suit you well enough (and will be understood). Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-10-24 21:36 +0200 |
| Message-ID | <10dgkgi$2qve3$1@dont-email.me> |
| In reply to | #394711 |
On 24.10.2025 19:35, David Brown wrote: > On 24/10/2025 15:27, bart wrote: >> >> 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. Unusual for whom? > It further appears that >> you have to do 'make install' to be able to run it without a path. Yes, sure; if you want to use an executable as a regular program you have to install it at the (or at some) appropriate place. I'd consider it a horror if I'd compile a source and any previous installed version gets overwritten (or shadowed); even more so in a multi-user system! > > 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".) It is quite common that the executable file of a software package is created in the directory where the sources reside. (I've just a hand-full of third-party packages on my system but all do exactly that. In my own projects I have typically also a two-step process; some "make" (or alike) generation process (in the source directory) and some "install" (or alike) installation or upload process.) There's of course also larger projects that may have an organized hierarchy of directories for system components and/or libraries. Then the makefiles(-hierarchies) handle that, each in its scope. For the use of executables or libraries there's the install step, of course. In professional contexts you don't want these steps combined. After the build you want to pre-install it in an QA area for the tests. Another step is the packaging to deliver the software products. And the package can then be installed; first in the next level QA test, later, after approval, at the production site. For private, primitive, or toy projects these steps are usually not (or not all) necessary. But even there it's typically not the right thing to have the build and install step combined, as explained initially. But anyway I also wonder about bart that he couldn't find it; maybe he's expecting some Windows "convention" on Unix? - If in doubt I'm just typing 'ls -ltr' to see the latest files created or directory that got updated to get a concrete hint on where the software products have been generated. Janis
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-10-24 13:07 -0700 |
| Message-ID | <87ldl012su.fsf@example.invalid> |
| In reply to | #394711 |
David Brown <david.brown@hesbynett.no> writes:
> On 24/10/2025 15:27, bart wrote:
[...]
>> 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.
WSL, "Windows Subsystem for Linux" (which should probably have been
called "Linux Subsystem for Windows") provides something that looks just
like a direct Linux desktop system. It supports several different
Linux-based distributions. I use Ubuntu, and the build procedure under
WSL is exactly the same as under Ubuntu.
>> 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".)
Putting the executable in src is very common for this kind of package.
I generally don't notice, since I always run "make install", which knows
where to find the executable and where to copy it.
[...]
>> 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.
It's easier than that. The Makefile provides an "install-strip" option
that does the installation and strips the executable. A lot of packages
like this support "make install-strip". For those that don't, just run
"strip" manually after installation.
[...]
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-10-25 13:15 +0200 |
| Message-ID | <10dibh1$37h93$2@dont-email.me> |
| In reply to | #394717 |
On 24/10/2025 22:07, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 24/10/2025 15:27, bart wrote: > [...] >>> 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. > > WSL, "Windows Subsystem for Linux" (which should probably have been > called "Linux Subsystem for Windows") provides something that looks just > like a direct Linux desktop system. It supports several different > Linux-based distributions. I use Ubuntu, and the build procedure under > WSL is exactly the same as under Ubuntu. > Sure. I know what WSL is, I just haven't used it. (In my office I have a Windows machine and a Linux machine, and it's not often that I need to use more than a basic set of msys2 stuff on Windows or Wine on Linux, because I can usually run things on their "native" OS.) >>> 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".) > > Putting the executable in src is very common for this kind of package. > I generally don't notice, since I always run "make install", which knows > where to find the executable and where to copy it. > Maybe I am coloured by my preferences - I prefer to keep the build in a tree adjacent to the source code, rather than in the source code directories, at least for projects of a certain size. Of course you (and others) are right that lots of builds /do/ make the executable in the source directory. > [...] > >>> 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. > > It's easier than that. The Makefile provides an "install-strip" option > that does the installation and strips the executable. A lot of packages > like this support "make install-strip". For those that don't, just run > "strip" manually after installation. > Yes.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-10-24 13:01 -0700 |
| Message-ID | <87plac132k.fsf@example.invalid> |
| In reply to | #394705 |
bart <bc@freeuk.com> writes:
> 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.
Eventually? Once I cloned the repository, it took about 45 seconds to
build and install from source on my system, and I was able to run it
immediately.
I happen to have a script that automates much of the process that could
otherwise be done with about 3 commands. Writing that script was
worthwhile *for me* because I happen to build a lot of autotools-based
packages from source. Without that, it might have taken me several
minutes.
> That it favours your own OS, leaving users of other to have to jump
> through extra hoops, doesn't appear to bother you.
Why should it bother me? I can certainly see that an easier way to
build cdecl on Windows would be a good thing, but it doesn't affect me.
[...]
> Well I built cdecl too, under WSL. Jesus, that looked a lot of work!
Really? I built it under WSL myself, using exactly the same method I
used on my Ubuntu system. Cygwin too. The latter was a bit slow, but I
did other things while it was building.
Are you at all interested in learning how to build this kind of software
package more easily? If so, email me. This isn't really about C, so
I'd rather not dive into it too deeply here.
There are certainly things to dislike about autotools, but there are
thousands of software packages that use it. Once you learn how to build
one such package, you can build most of them (at least in a Unix-like
environment).
No, it doesn't work well for Windows without a Unix-like emulation
layer. Maybe it could be enhanced to work better on Windows. Maybe you
could contribute to making that happen.
> 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.
That's not unusual -- and the "make install" step is common to hundreds
of software packages. I usually don't notice where the executable
initially appears; "make install" puts it where I want it.
> (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.)
Sure, it would be nice if the README.md were more legible. Most of
them are. Apparently the author was more interested in it being
readable using a markdown viewer. But if you view the project's
site on GitHub, the README.md is formatted for you.
> 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).
As mentioned later in this thread, you didn't strip the executable. It
might be nice if stripping the executable were the default.
> 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?
How many lines of assembly language were generated and discarded during
compilation? I'm guessing you don't know or care. Why do you care so
much about other things that you don't need?
> 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
I doubt that that obscure syntax would be of interest to most people,
though I'm sure it works for you. If you wanted to generate something
more readable by more users, you might have an interesting competitor to
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 | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-10-24 15:01 -0700 |
| Message-ID | <10dgsvf$2sl6c$2@dont-email.me> |
| In reply to | #394692 |
On 10/23/2025 4:04 PM, 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. Fwiw, if you can find the tool that you want to use here: https://vcpkg.io it can be automatically built and integrated into MSVC. So far, it works okay... [...]
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <noone@noone.net> |
|---|---|
| Date | 2025-10-26 12:09 -0700 |
| Message-ID | <10dlrl2$78t1$1@dont-email.me> |
| In reply to | #394664 |
On Wed 10/22/2025 2:39 PM, Keith Thompson wrote: > ... I believe I have already posted about it here... or maybe not? cdecl.org reports a "syntax error" for declarations with top-level `const` qualifiers on function parameters: void foo(char *const) Such declarations are perfectly valid. (And adding an explcit parameter name does not help). The current version of cdecl.org still complains about it. -- Best regards, Andrey
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-10-26 15:36 -0700 |
| Message-ID | <87v7k1z3xk.fsf@example.invalid> |
| In reply to | #394746 |
Andrey Tarasevich <noone@noone.net> writes:
> On Wed 10/22/2025 2:39 PM, Keith Thompson wrote:
>> ...
>
> I believe I have already posted about it here... or maybe not?
>
> cdecl.org reports a "syntax error" for declarations with top-level
> `const` qualifiers on function parameters:
>
> void foo(char *const)
>
> Such declarations are perfectly valid. (And adding an explcit
> parameter name does not help).
>
> The current version of cdecl.org still complains about it.
You're probably using 2.5, the version most commonly packaged with Linux
distributions. The cdecl.org site uses that same old version.
This entire thread is about the newer version available at
<https://github.com/paul-j-lucas/cdecl/>. It doesn't have that bug.
$ cdecl --version
cdecl 18.6
Copyright (C) 2025 Paul J. Lucas
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY to the extent permitted by law.
$ cdecl explain 'void foo(char *const)'
declare foo as function (constant pointer to character) returning void
$ cdecl explain 'void foo(char *const foo)'
declare foo as function (foo as constant pointer to character) returning void
$
(I'm not entirely pleased that the newer version expands "char" to
"character" and, worse, "int" to "integer", but I can live with it.)
--
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 | "Paul J. Lucas" <paul@lucasmail.org> |
|---|---|
| Date | 2025-12-09 07:31 -0800 |
| Message-ID | <10h9fde$th53$1@dont-email.me> |
| In reply to | #394752 |
On 10/26/25 3:36 PM, Keith Thompson wrote: > (I'm not entirely pleased that the newer version expands "char" to > "character" and, worse, "int" to "integer", but I can live with it.) Hence the --no-english-types or -T command line option or the "set noenglish" command (from within cdecl or a config file). The thought was that those newer to C and less familiar with its types might benefit from more elaborate output. - Paul
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <046-301-5902@kylheku.com> |
|---|---|
| Date | 2025-12-09 20:38 +0000 |
| Message-ID | <20251209121945.235@kylheku.com> |
| In reply to | #395738 |
On 2025-12-09, Paul J. Lucas <paul@lucasmail.org> wrote: > On 10/26/25 3:36 PM, Keith Thompson wrote: >> (I'm not entirely pleased that the newer version expands "char" to >> "character" and, worse, "int" to "integer", but I can live with it.) > > Hence the --no-english-types or -T command line option or the > "set noenglish" command (from within cdecl or a config file). The problem is that the English words chosen already have a meaning. "Integer" is a type category in C; uint32_t is one of the "integer types". "Character" is a representational concept for units of text, manifesting itself via different types and sometimes even aggregates (e.g multi-byte character). > The thought was that those newer to C and less familiar with its > types might benefit from more elaborate output. This kind of thing just ensures that newbies go sideways from being less familiar to being incorrectly familiar. They should know from their first contact with the char type that it's just an integer type with a small range. (Arrays of which are used for text storage in classic text processing, where if a legacy character set is used such as ASCII, there is a 1:1 correspondence between each char element and a character, otherwise not.) -- 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 | "Paul J. Lucas" <paul@lucasmail.org> |
|---|---|
| Date | 2025-12-09 16:46 -0800 |
| Message-ID | <10hafso$16u9e$1@dont-email.me> |
| In reply to | #395741 |
On 12/9/25 12:38 PM, Kaz Kylheku wrote: > On 2025-12-09, Paul J. Lucas <paul@lucasmail.org> wrote: >> On 10/26/25 3:36 PM, Keith Thompson wrote: >>> (I'm not entirely pleased that the newer version expands "char" to >>> "character" and, worse, "int" to "integer", but I can live with it.) >> >> Hence the --no-english-types or -T command line option or the >> "set noenglish" command (from within cdecl or a config file). > > The problem is that the English words chosen already have a meaning. > > "Integer" is a type category in C; It's not a keyword, so that's irrelevant. Likewise, "Character." >> The thought was that those newer to C and less familiar with its >> types might benefit from more elaborate output. > > This kind of thing just ensures that newbies go sideways from being > less familiar to being incorrectly familiar. Opinion noted. I disagree. - Paul
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-12-09 17:51 -0800 |
| Message-ID | <87bjk7ayuu.fsf@example.invalid> |
| In reply to | #395749 |
"Paul J. Lucas" <paul@lucasmail.org> writes:
> On 12/9/25 12:38 PM, Kaz Kylheku wrote:
>> On 2025-12-09, Paul J. Lucas <paul@lucasmail.org> wrote:
>>> On 10/26/25 3:36 PM, Keith Thompson wrote:
>>>> (I'm not entirely pleased that the newer version expands
>>>> "char" to "character" and, worse, "int" to "integer", but I
>>>> can live with it.)
>>>
>>> Hence the --no-english-types or -T command line option or the
>>> "set noenglish" command (from within cdecl or a config file).
>> The problem is that the English words chosen already have a
>> meaning. "Integer" is a type category in C;
>
> It's not a keyword, so that's irrelevant. Likewise,
> "Character."
>
>>> The thought was that those newer to C and less familiar with
>>> its types might benefit from more elaborate output.
>> This kind of thing just ensures that newbies go sideways from
>> being less familiar to being incorrectly familiar.
>
> Opinion noted. I disagree.
If you prefer the C-like syntax rather than pseudo-English (as I
do), you can change the default by creating a ".cdeclrc" file.
$ cdecl explain "int n;" declare n as integer $ echo "set
noenglish-types" > $HOME/.cdeclrc $ cdecl explain "int n;" declare
n as int $
--
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 | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-10-26 14:44 -0700 |
| Message-ID | <10dm4oi$9uhq$1@dont-email.me> |
| In reply to | #394664 |
On 10/22/2025 2:39 PM, Keith Thompson wrote:
> 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/>.
I must be doing something wrong:
int (*fp_read) (void* const, void*, size_t)
is syntax error. It from one of my older experiments:
struct device_prv_vtable {
int (*fp_read) (void* const, void*, size_t);
int (*fp_write) (void* const, void const*, size_t);
};
https://groups.google.com/g/comp.lang.c/c/-BFbjYxcBQg/m/2uRErOV6AgAJ
https://pastebin.com/raw/f52a443b1
(link to raw text...)
[...]
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-10-26 15:38 -0700 |
| Message-ID | <87qzupz3tx.fsf@example.invalid> |
| In reply to | #394749 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> On 10/22/2025 2:39 PM, Keith Thompson wrote:
>> 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/>.
> I must be doing something wrong:
Yes.
> int (*fp_read) (void* const, void*, size_t)
>
> is syntax error. It from one of my older experiments:
You're using the old 2.5 version. The newer forked version handles that
declaration correctly, but you have to build it from source. cdecl.org
uses the old version.
--
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 | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-10-27 11:51 -0700 |
| Message-ID | <10doeve$13cso$2@dont-email.me> |
| In reply to | #394753 |
On 10/26/2025 3:38 PM, Keith Thompson wrote: > "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >> On 10/22/2025 2:39 PM, Keith Thompson wrote: >>> 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/>. >> I must be doing something wrong: > > Yes. > >> int (*fp_read) (void* const, void*, size_t) >> >> is syntax error. It from one of my older experiments: > > You're using the old 2.5 version. The newer forked version handles that > declaration correctly, but you have to build it from source. cdecl.org > uses the old version. > Ahh! Thanks Keith.
[toc] | [prev] | [standalone]
Page 10 of 10 — ← Prev page 1 … 8 9 [10]
Back to top | Article view | comp.lang.c
csiph-web