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 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
| From | DFS <nospam@dfs.com> |
|---|---|
| Date | 2026-03-04 08:29 -0500 |
| Message-ID | <10o9c3n$2ul3p$1@dont-email.me> |
| In reply to | #396736 |
On 3/3/2026 9:20 AM, Tim Rentsch wrote: > DFS <nospam@dfs.com> writes: > >> On 3/3/2026 12:09 AM, Tim Rentsch wrote: >> >>> DFS <nospam@dfs.com> writes: >>> >>>> On 3/2/2026 3:44 AM, Tim Rentsch wrote: >>>> >>>>> DFS <nospam@dfs.com> writes: >>>>> >>>>> >>>>> A straightfoward exercise. Here is a counter challenge to make >>>>> things more interesting: as above, but don't use nested loops >>>>> (or goto's, etc). >>>> >>>> Done. > > I should have added, I appreciate your taking on the challenge. Absolutely. It was actually interesting to get it done without loops. >> Recursion means the function calls itself. > > What you're describing is called direct recursion. The word > recursion by itself, without the adjective, includes the case > of mutually recursive functions. I see. I didn't realize there were so many types of recursion: direct: tail, head, tree, nested indirect (or mutual), linear, multiple, structural, generative. >> [...] >> >>> The latest challenge, which I just got through doing, is to >>> disallow if, for, while, goto, return, and to forbid functions >>> and function calls except for calls to C standard library >>> functions. >> >> Yikes! >> >> Is main() OK? > > Yes, sorry, not mentioning main() was an oversight on my part. > (Still not okay to call it.) I was actually kidding, but I see online you can do some trickery to make a standalone C program work without main(). Why? Just for s's and giggles? >> How about the use of variables? > > Sure. > >> What written languages are allowed? > > Standard ISO C. Okay not to be strictly conforming. :) > >> nested ternaries? How deep? > > Sure. As deep as you can stand, within reason. My own code > sometimes used ?: at the end of another ?: but not in the middle > (ie, ... ? ... ? ... : ... : ... never appeared). > >>> Also no math library. :) >> >> Using math.h allowed me to easily create a one-line formula. >> But I could probably now do it in 3-4 lines without math.h. > > Yes it isn't hard. > >>> The program is a bit on the long side because of argument >>> processing but the matrix print code is less than 20 lines, >>> including 5 blank lines. >> >> I'll have to bow out for now, but would like to see your latest code. > > My rule is not to post my own code until others have made a good > faith effort on the challenge. >> I note that the no-loops challenge was a worthwhile pursuit I never >> even considered. > > Yes, no loops is fun. Once you get used to it, using tail-recursive > functions in place of loops often seems like a better choice. Yes. for.. and while.. loops are more intuitive (because we likely spent many years using them), but once I got it working without them it felt sort of freeing. I KNEW I'd learn something new on clc. >> I think a recursive function could be really short and sweet, so I'm >> going to try that. > > By all means. The version I first wrote had two tail-recursive > functions, one to find the appropriate number of rows and columns > for a given cutoff, and one to show the matrix of values. I recently thought of a new approach: fill an array with 1 to the cutoff (min(cutoff, rows*cols) anyway), and just print the whole array col by row. Then there's never a need to check each value as you're printing it. For me a for.. loop is easiest to fill an array. but if loops are banned you could do it recursively. but if recursion is banned you could do it?
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-03-04 16:02 +0100 |
| Message-ID | <10o9hj0$2kkfl$1@dont-email.me> |
| In reply to | #396756 |
On 2026-03-04 14:29, DFS wrote: > > for.. and while.. loops are more intuitive (because we likely spent many > years using them), but once I got it working without them it felt sort > of freeing. Yes, it depends on how we learned programming and what we're used. "C" programmers naturally use loops and variables. Bauer/Wössner[1981], for example, wrote a monography _without using loops and variables_ in the first 320 pages; they derived their existence coming from a functional approach with recursive functions. Janis
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-03-04 08:09 -0800 |
| Message-ID | <86ldg7d1a0.fsf@linuxsc.com> |
| In reply to | #396756 |
DFS <nospam@dfs.com> writes: > On 3/3/2026 9:20 AM, Tim Rentsch wrote: > >> DFS <nospam@dfs.com> writes: >> >>> On 3/3/2026 12:09 AM, Tim Rentsch wrote: >>> >>>> DFS <nospam@dfs.com> writes: >>>> >>>>> On 3/2/2026 3:44 AM, Tim Rentsch wrote: >>>>> >>>>>> DFS <nospam@dfs.com> writes: >>>>>> >>>>>> >>>>>> A straightfoward exercise. Here is a counter challenge to make >>>>>> things more interesting: as above, but don't use nested loops >>>>>> (or goto's, etc). >>>>> >>>>> Done. >> >> I should have added, I appreciate your taking on the challenge. > > Absolutely. It was actually interesting to get it done without loops. > >>> Recursion means the function calls itself. >> >> What you're describing is called direct recursion. The word >> recursion by itself, without the adjective, includes the case >> of mutually recursive functions. > > I see. > > I didn't realize there were so many types of recursion: > > direct: tail, head, tree, nested > > indirect (or mutual), linear, multiple, structural, generative. Just a note that a function can be tail recursive without being directly recursive. A tail call is one where the result of the call is the return value of the calling function, regardless of whether the call is recursive, including being indirectly recursive. >>> [...] >>> >>>> The latest challenge, which I just got through doing, is to >>>> disallow if, for, while, goto, return, and to forbid functions >>>> and function calls except for calls to C standard library >>>> functions. >>> >>> Yikes! >>> >>> Is main() OK? >> >> Yes, sorry, not mentioning main() was an oversight on my part. >> (Still not okay to call it.) > > I was actually kidding, but I see online you can do some trickery to > make a standalone C program work without main(). To me that would make the problem outside the realm of C programs, and so subject to a technical out-of-bounds in this newsgroup. I know other people have different stances on this question, I am simply explaining my own view so you know where I'm coming from. >>> [...] >>> >>> I note that the no-loops challenge was a worthwhile pursuit I never >>> even considered. >> >> Yes, no loops is fun. Once you get used to it, using tail-recursive >> functions in place of loops often seems like a better choice. > > Yes. > > for.. and while.. loops are more intuitive (because we likely spent > many years using them), but once I got it working without them it felt > sort of freeing. Like what you say, for() and while() feel more natural because you're more used to them. That will change as you use a functional and/or recursive style more. My own experience with functional programming and writing functions resursively is that at first they seemed somewhat contrived but as I gained experience they felt more natural, and later in many cases a functional/recursive writing seemed easier and more direct. So I urge you to continue pushing forward on this path. >>> I think a recursive function could be really short and sweet, so I'm >>> going to try that. >> >> By all means. The version I first wrote had two tail-recursive >> functions, one to find the appropriate number of rows and columns >> for a given cutoff, and one to show the matrix of values. > > I recently thought of a new approach: fill an array with 1 to the > cutoff (min(cutoff, rows*cols) anyway), and just print the whole array > col by row. Then there's never a need to check each value as you're > printing it. Hmmm. Well I give you points for originality. ;) > For me a for.. loop is easiest to fill an array. > > but if loops are banned you could do it recursively. > > but if recursion is banned you could do it? My hint is there are some powerful functions in the C standard library that make this feasible. If that hint isn't enough, someone else asked a question in this thread (and I responded) that should point you in the right direction. If both of those hints aren't enough, ask again and I'll try to get you closer to the goal.
[toc] | [prev] | [next] | [standalone]
| From | DFS <nospam@dfs.com> |
|---|---|
| Date | 2026-03-06 10:34 -0500 |
| Message-ID | <10oes6q$pas6$1@dont-email.me> |
| In reply to | #396763 |
On 3/4/2026 11:09 AM, Tim Rentsch wrote: > DFS <nospam@dfs.com> writes: > >> I recently thought of a new approach: fill an array with 1 to the >> cutoff (min(cutoff, rows*cols) anyway), and just print the whole array >> col by row. Then there's never a need to check each value as you're >> printing it. > > Hmmm. Well I give you points for originality. ;) I'm sensing sarcasm. I pursued the array approach (a little differently than I described above), but in the end it was useless and a waste of time. example: 4x4 array looked like this: position: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 initial : 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 filled : 1 5 9 13 0 2 6 10 14 0 3 7 11 15 0 4 8 12 16 printed : 1 5 9 13 2 6 10 14 3 7 11 15 4 8 12 16 When you come to a 0 you do newline. Worked great with no cutoffs, but couldn't quite get the printing right when there were cutoff values. And it ended up being about 50% MORE code than my original algorithm. And it used an unnecessary array object. Altogether a fail. > If both of those hints aren't enough, ask again and I'll try to get > you closer to the goal. I'll wait until you post your majestic code. I see Lew Pitcher submitted his - mind-blowing stuff. I compiled and tested, and it seemed to work fine.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-03-06 08:46 -0800 |
| Message-ID | <86a4wkc3dv.fsf@linuxsc.com> |
| In reply to | #396821 |
DFS <nospam@dfs.com> writes: > On 3/4/2026 11:09 AM, Tim Rentsch wrote: > >> DFS <nospam@dfs.com> writes: >> >>> I recently thought of a new approach: fill an array with 1 to the >>> cutoff (min(cutoff, rows*cols) anyway), and just print the whole array >>> col by row. Then there's never a need to check each value as you're >>> printing it. >> >> Hmmm. Well I give you points for originality. ;) > > I'm sensing sarcasm. I wasn't being sarcastic; I do give you points for originality. I leave it to you to decide how much value to ascribe to that. To be frank I didn't quite understand what you were suggesting. I was waiting for you to post some code so I could see what you meant. > I pursued the array approach (a little differently than I described > above), but in the end it was useless and a waste of time. > > example: 4x4 array looked like this: > > position: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 > initial : 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > filled : 1 5 9 13 0 2 6 10 14 0 3 7 11 15 0 4 8 12 16 > printed : > 1 5 9 13 > 2 6 10 14 > 3 7 11 15 > 4 8 12 16 > > When you come to a 0 you do newline. > > Worked great with no cutoffs, but couldn't quite get the printing > right when there were cutoff values. And it ended up being about 50% > MORE code than my original algorithm. And it used an unnecessary > array object. > > Altogether a fail. Exploring a new method, even if unsuccessful, still has value. >> If both of those hints aren't enough, ask again and I'll try to get >> you closer to the goal. > > I'll wait until you post your majestic code. I'm still hoping you will post an attempt first, especially now that you have seen Lew Pitcher's response. If you tell me where you are stuck I can try to give a suitable hint to get you over the hump.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-03-04 11:25 -0800 |
| Message-ID | <87o6l3jt2m.fsf@example.invalid> |
| In reply to | #396756 |
DFS <nospam@dfs.com> writes:
> On 3/3/2026 9:20 AM, Tim Rentsch wrote:
>> DFS <nospam@dfs.com> writes:
>>> Is main() OK?
>> Yes, sorry, not mentioning main() was an oversight on my part.
>> (Still not okay to call it.)
>
> I was actually kidding, but I see online you can do some trickery to
> make a standalone C program work without main().
>
> Why? Just for s's and giggles?
[...]
I'm curious what you're referring to. It's not possible to have a
working *portable* C program (for a hosted implementation) without
a main function. There might be some compiler-specific tricks for
using or specifying an entry point with a different name.
For freestanding implementations, the name and type of the entry
point are implementation-defined, and portability goes out the
window.
--
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 | DFS <nospam@dfs.com> |
|---|---|
| Date | 2026-03-05 13:46 -0500 |
| Message-ID | <10ocj2e$1ke5$1@dont-email.me> |
| In reply to | #396767 |
On 3/4/2026 2:25 PM, Keith Thompson wrote: > DFS <nospam@dfs.com> writes: >> On 3/3/2026 9:20 AM, Tim Rentsch wrote: >>> DFS <nospam@dfs.com> writes: >>>> Is main() OK? >>> Yes, sorry, not mentioning main() was an oversight on my part. >>> (Still not okay to call it.) >> >> I was actually kidding, but I see online you can do some trickery to >> make a standalone C program work without main(). >> >> Why? Just for s's and giggles? > [...] > > I'm curious what you're referring to. It's not possible to have a > working *portable* C program (for a hosted implementation) without > a main function. There might be some compiler-specific tricks for > using or specifying an entry point with a different name. Correct, per Google AI Overview (for "c program without main function") "While the C standard requires a main() function for programs running in a standard "hosted" environment, it is technically possible to create an executable program without explicitly defining main() using non-standard, implementation-specific methods. These methods often fall into two main categories: 1. Using Preprocessor Directives (Macros) 2. Modifying the Entry Point (Linker Options)" Rentsch's motivation seems to be doing something way outside the box. All will be revealed when he releases his double-secret code.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-03-05 21:34 +0100 |
| Message-ID | <10ocpct$3ups$1@dont-email.me> |
| In reply to | #396785 |
On 05/03/2026 19:46, DFS wrote: > On 3/4/2026 2:25 PM, Keith Thompson wrote: >> DFS <nospam@dfs.com> writes: >>> On 3/3/2026 9:20 AM, Tim Rentsch wrote: >>>> DFS <nospam@dfs.com> writes: >>>>> Is main() OK? >>>> Yes, sorry, not mentioning main() was an oversight on my part. >>>> (Still not okay to call it.) >>> >>> I was actually kidding, but I see online you can do some trickery to >>> make a standalone C program work without main(). >>> >>> Why? Just for s's and giggles? >> [...] >> >> I'm curious what you're referring to. It's not possible to have a >> working *portable* C program (for a hosted implementation) without >> a main function. There might be some compiler-specific tricks for >> using or specifying an entry point with a different name. > > > Correct, per Google AI Overview (for "c program without main function") > > "While the C standard requires a main() function for programs running in > a standard "hosted" environment, it is technically possible to create an > executable program without explicitly defining main() using non- > standard, implementation-specific methods. > > These methods often fall into two main categories: > 1. Using Preprocessor Directives (Macros) > 2. Modifying the Entry Point (Linker Options)" > There are more imaginative ways to get a program without a "main" function (all of which are non-portable). You can use a gcc "alias" attribute to make "main" an alias for your "real_main" function. You could make your "main" a data object, containing the opcodes for "jmp real_main". You could use a gcc "constructor" alias to have "real_main" run before main(), and have "main" simply be a symbol in the linker or C file. You could replace the C startup code that runs before main, and have it call "real_main" instead. There may be other ways - that's just off the top of my head. > > Rentsch's motivation seems to be doing something way outside the box. > > All will be revealed when he releases his double-secret code. > /If/ he reveals it. And /if/ he reveals it this year, rather than months after everyone has forgotten the thread.
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2026-03-05 19:09 +0000 |
| Message-ID | <10ockdh$3qpk6$1@dont-email.me> |
| In reply to | #396733 |
On Mon, 02 Mar 2026 21:09:21 -0800, Tim Rentsch wrote: [snip] > The latest challenge, which I just got through doing, is to > disallow if, for, while, goto, return, and to forbid functions > and function calls except for calls to C standard library > functions. Also no math library. :) Inventive, aren't you :-) I've got a working matrix print that (I think) satisfies your requirements, but have not started on the argument processing logic yet. I may, yet again, revise my approach, as the solution I'm using is quite tedious to code. > The program is a bit on the long side because of argument > processing but the matrix print code is less than 20 lines, > including 5 blank lines. 20 lines, including 4 blank lines, but I can reduce it a bit. I should be able to match (or at least approximate) your line count. -- Lew Pitcher "In Skills We Trust" Not LLM output - I'm just like this.
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2026-03-05 21:12 +0000 |
| Message-ID | <10ocrjn$3qpk6$2@dont-email.me> |
| In reply to | #396789 |
On Thu, 05 Mar 2026 19:09:37 +0000, Lew Pitcher wrote: > On Mon, 02 Mar 2026 21:09:21 -0800, Tim Rentsch wrote: > [snip] >> The latest challenge, which I just got through doing, is to >> disallow if, for, while, goto, return, and to forbid functions >> and function calls except for calls to C standard library >> functions. Also no math library. :) > > Inventive, aren't you :-) > > I've got a working matrix print that (I think) satisfies your > requirements, but have not started on the argument processing > logic yet. I may, yet again, revise my approach, as the solution > I'm using is quite tedious to code. OK, so the "no if statements" is a bit of a bother, but not insurmountable. It's just a case of switching things around. And, perhaps there's a third option as well. As I said, the alternatives are just tedious to code. But, I now need to find a replacement for sqrt() that doesn't take a lot of space. Back to first principles for me, then. >> The program is a bit on the long side because of argument >> processing but the matrix print code is less than 20 lines, >> including 5 blank lines. > > 20 lines, including 4 blank lines, but I can reduce it a bit. > I should be able to match (or at least approximate) your line > count. -- Lew Pitcher "In Skills We Trust" Not LLM output - I'm just like this.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-03-05 14:12 -0800 |
| Message-ID | <86zf4mapto.fsf@linuxsc.com> |
| In reply to | #396795 |
Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes: > On Thu, 05 Mar 2026 19:09:37 +0000, Lew Pitcher wrote: > >> On Mon, 02 Mar 2026 21:09:21 -0800, Tim Rentsch wrote: >> [snip] >> >>> The latest challenge, which I just got through doing, is to >>> disallow if, for, while, goto, return, and to forbid functions >>> and function calls except for calls to C standard library >>> functions. Also no math library. :) >> >> Inventive, aren't you :-) >> >> I've got a working matrix print that (I think) satisfies your >> requirements, but have not started on the argument processing >> logic yet. I may, yet again, revise my approach, as the solution >> I'm using is quite tedious to code. > > OK, so the "no if statements" is a bit of a bother, but not > insurmountable. It's just a case of switching things around. > And, perhaps there's a third option as well. > > As I said, the alternatives are just tedious to code. I did manage to find some tricks to make things simpler, but probably the most important is ?: is your friend. > But, I now need to find a replacement for sqrt() that doesn't take > a lot of space. Back to first principles for me, then. There is an easy way to do this, if not especially elegant: start a counter at 0 and count it up until counter*counter >= cutoff. Then there is a straightword arithmetic test to see if counter is good or bad.
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2026-03-05 22:24 +0000 |
| Message-ID | <10ocvrk$3qpk6$3@dont-email.me> |
| In reply to | #396799 |
On Thu, 05 Mar 2026 14:12:19 -0800, Tim Rentsch wrote: > Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes: > >> On Thu, 05 Mar 2026 19:09:37 +0000, Lew Pitcher wrote: >> >>> On Mon, 02 Mar 2026 21:09:21 -0800, Tim Rentsch wrote: >>> [snip] >>> >>>> The latest challenge, which I just got through doing, is to >>>> disallow if, for, while, goto, return, and to forbid functions >>>> and function calls except for calls to C standard library >>>> functions. Also no math library. :) >>> >>> Inventive, aren't you :-) >>> >>> I've got a working matrix print that (I think) satisfies your >>> requirements, but have not started on the argument processing >>> logic yet. I may, yet again, revise my approach, as the solution >>> I'm using is quite tedious to code. >> >> OK, so the "no if statements" is a bit of a bother, but not >> insurmountable. It's just a case of switching things around. >> And, perhaps there's a third option as well. >> >> As I said, the alternatives are just tedious to code. > > I did manage to find some tricks to make things simpler, but > probably the most important is ?: is your friend. that, and switch()/case, which is a nice substitute for if () statements with complex bodies, or if () / else statements. >> But, I now need to find a replacement for sqrt() that doesn't take >> a lot of space. Back to first principles for me, then. > > There is an easy way to do this, if not especially elegant: start a > counter at 0 and count it up until counter*counter >= cutoff. Then > there is a straightword arithmetic test to see if counter is good or > bad. I was playing with the Heron's method of approximation, but was getting anomalous numbers when coded to the restrictions of the challenge. I don't mind burning cycles, and might go for the straightforward way, but I'm still thinking on it -- Lew Pitcher "In Skills We Trust" Not LLM output - I'm just like this.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-03-06 01:00 +0200 |
| Message-ID | <20260306010016.0000729e@yahoo.com> |
| In reply to | #396800 |
On Thu, 5 Mar 2026 22:24:53 -0000 (UTC) Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote: > On Thu, 05 Mar 2026 14:12:19 -0800, Tim Rentsch wrote: > > > Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes: > > > >> On Thu, 05 Mar 2026 19:09:37 +0000, Lew Pitcher wrote: > >> > >>> On Mon, 02 Mar 2026 21:09:21 -0800, Tim Rentsch wrote: > >>> [snip] > >>> > >>>> The latest challenge, which I just got through doing, is to > >>>> disallow if, for, while, goto, return, and to forbid functions > >>>> and function calls except for calls to C standard library > >>>> functions. Also no math library. :) > >>> > >>> Inventive, aren't you :-) > >>> > >>> I've got a working matrix print that (I think) satisfies your > >>> requirements, but have not started on the argument processing > >>> logic yet. I may, yet again, revise my approach, as the solution > >>> I'm using is quite tedious to code. > >> > >> OK, so the "no if statements" is a bit of a bother, but not > >> insurmountable. It's just a case of switching things around. > >> And, perhaps there's a third option as well. > >> > >> As I said, the alternatives are just tedious to code. > > > > I did manage to find some tricks to make things simpler, but > > probably the most important is ?: is your friend. > > that, and switch()/case, which is a nice substitute for if () > statements with complex bodies, or if () / else statements. > My impression was that switch is omitted from the list of disallowed constructs by mistake. > >> But, I now need to find a replacement for sqrt() that doesn't take > >> a lot of space. Back to first principles for me, then. > > > > There is an easy way to do this, if not especially elegant: start a > > counter at 0 and count it up until counter*counter >= cutoff. Then > > there is a straightword arithmetic test to see if counter is good or > > bad. > > I was playing with the Heron's method of approximation, but was > getting anomalous numbers when coded to the restrictions of the > challenge. > > I don't mind burning cycles, and might go for the straightforward > way, but I'm still thinking on it >
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-03-05 15:08 -0800 |
| Message-ID | <86qzpxc1su.fsf@linuxsc.com> |
| In reply to | #396801 |
Michael S <already5chosen@yahoo.com> writes: > On Thu, 5 Mar 2026 22:24:53 -0000 (UTC) > Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote: > >> On Thu, 05 Mar 2026 14:12:19 -0800, Tim Rentsch wrote: >> >>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes: >>> >>>> On Thu, 05 Mar 2026 19:09:37 +0000, Lew Pitcher wrote: >>>> >>>>> On Mon, 02 Mar 2026 21:09:21 -0800, Tim Rentsch wrote: >>>>> [snip] >>>>> >>>>>> The latest challenge, which I just got through doing, is to >>>>>> disallow if, for, while, goto, return, and to forbid functions >>>>>> and function calls except for calls to C standard library >>>>>> functions. Also no math library. :) >>>>> >>>>> Inventive, aren't you :-) >>>>> >>>>> I've got a working matrix print that (I think) satisfies your >>>>> requirements, but have not started on the argument processing >>>>> logic yet. I may, yet again, revise my approach, as the solution >>>>> I'm using is quite tedious to code. >>>> >>>> OK, so the "no if statements" is a bit of a bother, but not >>>> insurmountable. It's just a case of switching things around. >>>> And, perhaps there's a third option as well. >>>> >>>> As I said, the alternatives are just tedious to code. >>> >>> I did manage to find some tricks to make things simpler, but >>> probably the most important is ?: is your friend. >> >> that, and switch()/case, which is a nice substitute for if () >> statements with complex bodies, or if () / else statements. > > My impression was that switch is omitted from the list of disallowed > constructs by mistake. Definitely not. Use of switch() is allowed (and 'case' also).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-03-05 15:05 -0800 |
| Message-ID | <86v7f9c1y2.fsf@linuxsc.com> |
| In reply to | #396800 |
Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes: > On Thu, 05 Mar 2026 14:12:19 -0800, Tim Rentsch wrote: > >> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes: >> >>> On Thu, 05 Mar 2026 19:09:37 +0000, Lew Pitcher wrote: >>> >>>> On Mon, 02 Mar 2026 21:09:21 -0800, Tim Rentsch wrote: >>>> [snip] >>>> >>>>> The latest challenge, which I just got through doing, is to >>>>> disallow if, for, while, goto, return, and to forbid functions >>>>> and function calls except for calls to C standard library >>>>> functions. Also no math library. :) >>>> >>>> Inventive, aren't you :-) >>>> >>>> I've got a working matrix print that (I think) satisfies your >>>> requirements, but have not started on the argument processing >>>> logic yet. I may, yet again, revise my approach, as the solution >>>> I'm using is quite tedious to code. >>> >>> OK, so the "no if statements" is a bit of a bother, but not >>> insurmountable. It's just a case of switching things around. >>> And, perhaps there's a third option as well. >>> >>> As I said, the alternatives are just tedious to code. >> >> I did manage to find some tricks to make things simpler, but >> probably the most important is ?: is your friend. > > that, and switch()/case, which is a nice substitute for if () statements > with complex bodies, or if () / else statements. > >>> But, I now need to find a replacement for sqrt() that doesn't take >>> a lot of space. Back to first principles for me, then. >> >> There is an easy way to do this, if not especially elegant: start a >> counter at 0 and count it up until counter*counter >= cutoff. Then >> there is a straightword arithmetic test to see if counter is good or >> bad. > > I was playing with the Heron's method of approximation, but was > getting anomalous numbers when coded to the restrictions of the > challenge. > > I don't mind burning cycles, and might go for the straightforward > way, but I'm still thinking on it The simple counter method is what I first coded. Then I did a binary search. The binary search is kind of clunky in a "no for() or while()" environment, so I figured out a way to use Newton-Raphson iteration. A little bit tricky to get right, but after wrestling with it I managed to get a fairly nice formulation.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou@hotmail.com> |
|---|---|
| Date | 2026-03-06 00:18 +0100 |
| Message-ID | <10od30j$79v9$1@dont-email.me> |
| In reply to | #396795 |
On 05.03.26 22:12, Lew Pitcher wrote:
> On Thu, 05 Mar 2026 19:09:37 +0000, Lew Pitcher wrote:
[...]
>
> But, I now need to find a replacement for sqrt() that doesn't take
> a lot of space. Back to first principles for me, then.
The roguelike game Nethack that historically deliberately didn't
use any floating point had this code (most is just comments):
/* integer square root function without using floating point */
int
isqrt(val)
int val;
{
int rt = 0;
int odd = 1;
/*
* This could be replaced by a faster algorithm, but has not been
because:
* + the simple algorithm is easy to read;
* + this algorithm does not require 64-bit support;
* + in current usage, the values passed to isqrt() are not really that
* large, so the performance difference is negligible;
* + isqrt() is used in only few places, which are not bottle-necks.
*/
while (val >= odd) {
val = val - odd;
odd = odd + 2;
rt = rt + 1;
}
return rt;
}
Janis
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-03-07 22:04 +0200 |
| Message-ID | <20260307220446.000077d9@yahoo.com> |
| In reply to | #396804 |
On Fri, 6 Mar 2026 00:18:43 +0100
Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
> On 05.03.26 22:12, Lew Pitcher wrote:
> > On Thu, 05 Mar 2026 19:09:37 +0000, Lew Pitcher wrote:
> [...]
> >
> > But, I now need to find a replacement for sqrt() that doesn't take
> > a lot of space. Back to first principles for me, then.
>
> The roguelike game Nethack that historically deliberately didn't
> use any floating point had this code (most is just comments):
>
> /* integer square root function without using floating point */
> int
> isqrt(val)
> int val;
> {
> int rt = 0;
> int odd = 1;
> /*
> * This could be replaced by a faster algorithm, but has not
> been because:
> * + the simple algorithm is easy to read;
> * + this algorithm does not require 64-bit support;
> * + in current usage, the values passed to isqrt() are not
> really that
> * large, so the performance difference is negligible;
> * + isqrt() is used in only few places, which are not
> bottle-necks. */
> while (val >= odd) {
> val = val - odd;
> odd = odd + 2;
> rt = rt + 1;
> }
> return rt;
> }
>
>
> Janis
>
That code is O(sqrt(val)). Good enough in this particular case, because
main print loop is much slower than that at O(val), but I find it
non-satisfactory.
Here is O(log(N)) variant that is even simpler than code above.
unsigned usqrt(unsigned x)
{
if (x < 2)
return x;
unsigned y = x/2, r;
while ((r = x / y) < y)
y = (r + y) / 2;
return y;
}
And here is variation that is a little less simple, but not complicated
and faster than one before, because it does fewer divisions.
The number of divisions that can't be implemented as shift is at most
ceil(sqrt(ceil(log2(ceil(sqrt(val)))
unsigned usqrt(unsigned x)
{
if (x < 2)
return x;
unsigned y = 8, xx = x;
while (xx > 63) {
xx /= 64;
y *= 8;
}
unsigned r;
while ((r = x / y) < y)
y = (r + y) / 2;
return y;
}
And here is less simple but still obvious implementation that does no
divisions at all. No multiplications as well.
unsigned usqrt(unsigned x)
{
if (x < 2)
return x;
unsigned xx = x;
int e = 0;
while (xx > 63) {
xx /= 64;
e += 3;
}
while (xx > 3) {
xx /= 4;
e += 1;
}
unsigned y = 1u << e;
x -= y << e;
for (e = e - 1; e >= 0; --e) {
unsigned d = y*2 + (1u << e);
if (d <= (x >> e)) {
x -= d << e;
y += 1u << e;
}
}
return y;
}
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou@hotmail.com> |
|---|---|
| Date | 2026-03-08 00:26 +0100 |
| Message-ID | <10oic6n$1u9aa$1@dont-email.me> |
| In reply to | #396852 |
On 07.03.26 21:04, Michael S wrote:
> On Fri, 6 Mar 2026 00:18:43 +0100
> Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
>
>> On 05.03.26 22:12, Lew Pitcher wrote:
>>> On Thu, 05 Mar 2026 19:09:37 +0000, Lew Pitcher wrote:
>> [...]
>>>
>>> But, I now need to find a replacement for sqrt() that doesn't take
>>> a lot of space. Back to first principles for me, then.
>>
>> The roguelike game Nethack that historically deliberately didn't
>> use any floating point had this code (most is just comments):
>>
>> /* integer square root function without using floating point */
>> int
>> isqrt(val)
>> int val;
>> {
>> int rt = 0;
>> int odd = 1;
>> /*
>> * This could be replaced by a faster algorithm, but has not
>> been because:
>> * + the simple algorithm is easy to read;
>> * + this algorithm does not require 64-bit support;
>> * + in current usage, the values passed to isqrt() are not
>> really that
>> * large, so the performance difference is negligible;
>> * + isqrt() is used in only few places, which are not
>> bottle-necks. */
>> while (val >= odd) {
>> val = val - odd;
>> odd = odd + 2;
>> rt = rt + 1;
>> }
>> return rt;
>> }
>>
>>
>> Janis
>>
>
> That code is O(sqrt(val)). Good enough in this particular case, because
> main print loop is much slower than that at O(val), but I find it
> non-satisfactory.
I have no stakes here. If it were my code I'd have at least simplified
it with the trivial 2-address replacements { val-=odd; odd+=2; rt++; }
that I consider clearer ("simpler") without muddying the simplicity of
the underlying expressions.
>
> Here is O(log(N)) variant that is even simpler than code above.
Not sure what you mean by "simpler". Personally I perceive below code
less "simple" with the less trivial expressions and stuffing of the
assignment into the while-loop condition. It's a nice case of applied
code tweaking anyway.
And in other application cases certainly worth any performance gains.
(I haven't yet closely inspected the code but I probably will do.)
I'm a bit astonished by the last variants, though, with its constants
(63 and 64); this is something that looks like a variant specifically
tailored to some system architecture. But okay, I see that you might
want to "cluster" the arithmetics.
I like especially the attempts to reduce arithmetic divisions (given
that the original Nethack code didn't have these in the first place).
Janis
>
> unsigned usqrt(unsigned x)
> {
> if (x < 2)
> return x;
> unsigned y = x/2, r;
> while ((r = x / y) < y)
> y = (r + y) / 2;
> return y;
> }
>
> And here is variation that is a little less simple, but not complicated
> and faster than one before, because it does fewer divisions.
> The number of divisions that can't be implemented as shift is at most
> ceil(sqrt(ceil(log2(ceil(sqrt(val)))
>
> unsigned usqrt(unsigned x)
> {
> if (x < 2)
> return x;
> unsigned y = 8, xx = x;
> while (xx > 63) {
> xx /= 64;
> y *= 8;
> }
> unsigned r;
> while ((r = x / y) < y)
> y = (r + y) / 2;
> return y;
> }
>
> And here is less simple but still obvious implementation that does no
> divisions at all. No multiplications as well.
>
> unsigned usqrt(unsigned x)
> {
> if (x < 2)
> return x;
> unsigned xx = x;
> int e = 0;
> while (xx > 63) {
> xx /= 64;
> e += 3;
> }
> while (xx > 3) {
> xx /= 4;
> e += 1;
> }
> unsigned y = 1u << e;
> x -= y << e;
> for (e = e - 1; e >= 0; --e) {
> unsigned d = y*2 + (1u << e);
> if (d <= (x >> e)) {
> x -= d << e;
> y += 1u << e;
> }
> }
> return y;
> }
>
>
>
>
>
>
>
>
>
>
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-03-08 02:45 +0200 |
| Message-ID | <20260308024533.00004a5d@yahoo.com> |
| In reply to | #396857 |
On Sun, 8 Mar 2026 00:26:15 +0100 Janis Papanagnou <janis_papanagnou@hotmail.com> wrote: > > I'm a bit astonished by the last variants, though, with its constants > (63 and 64); this is something that looks like a variant specifically > tailored to some system architecture. But okay, I see that you might > want to "cluster" the arithmetics. > Quite opposite to what you say - in the spirit of comp.lang.c this part of code uses most generic of relatively fast methods of calculation of non-precise value of floor(log2(x)/2) when expected result is in range [0:15]. The expected range is [0:15] because 32 bits is the most popular size of 'unsigned' type. Using bigger threshold number (4**4-1==255) will on average increase a # of more expensive iterations in the next loop. Using smaller number (15 or 3) will increase # of iteration in this loop. If it was tailored I'd avoid this loop completely and instead will use language extension, like __bultin_clz() on gcc and compatible or _BitScanReverse() on MSVC and compatible C23 has standard way to express it - stdc_leading_zeros(). But C23 is not yet accepted as de-facto C Standard of comp.lang.c and rightfully so.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou@hotmail.com> |
|---|---|
| Date | 2026-03-08 17:05 +0100 |
| Message-ID | <10ok6nf$2fnjg$1@dont-email.me> |
| In reply to | #396861 |
On 08.03.26 01:45, Michael S wrote:
> On Sun, 8 Mar 2026 00:26:15 +0100
> Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
>
>>
>> I'm a bit astonished by the last variants, though, with its constants
>> (63 and 64); this is something that looks like a variant specifically
>> tailored to some system architecture. But okay, I see that you might
>> want to "cluster" the arithmetics.
>>
>
> Quite opposite to what you say
Oh, rally? - What you write below ("most popular size") sounds not
like a focus on the algorithm but on concrete (typical) systems.
Don't get me wrong; I think it's fine to do that for concrete
implementations.
What you suggested looks like a sort of "clustering", as I said.
I did that myself in the past for an arbitrary precision modulus
operator; I could have worked on universal octet sizes but chose
to assume at least 32 byte arithmetic available to speed up the
process. Given contemporary architectures I could increase that
further, I could tailor it to 64 bit entities for another speed
factor of 2 (in cases where we'd need every nanosecond). Nowadays
I'd probably inquire the available "register sizes" per program
logic (or at compile time) and use optimally tailored sizes where
it matters. Personally I prefer avoiding such hard-coded constants.
> - in the spirit of comp.lang.c this
> part of code uses most generic of relatively fast methods of
> calculation of non-precise value of floor(log2(x)/2) when expected
> result is in range [0:15].
> The expected range is [0:15] because 32 bits is the most popular size
> of 'unsigned' type.
> Using bigger threshold number (4**4-1==255) will on average increase
> a # of more expensive iterations in the next loop.
> Using smaller number (15 or 3) will increase # of iteration in this
> loop.
>
> If it was tailored I'd avoid this loop completely and instead will use
> language extension, like __bultin_clz() on gcc and compatible or
> _BitScanReverse() on MSVC and compatible
(If you had read "tailored" as a vendor specific tailoring using
proprietary features you misunderstood what I said. - Nevermind.)
Janis
>
> C23 has standard way to express it - stdc_leading_zeros(). But C23 is
> not yet accepted as de-facto C Standard of comp.lang.c and rightfully
> so.
>
>
[toc] | [prev] | [next] | [standalone]
Page 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web