Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #396684 > unrolled thread
| Started by | DFS <nospam@dfs.com> |
|---|---|
| First post | 2026-02-19 16:55 -0500 |
| Last post | 2026-03-16 09:04 +0100 |
| Articles | 20 on this page of 218 — 21 participants |
Back to article view | Back to comp.lang.c
Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-02-19 16:55 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway jayjwa <jayjwa@atr2.ath.cx.invalid> - 2026-02-25 15:56 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-02-26 10:05 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway jayjwa <jayjwa@atr2.ath.cx.invalid> - 2026-02-26 13:20 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-02-26 17:06 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-02-26 17:27 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-02-26 14:31 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway jayjwa <jayjwa@atr2.ath.cx.invalid> - 2026-02-26 13:33 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-02-26 18:49 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-02-26 18:55 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-02-26 19:17 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-02-26 19:34 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-02-26 20:01 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-06 10:36 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-06 17:38 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-06 17:48 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-02-27 00:12 +0000
[OT] Bart's scripting language solution (was Re: Sort of trivial code challenge - may be interesting to you anyway) Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-06 06:37 +0100
Re: [OT] Bart's scripting language solution (was Re: Sort of trivial code challenge - may be interesting to you anyway) Bart <bc@freeuk.com> - 2026-03-06 15:48 +0000
Re: [OT] Bart's scripting language solution (was Re: Sort of trivial code challenge - may be interesting to you anyway) Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-06 18:17 +0100
Re: [OT] Bart's scripting language solution (was Re: Sort of trivial code challenge - may be interesting to you anyway) Bart <bc@freeuk.com> - 2026-03-06 21:46 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-02 00:44 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-02 11:07 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-02 06:35 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-02 17:50 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-02 21:15 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-03 20:48 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-03 22:47 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway David Brown <david.brown@hesbynett.no> - 2026-03-04 08:48 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-04 01:07 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-04 12:09 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-04 11:19 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway David Brown <david.brown@hesbynett.no> - 2026-03-04 12:58 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-11 11:31 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-04 13:20 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-04 08:30 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-04 14:36 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-04 10:02 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-04 19:27 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-05 13:49 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-05 21:02 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-05 20:39 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-05 19:24 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-05 13:54 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-12 05:50 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-13 11:58 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-13 23:00 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-15 15:54 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-15 23:42 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-06 12:02 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-15 15:43 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-02 17:40 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-02 21:09 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-03 08:23 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-03 06:20 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-03 23:56 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-03 15:51 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-04 11:45 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-04 07:01 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-11 11:37 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-04 08:29 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-04 16:02 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-04 08:09 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-06 10:34 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-06 08:46 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-04 11:25 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-05 13:46 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway David Brown <david.brown@hesbynett.no> - 2026-03-05 21:34 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-05 19:09 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-05 21:12 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-05 14:12 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-05 22:24 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-06 01:00 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-05 15:08 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-05 15:05 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-06 00:18 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-07 22:04 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-08 00:26 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-08 02:45 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-08 17:05 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-11 07:57 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-06 00:12 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-06 00:14 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-05 20:31 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-06 13:51 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-06 08:53 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-06 19:36 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-06 18:14 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-07 18:21 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-07 11:55 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-07 20:10 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-11 10:44 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-07 12:02 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-07 20:14 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-11 10:53 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-07 16:58 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-08 00:35 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-11 08:23 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-08 00:40 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-08 10:42 -0400
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-08 15:18 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-08 12:21 -0400
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-08 19:29 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-09 21:20 -0400
Re: Sort of trivial code challenge - may be interesting to you anyway scott@slp53.sl.home (Scott Lurndal) - 2026-03-10 14:43 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-10 18:08 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Giovanni <lsodgf0@home.net.it> - 2026-03-10 17:18 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway scott@slp53.sl.home (Scott Lurndal) - 2026-03-10 16:32 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-10 15:25 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-11 07:07 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-11 13:49 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-10 20:24 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-10 15:29 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-11 00:29 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway scott@slp53.sl.home (Scott Lurndal) - 2026-03-11 00:33 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-11 11:04 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway antispam@fricas.org (Waldek Hebisch) - 2026-03-10 20:18 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-12 05:37 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-08 17:57 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-08 13:19 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-09 01:12 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway scott@slp53.sl.home (Scott Lurndal) - 2026-03-08 21:42 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-03-08 15:58 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway David Brown <david.brown@hesbynett.no> - 2026-03-09 08:09 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-09 08:53 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-03-09 15:25 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-11 14:40 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-12 05:55 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-08 16:00 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-11 12:44 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-08 17:36 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-08 13:27 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-11 06:33 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway David Brown <david.brown@hesbynett.no> - 2026-03-08 12:22 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-11 06:27 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-07 16:43 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-11 07:29 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-11 14:22 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-25 10:07 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-25 15:54 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-30 03:13 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-06 16:02 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-06 12:11 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-06 13:01 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-06 13:28 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-06 21:53 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-06 22:14 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-07 07:33 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-07 10:24 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-07 19:16 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-07 14:18 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-08 00:47 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-09 22:18 -0400
Re: Sort of trivial code challenge - may be interesting to you anyway Richard Harnden <richard.nospam@gmail.invalid> - 2026-03-10 10:14 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Richard Harnden <richard.nospam@gmail.invalid> - 2026-03-11 11:40 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-07 13:33 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Richard Harnden <richard.nospam@gmail.invalid> - 2026-03-07 14:53 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-07 15:44 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-07 19:53 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-07 10:22 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-11 11:40 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-11 11:00 -0400
Re: Sort of trivial code challenge - may be interesting to you anyway wij <wyniijj5@gmail.com> - 2026-03-12 00:00 +0800
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-11 18:03 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway scott@slp53.sl.home (Scott Lurndal) - 2026-03-11 17:52 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway wij <wyniijj5@gmail.com> - 2026-03-12 23:14 +0800
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-12 16:23 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-12 16:11 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-05 14:04 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-11 11:36 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-11 11:35 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-03 15:40 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-03 16:23 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-04 15:31 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-04 09:38 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-03 16:39 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-03 12:00 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-04 11:44 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-04 17:44 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-04 15:13 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-04 21:07 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway scott@slp53.sl.home (Scott Lurndal) - 2026-03-04 23:37 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-05 07:32 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-05 08:23 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-05 02:24 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-05 08:46 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-05 09:52 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway tTh <tth@none.invalid> - 2026-03-05 10:49 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-05 11:03 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway gazelle@shell.xmission.com (Kenny McCormack) - 2026-03-05 15:22 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-05 05:06 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-05 11:13 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-05 14:11 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-06 03:35 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway scott@slp53.sl.home (Scott Lurndal) - 2026-03-05 14:49 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-05 19:27 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-05 19:46 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway tTh <tth@none.invalid> - 2026-03-05 20:50 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-05 22:34 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-06 07:48 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-06 11:49 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-06 13:41 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-06 15:33 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-06 14:42 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-05 13:49 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway scott@slp53.sl.home (Scott Lurndal) - 2026-03-06 02:17 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-05 20:06 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway scott@slp53.sl.home (Scott Lurndal) - 2026-03-06 14:58 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-06 17:13 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-06 08:37 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway scott@slp53.sl.home (Scott Lurndal) - 2026-03-03 17:29 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-03 19:20 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-03 16:26 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-04 05:27 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Opus <ifonly@youknew.org> - 2026-03-04 22:42 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway peter <peter.noreply@tin.it> - 2026-03-14 10:42 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-15 15:09 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-16 09:04 +0100
Page 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-03-08 15:18 +0000 |
| Message-ID | <10ok405$2f6sn$1@dont-email.me> |
| In reply to | #396864 |
On 08/03/2026 14:42, DFS wrote: > On 3/7/2026 6:40 PM, Janis Papanagnou wrote: >> On 07.03.26 22:58, DFS wrote: >>> On 3/7/2026 3:02 PM, Tim Rentsch wrote: >>>> [...] >>> >>> What do you think would be the reaction in a corporate programming >>> dept to this unique kind of code? >> >> From my experiences in a couple such departments of professional >> software development... >> >> The "uniqueness" would not be a problem. It would have failed to >> many requirements that maintainable code was expected to have. > > I figured as much. > > > Nested ternaries like this: > > c = square ? a1 : !hwc ? h*w : a3 > h*w ? h*w : a3; > > are harder to decipher at first glance than 3 or 4 levels of indented > if-then-elses. TR doesn't like parentheses around ?: terms; everyone is expected to know their precedence. (BTW I would class ?: as 'if'. In the languages I create, the 'if' statement the the ternary operator, which I write as (||), are interchangeable.) >> I can explain the (positive) excitement only by some nerdy stance >> in this specific CLC domain. > > > Give the man his due. It's extremely unique and excitement-worthy. > > What's also very nice is there are no long lines that wrap. > > Sure it's a bearded-lady novelty, but I think he knocked it out of the > park. > Funny though how TR castigated me for not offering a C solution, but his solution is one I would not class as C code, as it only uses a subset of the language and in a weird manner (a bit like some of my generated C which is not meant to be human-readable). My script code is however trivially convertible to C (which I later posted) or to any other language. While his C solution is much harder to port as it is; it would need rewriting, once you can figure out how it works.
[toc] | [prev] | [next] | [standalone]
| From | DFS <nospam@dfs.com> |
|---|---|
| Date | 2026-03-08 12:21 -0400 |
| Message-ID | <10ok7mt$2e7mc$5@dont-email.me> |
| In reply to | #396865 |
On 3/8/2026 11:18 AM, Bart wrote: > In the languages I create, plural? It's very impressive that you developed your own working language. Is the BartScript interpreter written in C? Can you post it? The reference Python implementation is written in C. https://github.com/python/cpython > Funny though how TR castigated me for not offering a C solution, > but his solution is one I would not class as C code, It is. It compiled with gcc, and uses C library functions. > My script code is however trivially convertible to C > (which I later posted) I just tested it. It prints past the cutoffs, but does make the correct decision about the square matrix.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-03-08 19:29 +0000 |
| Message-ID | <10oking$2jsja$1@dont-email.me> |
| In reply to | #396868 |
On 08/03/2026 16:21, DFS wrote:
> On 3/8/2026 11:18 AM, Bart wrote:
>
>
>> In the languages I create,
>
> plural?
>
> It's very impressive that you developed your own working language. Is
> the BartScript interpreter written in C? Can you post it?
I normally run my own systems programming language. I've been doing that
for well over 40 years (but the language has evolved a little!).
It is written in itself ('self-hosted'). It was used to implement that
scripting language. And it was used to implement a C compiler of sorts
which I used to test some of the code posted here including Tim's version.
>
> The reference Python implementation is written in C.
> https://github.com/python/cpython
>
>
>
> > Funny though how TR castigated me for not offering a C solution,
> > but his solution is one I would not class as C code,
>
> It is. It compiled with gcc, and uses C library functions.
Using C functions means nothing. I can use C functions too (note that
setjmp/longjmp are not functions); so can many languages.
But C is very frequently used to emulate all sorts of different
paradigms, and/or syntaxes. People have written programs entirely using
using C's preprocessor macros.
I can turn code written in my systems language into an intermediate,
linear language, and can then turn that into attrocious C source code.
IOCCC entries offer more examples.
It will all compile with gcc, but again I would hesitate to call it
'writing in C'; more like 'abusing C'!
My own manually written C code is very conservative in style.
(I did start translating TR's C code into my language, just to see of it
could also express such a program.
I got as far as implementing versions of setjmp/longjmp, which my
language lacks. But there I stopped: I found it too annoying to just
slavishly follow the same coding style, and I would probably have
rewritten half of it.)
[toc] | [prev] | [next] | [standalone]
| From | DFS <nospam@dfs.com> |
|---|---|
| Date | 2026-03-09 21:20 -0400 |
| Message-ID | <10onrkk$3s7id$2@dont-email.me> |
| In reply to | #396871 |
On 3/8/2026 3:29 PM, Bart wrote: > note that setjmp/longjmp are not functions huh? https://man7.org/linux/man-pages/man3/longjmp.3.html
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-03-10 14:43 +0000 |
| Message-ID | <k6WrR.167431$MXdd.56107@fx18.iad> |
| In reply to | #396880 |
DFS <nospam@dfs.com> writes: >On 3/8/2026 3:29 PM, Bart wrote: > >> note that setjmp/longjmp are not functions > > >huh? > >https://man7.org/linux/man-pages/man3/longjmp.3.html POSIX allows setjmp to be defined as a macro. https://pubs.opengroup.org/onlinepubs/9799919799/functions/setjmp.html
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-03-10 18:08 +0200 |
| Message-ID | <20260310180831.00002b7b@yahoo.com> |
| In reply to | #396883 |
On Tue, 10 Mar 2026 14:43:28 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > DFS <nospam@dfs.com> writes: > >On 3/8/2026 3:29 PM, Bart wrote: > > > >> note that setjmp/longjmp are not functions > > > > > >huh? > > > >https://man7.org/linux/man-pages/man3/longjmp.3.html > > POSIX allows setjmp to be defined as a macro. > > https://pubs.opengroup.org/onlinepubs/9799919799/functions/setjmp.html > Just allows? Are there real-world examples of implementing setjmp not as a macro?
[toc] | [prev] | [next] | [standalone]
| From | Giovanni <lsodgf0@home.net.it> |
|---|---|
| Date | 2026-03-10 17:18 +0100 |
| Message-ID | <10opg7s$fp8$1@milena.home.net.it> |
| In reply to | #396884 |
On 3/10/26 17:08, Michael S wrote: >> POSIX allows setjmp to be defined as a macro. >> >> https://pubs.opengroup.org/onlinepubs/9799919799/functions/setjmp.html >> > Just allows? > Are there real-world examples of implementing setjmp not as a macro? > I had to implement it in a boot loader and did it in x86 assembler. Ciao Giovanni -- A computer is like an air conditioner, it stops working when you open Windows. < https://giovanni.homelinux.net/ >
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-03-10 16:32 +0000 |
| Message-ID | <cIXrR.279464$K0Ib.225529@fx45.iad> |
| In reply to | #396884 |
Michael S <already5chosen@yahoo.com> writes: >On Tue, 10 Mar 2026 14:43:28 GMT >scott@slp53.sl.home (Scott Lurndal) wrote: > >> DFS <nospam@dfs.com> writes: >> >On 3/8/2026 3:29 PM, Bart wrote: >> > >> >> note that setjmp/longjmp are not functions >> > >> > >> >huh? >> > >> >https://man7.org/linux/man-pages/man3/longjmp.3.html >> >> POSIX allows setjmp to be defined as a macro. >> >> https://pubs.opengroup.org/onlinepubs/9799919799/functions/setjmp.html >> > >Just allows? >Are there real-world examples of implementing setjmp not as a macro? > There may have been 33 years ago. From the P1003.4/D14.1 rationale (1993) Section B8.3.1 (Nonlocal jumps): "The C standard specifies various restrictions on the usage of the setjmp() macro in order to permit implementers to recognize the name in the compiler and not implement an actual function. These same restricts apply to the sigsetjmp macro."
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-03-10 15:25 -0700 |
| Message-ID | <87bjgv2ugg.fsf@example.invalid> |
| In reply to | #396883 |
scott@slp53.sl.home (Scott Lurndal) writes:
> DFS <nospam@dfs.com> writes:
>>On 3/8/2026 3:29 PM, Bart wrote:
>>> note that setjmp/longjmp are not functions
>>
>>huh?
>>
>>https://man7.org/linux/man-pages/man3/longjmp.3.html
>
> POSIX allows setjmp to be defined as a macro.
>
> https://pubs.opengroup.org/onlinepubs/9799919799/functions/setjmp.html
More to the point, ISO C (all editions from C90 to C23) specifies that
setjmp is a macro, and longjmp is a function. (Like any library
function, longjmp can *also* be implemented as a macro).
As it happens, glibc's <setjmp.h> has:
#define setjmp(env) _setjmp (env)
where _setjmp is a function.
POSIX says:
It is unspecified whether setjmp() is a macro or a function. If
a macro definition is suppressed in order to access an actual
function, or a program defines an external identifier with the
name setjmp, the behavior is undefined.
which may be inconsistent with ISO C.
--
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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-03-11 07:07 -0700 |
| Message-ID | <868qbya29e.fsf@linuxsc.com> |
| In reply to | #396889 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> scott@slp53.sl.home (Scott Lurndal) writes:
>
>> DFS <nospam@dfs.com> writes:
>>
>>> On 3/8/2026 3:29 PM, Bart wrote:
>>>
>>>> note that setjmp/longjmp are not functions
>>>
>>> huh?
>>>
>>> https://man7.org/linux/man-pages/man3/longjmp.3.html
>>
>> POSIX allows setjmp to be defined as a macro.
>>
>> https://pubs.opengroup.org/onlinepubs/9799919799/functions/setjmp.html
>
> More to the point, ISO C (all editions from C90 to C23) specifies that
> setjmp is a macro, and longjmp is a function. (Like any library
> function, longjmp can *also* be implemented as a macro).
>
> As it happens, glibc's <setjmp.h> has:
>
> #define setjmp(env) _setjmp (env)
>
> where _setjmp is a function.
>
> POSIX says:
>
> It is unspecified whether setjmp() is a macro or a function. If
> a macro definition is suppressed in order to access an actual
> function, or a program defines an external identifier with the
> name setjmp, the behavior is undefined.
>
> which may be inconsistent with ISO C.
The original ANSI C standard says this:
It is unspecified whether setjmp is a macro or an identifier
declared with external linkage. If a macro definition is
suppressed in order to access an actual function, or a program
defines an external identifier with the name setjmp, the
behavior is undefined.
I think every version of the ISO C standard says exactly the same
thing. I did a quick check but didn't verify that the wording is
exactly identical in every case.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-03-11 13:49 -0700 |
| Message-ID | <87zf4e147s.fsf@example.invalid> |
| In reply to | #396902 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>> DFS <nospam@dfs.com> writes:
>>>> On 3/8/2026 3:29 PM, Bart wrote:
>>>>> note that setjmp/longjmp are not functions
>>>>
>>>> huh?
>>>>
>>>> https://man7.org/linux/man-pages/man3/longjmp.3.html
>>>
>>> POSIX allows setjmp to be defined as a macro.
>>>
>>> https://pubs.opengroup.org/onlinepubs/9799919799/functions/setjmp.html
>>
>> More to the point, ISO C (all editions from C90 to C23) specifies that
>> setjmp is a macro, and longjmp is a function. (Like any library
>> function, longjmp can *also* be implemented as a macro).
>>
>> As it happens, glibc's <setjmp.h> has:
>>
>> #define setjmp(env) _setjmp (env)
>>
>> where _setjmp is a function.
>>
>> POSIX says:
>>
>> It is unspecified whether setjmp() is a macro or a function. If
>> a macro definition is suppressed in order to access an actual
>> function, or a program defines an external identifier with the
>> name setjmp, the behavior is undefined.
>>
>> which may be inconsistent with ISO C.
>
> The original ANSI C standard says this:
>
> It is unspecified whether setjmp is a macro or an identifier
> declared with external linkage. If a macro definition is
> suppressed in order to access an actual function, or a program
> defines an external identifier with the name setjmp, the
> behavior is undefined.
>
> I think every version of the ISO C standard says exactly the same
> thing. I did a quick check but didn't verify that the wording is
> exactly identical in every case.
You're right, I missed that. The wording is consistent from ANSI
C89 up to the latest draft of C2y.
The first paragraph says:
The header <setjmp.h> defines the macro setjmp, and declares one
function and one type, for bypassing the normal function call and
return discipline.
C23 adds wording about the __STDC_VERSION_SETJMP_H__ macro.
The third or fourth paragraph says:
It is unspecified whether setjmp is a macro or an identifier
declared with external linkage. If a macro definition is suppressed
to access an actual function, or a program defines an external
identifier with the name setjmp, the behavior is undefined.
Any standard library function may optionally be implemented as a macro.
setjmp is different in that an implementation is allowed to define it
only as a function, only as a macro, or both.
Since the first paragraph clearly *and incorrectly* refers to "the macro
setjmp", I didn't read the rest. I suggest it should say "the macro or
function setjmp".
For this program:
#include <stdio.h>
#include <setjmp.h>
int main(void) {
#ifdef setjmp
puts("setjmp is defined as a macro");
#else
puts("setjmp is not defined");
#endif
return 0;
}
a conforming hosted implementation could print either message.
--
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 | 2026-03-10 20:24 +0000 |
| Message-ID | <10opulu$hpeb$1@dont-email.me> |
| In reply to | #396880 |
On 10/03/2026 01:20, DFS wrote: > On 3/8/2026 3:29 PM, Bart wrote: > >> note that setjmp/longjmp are not functions > > > huh? > > https://man7.org/linux/man-pages/man3/longjmp.3.html > I was wrong, there in func some C libraries that use functions. Such as MSVCRT (but it didn't work when I tried it just now from another language). It might explain why 'setjump' works in such an unintuitive way: not only it is it used to set (implicitly) a recovery point, but that point must be this exact same function call.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-03-10 15:29 -0700 |
| Message-ID | <877brj2u9z.fsf@example.invalid> |
| In reply to | #396888 |
Bart <bc@freeuk.com> writes:
> On 10/03/2026 01:20, DFS wrote:
>> On 3/8/2026 3:29 PM, Bart wrote:
>>> note that setjmp/longjmp are not functions
>> huh?
>> https://man7.org/linux/man-pages/man3/longjmp.3.html
>
> I was wrong, there in func some C libraries that use functions.
You were right about setjmp, which is a macro. You were wrong about
longjmp, which is a function (but like any library function it can
additionally be implemented as a macro.)
> Such as MSVCRT (but it didn't work when I tried it just now from
> another language).
>
> It might explain why 'setjump' works in such an unintuitive way: not
> only it is it used to set (implicitly) a recovery point, but that
> point must be this exact same function call.
I'm not sure how else it could work. I could imagine an alternative
setjmp() that specifies a recovery point other than the call itself,
but you'd need a way to specify that point. (A label wouldn't work,
since setjmp and longjmp work across functions.)
--
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 | 2026-03-11 00:29 +0000 |
| Message-ID | <10oqd0f$mla1$1@dont-email.me> |
| In reply to | #396890 |
On 10/03/2026 22:29, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 10/03/2026 01:20, DFS wrote:
>>> On 3/8/2026 3:29 PM, Bart wrote:
>>>> note that setjmp/longjmp are not functions
>>> huh?
>>> https://man7.org/linux/man-pages/man3/longjmp.3.html
>>
>> I was wrong, there in func some C libraries that use functions.
>
> You were right about setjmp, which is a macro. You were wrong about
> longjmp, which is a function (but like any library function it can
> additionally be implemented as a macro.)
Well, 'setjmp' is exported as a function from MSVCRT. (As I said,
calling setjmp then longjmp crashed while calling the latter, but it
could be for other reasons).
>> Such as MSVCRT (but it didn't work when I tried it just now from
>> another language).
>>
>> It might explain why 'setjump' works in such an unintuitive way: not
>> only it is it used to set (implicitly) a recovery point, but that
>> point must be this exact same function call.
>
> I'm not sure how else it could work. I could imagine an alternative
> setjmp() that specifies a recovery point other than the call itself,
> but you'd need a way to specify that point. (A label wouldn't work,
> since setjmp and longjmp work across functions.)
Yes, the way I emulated setjmp (trying to port Tim's code), used a
version where a label within this function (like a gnu C label pointer)
was a second argument. Doing it otherwise would have needed inline
assembly (and probably hidden behind setjmp as a macro!), which I no
longer have.
But I anyway prefer it like that. Then you don't need to use setjmp in
this peculiar manner:
if (setjmp(buff) == 0 ) // true after first set-up
-- some code that ends up calling longjmp
-- in some nested function
else // here after that longjmp as it
... // magically restarts this 'if'
(The way I do setjmp/longjmp in my C compiler is via dedicated IL
instructions. The same IL is available to my other language, but it
would need language + compiler changes to utilise them.)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-03-11 00:33 +0000 |
| Message-ID | <rL2sR.65147$h8Sf.56533@fx12.iad> |
| In reply to | #396890 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>Bart <bc@freeuk.com> writes:
>> On 10/03/2026 01:20, DFS wrote:
>>> On 3/8/2026 3:29 PM, Bart wrote:
>>>> note that setjmp/longjmp are not functions
>>> huh?
>>> https://man7.org/linux/man-pages/man3/longjmp.3.html
>>
>> I was wrong, there in func some C libraries that use functions.
>
>You were right about setjmp, which is a macro. You were wrong about
>longjmp, which is a function (but like any library function it can
>additionally be implemented as a macro.)
>
>> Such as MSVCRT (but it didn't work when I tried it just now from
>> another language).
>>
>> It might explain why 'setjump' works in such an unintuitive way: not
>> only it is it used to set (implicitly) a recovery point, but that
>> point must be this exact same function call.
>
>I'm not sure how else it could work.
When one realizes that setjmp simply saves the processor user
state at the time of the call (all registers including
the stack pointer and program counter along with the
processor flags) and simply restores that state when longjmp is
invoked, it seems rather intuitive.
longjmp just needs to update the saved processor register that normally
holds a function return value (e.g. %rax) before branching to the
saved PC.
Versions for AMD64:
/**
* Preserve the current register state. This function is only for the use
* of c_rollback.
*
* On entry:
* %rdi c_rollback::_rb_state *
*/
ENTRY(_ZN10c_rollback7_setjmpEPNS_9_rb_stateE)
pop %rsi # Get return address & adjust stack
xorl %eax, %eax # Processor will zero-extend to 64 bits
movq %rbx, (%rdi) # Save RBX register
movq %rsp, 56(%rdi) # Save RSP after return
push %rsi # Restore return address
movq %rbp, 8(%rdi) # Save RBP
movq %r12, 16(%rdi) # Save R12
movq %r13, 24(%rdi) # Save R13
movq %r14, 32(%rdi) # Save R14
movq %r15, 40(%rdi) # Save R15
movq %rsi, 48(%rdi) # Save Return Address
ret
/**
* Restore current register state. This function is only for the use
* of c_rollback.
*
* On entry:
* %rdi c_rollback::_rb_state *
* %rsi uint64
*/
ENTRY(_ZN10c_rollback8_longjmpEPNS_9_rb_stateEm)
movq %rsi, %rax # Return value
movq (%rdi), %rbx # Restore RBX
movq 8(%rdi), %rbp # Restore RBP
movq 16(%rdi), %r12 # Restore R12
movq 24(%rdi), %r13 # Restore R13
movq 32(%rdi), %r14 # Restore R14
movq 40(%rdi), %r15 # Restore R15
movq 56(%rdi), %rsp # Restore RSP
jmp *48(%rdi)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-03-11 11:04 +0000 |
| Message-ID | <10ori72$10uu6$1@dont-email.me> |
| In reply to | #396892 |
On 11/03/2026 00:33, Scott Lurndal wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Bart <bc@freeuk.com> writes:
>>> On 10/03/2026 01:20, DFS wrote:
>>>> On 3/8/2026 3:29 PM, Bart wrote:
>>>>> note that setjmp/longjmp are not functions
>>>> huh?
>>>> https://man7.org/linux/man-pages/man3/longjmp.3.html
>>>
>>> I was wrong, there in func some C libraries that use functions.
>>
>> You were right about setjmp, which is a macro. You were wrong about
>> longjmp, which is a function (but like any library function it can
>> additionally be implemented as a macro.)
>>
>>> Such as MSVCRT (but it didn't work when I tried it just now from
>>> another language).
>>>
>>> It might explain why 'setjump' works in such an unintuitive way: not
>>> only it is it used to set (implicitly) a recovery point, but that
>>> point must be this exact same function call.
>>
>> I'm not sure how else it could work.
>
> When one realizes that setjmp simply saves the processor user
> state at the time of the call (all registers including
> the stack pointer and program counter along with the
> processor flags)
The registers include PC, SP and FP. If 'setjmp' is written in a HLL,
then these are by no means trivial to extract. It depends on the
compiler's entry code for this function.
That applies even if using inline assembly; you'd have to ask for a raw
function where no entry code is generated.
> and simply restores that state when longjmp is
> invoked, it seems rather intuitive.
Not so intuitive when it comes to registers. It can record the state of
non-vol registers when setjmp is called, but those could change by code
executed when setjmp returns the first time.
It would depend on the code around the setjmp call:
int a=1234; // resides in register
...
while() {
switch setjmp() {
case 0: a=5678; ...
case 1: ...
}
Here, how confident can the compiler be that at case 1+, 'a' will always
have the value it had at the very first setjmp call? Maybe it can jump
back to that first ... which is a bunch of conditional statements, which
then calls code that eventually call longjmp.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-03-10 20:18 +0000 |
| Message-ID | <10opuaq$ja1j$2@paganini.bofh.team> |
| In reply to | #396871 |
Bart <bc@freeuk.com> wrote:
>
> I got as far as implementing versions of setjmp/longjmp, which my
> language lacks. But there I stopped: I found it too annoying to just
> slavishly follow the same coding style, and I would probably have
> rewritten half of it.)
People here must be very bored. I have found this challenge rather
uninteresting (bunch of arbitrary restrictions unlikely to happen in
real use). And the "use longjmp" variant is especially silly and
very specific to C: 'longjmp' is an indirect non-local goto so
'no goto' condition normally would mean that 'longjmp' is forbiden too.
And in most languages that can do nonlocal goto-s they are simply
called 'goto'. So this variant makes no sense in such languages.
BTW: I once implemented fibonacci function using explicit stack
and indirect jumps in PL/I under OS/360. But that showed
interesting feature: under OS/360 version using indirect jumps
was faster than version using function calls. I do not think
that version using 'longjmp' has any speed advantage on modern
systems.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-03-12 05:37 -0700 |
| Message-ID | <86a4wd8br1.fsf@linuxsc.com> |
| In reply to | #396887 |
antispam@fricas.org (Waldek Hebisch) writes: >> [...] > > People here must be very bored. I have found this challenge rather > uninteresting (bunch of arbitrary restrictions unlikely to happen in > real use). Different people have different interests. Do you think other people find everything you say interesting? > And the "use longjmp" variant is especially silly and very specific > to C: 'longjmp' is an indirect non-local goto so 'no goto' condition > normally would mean that 'longjmp' is forbiden too. And in most > languages that can do nonlocal goto-s they are simply called 'goto'. > So this variant makes no sense in such languages. Yes, this is comp.lang.c, so it's perfectly appropriate to have a condition specific to C. The prohibition against 'goto' meant specifically C's goto statement, not transfer of control; both 'break' and 'exit()' were allowed, for example. Moreover lonjmp is not at all the same as goto. Even discounting the non-local aspects, longjmp has capabilities that goto doesn't have, and also has restrictions that goto doesn't have. > BTW: I once implemented fibonacci function using explicit stack > and indirect jumps in PL/I under OS/360. But that showed > interesting feature: under OS/360 version using indirect jumps > was faster than version using function calls. I do not think > that version using 'longjmp' has any speed advantage on modern > systems. Performance was never the point of the exercise. Personally I find long discussions of performance minutia rather boring. But I don't jump in just to complain about them.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou@hotmail.com> |
|---|---|
| Date | 2026-03-08 17:57 +0100 |
| Message-ID | <10ok9qb$2fnjg$3@dont-email.me> |
| In reply to | #396865 |
On 08.03.26 16:18, Bart wrote: > On 08/03/2026 14:42, DFS wrote: >> >> Nested ternaries like this: >> >> c = square ? a1 : !hwc ? h*w : a3 > h*w ? h*w : a3; >> >> are harder to decipher at first glance than 3 or 4 levels of indented >> if-then-elses. > > TR doesn't like parentheses around ?: terms; everyone is expected to > know their precedence. Is the (unfamiliar) precedence here really the problem? - I may be already too long used to the "C" operators so that didn't appear as a problem to me. Given that this is basically just a simple if-elif sequence (as opposed to branching cascades) it appears also not per se as a problem (i.e. not from the perspective of the syntax structure). I'm sure that if the conditions were just wrapped to an own line you wouldn't have any problems to follow the control flow even without parenthesis. (And the free space then gained on these lines could be used to use more appropriate identifier names and a comment or two where sensible.) Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-03-08 13:19 -0700 |
| Message-ID | <874imqysza.fsf@example.invalid> |
| In reply to | #396865 |
Bart <bc@freeuk.com> writes:
[...]
> Funny though how TR castigated me for not offering a C solution, but
> his solution is one I would not class as C code, as it only uses a
> subset of the language and in a weird manner (a bit like some of my
> generated C which is not meant to be human-readable).
[...]
Nonsense. Of course Tim's code was C code. It compiles without
error with a conforming C compiler, and does not depend on any
extensions. Practically all C programs only use a subset of the
language.
Classifying C code that you don't like as "not C" is absurd.
Your code, on the other hand, was not written in C at all.
--
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]
Page 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web