Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #399062 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2026-05-17 00:03 +0200 |
| Last post | 2026-05-27 01:05 +0000 |
| Articles | 20 on this page of 248 — 20 participants |
Back to article view | Back to comp.lang.c
switch/extension for see below strongly needed fir <profesor.fir@gmail.com> - 2026-05-17 00:03 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-17 01:08 +0100
Re: switch/extension for see below strongly needed Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-16 18:21 -0700
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-17 12:16 +0100
Re: switch/extension for see below strongly needed fir <profesor.fir@gmail.com> - 2026-05-17 15:04 +0200
Re: switch/extension for see below strongly needed fir <profesor.fir@gmail.com> - 2026-05-17 15:08 +0200
Re: switch/extension for see below strongly needed Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-17 06:48 -0700
Re: switch/extension for see below strongly needed Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-05-17 14:43 +0000
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-17 16:53 +0100
Re: switch/extension for see below strongly needed fir <profesor.fir@gmail.com> - 2026-05-17 18:24 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-17 17:56 +0100
Re: switch/extension for see below strongly needed fir <profesor.fir@gmail.com> - 2026-05-17 21:07 +0200
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-18 08:56 +0200
Re: switch/extension for see below strongly needed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-18 09:22 +0200
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-18 10:35 +0200
Re: switch/extension for see below strongly needed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-18 10:41 +0200
Re: switch/extension for see below strongly needed antispam@fricas.org (Waldek Hebisch) - 2026-05-18 16:47 +0000
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-18 18:58 +0200
Using "extra" blocks to declare local variables (Was: switch/extension for see below strongly needed) gazelle@shell.xmission.com (Kenny McCormack) - 2026-05-19 05:48 +0000
Re: Using "extra" blocks to declare local variables (Was: switch/extension for see below strongly needed) David Brown <david.brown@hesbynett.no> - 2026-05-19 08:18 +0200
Re: Using "extra" blocks to declare local variables (Was: switch/extension for see below strongly needed) scott@slp53.sl.home (Scott Lurndal) - 2026-05-19 14:04 +0000
Re: Using "extra" blocks to declare local variables (Was: switch/extension for see below strongly needed) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-22 23:44 -0700
Re: switch/extension for see below strongly needed cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-18 18:13 +0000
Re: switch/extension for see below strongly needed scott@slp53.sl.home (Scott Lurndal) - 2026-05-18 18:37 +0000
You are not allowed to use "the S word" in this ng. (Was: switch/extension for see below strongly needed) gazelle@shell.xmission.com (Kenny McCormack) - 2026-05-19 05:49 +0000
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-18 18:35 +0100
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-18 21:24 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-18 21:48 +0100
Re: switch/extension for see below strongly needed Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 17:00 -0700
Re: switch/extension for see below strongly needed Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-18 14:23 -0700
Re: switch/extension for see below strongly needed Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-19 06:58 +0000
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-19 11:55 +0100
Re: switch/extension for see below strongly needed Richard Harnden <richard.nospam@gmail.invalid> - 2026-05-19 12:15 +0100
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-19 12:48 +0100
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-19 14:23 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-19 14:08 +0100
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-19 15:40 +0200
Re: switch/extension for see below strongly needed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-19 16:41 +0200
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-19 17:07 +0200
Re: switch/extension for see below strongly needed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-19 17:23 +0200
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-19 17:58 +0200
Re: switch/extension for see below strongly needed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-19 18:31 +0200
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-19 18:38 +0200
Re: switch/extension for see below strongly needed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-19 18:54 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-19 17:44 +0100
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-19 18:59 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-19 17:31 +0100
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-19 18:48 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-19 18:47 +0100
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-19 21:58 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-19 22:16 +0100
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-20 08:59 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-20 14:20 +0100
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-20 16:22 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-20 16:41 +0100
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-20 19:51 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-20 21:14 +0100
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-21 08:45 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-21 12:56 +0100
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-21 14:55 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-21 18:26 +0100
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-21 21:23 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-21 20:59 +0100
Re: switch/extension for see below strongly needed cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-21 21:35 +0000
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-22 09:31 +0200
Re: switch/extension for see below strongly needed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-22 06:52 +0200
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-22 09:34 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-22 11:43 +0100
Re: switch/extension for see below strongly needed cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-22 12:13 +0000
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-22 14:16 +0100
Re: switch/extension for see below strongly needed cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-22 17:32 +0000
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-22 20:27 +0100
Re: switch/extension for see below strongly needed cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-23 15:30 +0000
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-23 17:59 +0100
Re: switch/extension for see below strongly needed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-23 07:56 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-22 11:41 +0100
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-22 13:31 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-22 13:42 +0100
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-22 15:11 +0200
Re: switch/extension for see below strongly needed cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-22 14:57 +0000
Re: switch/extension for see below strongly needed scott@slp53.sl.home (Scott Lurndal) - 2026-05-22 16:16 +0000
Re: switch/extension for see below strongly needed cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-22 17:43 +0000
Re: switch/extension for see below strongly needed scott@slp53.sl.home (Scott Lurndal) - 2026-05-22 21:03 +0000
Re: switch/extension for see below strongly needed cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-22 22:02 +0000
Re: switch/extension for see below strongly needed Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-25 07:39 -0700
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-22 17:53 +0100
Re: switch/extension for see below strongly needed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-23 07:51 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-23 10:58 +0100
Re: switch/extension for see below strongly needed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-23 07:33 +0200
Re: switch/extension for see below strongly needed cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-24 02:48 +0000
Re: switch/extension for see below strongly needed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-24 10:13 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-24 12:30 +0100
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-24 13:39 +0100
Re: switch/extension for see below strongly needed tTh <tth@none.invalid> - 2026-05-24 22:09 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-24 21:48 +0100
Re: switch/extension for see below strongly needed scott@slp53.sl.home (Scott Lurndal) - 2026-05-24 22:04 +0000
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-25 10:34 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-22 11:45 +0100
Re: switch/extension for see below strongly needed dave_thompson_2@comcast.net - 2026-06-06 19:00 -0400
Re: switch/extension for see below strongly needed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-21 15:08 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-21 14:31 +0100
Re: switch/extension for see below strongly needed Michael S <already5chosen@yahoo.com> - 2026-05-21 19:37 +0300
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-21 18:38 +0100
Re: switch/extension for see below strongly needed James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-21 13:54 -0400
Re: switch/extension for see below strongly needed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-21 20:09 +0200
Re: switch/extension for see below strongly needed Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-21 14:31 -0700
Re: switch/extension for see below strongly needed James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-21 19:41 -0400
Re: switch/extension for see below strongly needed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-22 05:23 +0200
Re: switch/extension for see below strongly needed Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-22 21:38 -0700
Re: switch/extension for see below strongly needed Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-22 23:17 -0700
Re: switch/extension for see below strongly needed Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-23 00:04 -0700
Re: switch/extension for see below strongly needed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-23 09:35 +0200
Re: switch/extension for see below strongly needed Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-23 03:59 -0700
Re: switch/extension for see below strongly needed James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-21 13:48 -0400
Re: switch/extension for see below strongly needed Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-21 14:23 -0700
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-21 23:47 +0100
Re: switch/extension for see below strongly needed Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-21 17:24 -0700
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-22 01:51 +0100
Re: switch/extension for see below strongly needed scott@slp53.sl.home (Scott Lurndal) - 2026-05-22 14:04 +0000
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-22 16:16 +0100
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-22 17:47 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-22 17:35 +0100
Re: switch/extension for see below strongly needed scott@slp53.sl.home (Scott Lurndal) - 2026-05-22 20:57 +0000
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-23 00:24 +0100
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-23 11:46 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-23 11:31 +0100
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-23 13:51 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-23 13:07 +0100
Re: switch/extension for see below strongly needed fir <profesor.fir@gmail.com> - 2026-05-23 14:35 +0200
Re: switch/extension for see below strongly needed fir <profesor.fir@gmail.com> - 2026-05-23 14:38 +0200
Re: switch/extension for see below strongly needed Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-23 20:46 -0700
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-23 13:55 +0100
Re: switch/extension for see below strongly needed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-22 05:58 +0200
Re: switch/extension for see below strongly needed Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-21 21:21 -0700
Re: switch/extension for see below strongly needed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-22 07:17 +0200
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-22 10:49 +0200
Re: switch/extension for see below strongly needed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-23 05:49 +0200
Re: switch/extension for see below strongly needed James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-22 18:37 -0400
Re: switch/extension for see below strongly needed James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-21 19:49 -0400
Re: switch/extension for see below strongly needed Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-21 17:27 -0700
Re: switch/extension for see below strongly needed Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-23 14:21 -0700
Re: switch/extension for see below strongly needed Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-23 20:32 -0700
Re: switch/extension for see below strongly needed Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-23 14:19 -0700
Re: switch/extension for see below strongly needed Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-23 14:03 -0700
Re: switch/extension for see below strongly needed "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-20 16:39 -0700
Re: switch/extension for see below strongly needed cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-20 15:18 +0000
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-20 17:38 +0200
Re: switch/extension for see below strongly needed cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-20 18:17 +0000
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-21 09:56 +0200
Re: switch/extension for see below strongly needed cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-21 12:18 +0000
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-21 15:16 +0200
Re: switch/extension for see below strongly needed cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-22 14:44 +0000
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-22 17:12 +0200
Re: switch/extension for see below strongly needed cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-24 19:08 +0000
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-25 12:16 +0200
Re: switch/extension for see below strongly needed cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-26 14:09 +0000
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-26 18:16 +0200
Re: switch/extension for see below strongly needed Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-04 07:19 -0700
Re: switch/extension for see below strongly needed cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 17:18 +0000
Re: switch/extension for see below strongly needed Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 08:45 -0700
Re: switch/extension for see below strongly needed scott@slp53.sl.home (Scott Lurndal) - 2026-05-21 15:04 +0000
Re: switch/extension for see below strongly needed "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-20 16:47 -0700
Re: switch/extension for see below strongly needed cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-21 02:55 +0000
Re: switch/extension for see below strongly needed Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-23 21:12 -0700
Re: switch/extension for see below strongly needed Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-23 21:31 -0700
Re: switch/extension for see below strongly needed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-24 11:00 +0200
Re: switch/extension for see below strongly needed Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-24 04:15 -0700
Re: switch/extension for see below strongly needed James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-20 10:40 -0400
Re: switch/extension for see below strongly needed "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-20 16:52 -0700
Re: switch/extension for see below strongly needed cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-20 14:56 +0000
Re: switch/extension for see below strongly needed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-20 06:38 +0200
Re: switch/extension for see below strongly needed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-21 02:45 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-21 02:31 +0100
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-21 10:16 +0200
[OT] Genie bug and fix (was Re: switch/extension for see below strongly needed) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-22 04:48 +0200
Re: [OT] Genie bug and fix (was Re: switch/extension for see below strongly needed) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-22 05:02 +0200
Re: [OT] Genie bug and fix (was Re: switch/extension for see below strongly needed) Bart <bc@freeuk.com> - 2026-05-22 11:18 +0100
Re: [OT] Genie bug and fix (was Re: switch/extension for see below strongly needed) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-23 09:21 +0200
Re: switch/extension for see below strongly needed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-20 06:24 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-20 11:55 +0100
Re: switch/extension for see below strongly needed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-21 02:30 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-21 02:21 +0100
Re: switch/extension for see below strongly needed Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-20 18:51 -0700
Re: switch/extension for see below strongly needed gazelle@shell.xmission.com (Kenny McCormack) - 2026-05-21 11:46 +0000
Re: switch/extension for see below strongly needed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-21 14:56 +0200
Re: switch/extension for see below strongly needed scott@slp53.sl.home (Scott Lurndal) - 2026-05-21 15:12 +0000
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-21 16:47 +0100
Re: switch/extension for see below strongly needed Michael S <already5chosen@yahoo.com> - 2026-05-21 19:27 +0300
Re: switch/extension for see below strongly needed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-21 20:03 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-21 19:42 +0100
Re: switch/extension for see below strongly needed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-21 19:46 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-21 20:08 +0100
Re: switch/extension for see below strongly needed "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-19 14:34 -0700
Re: switch/extension for see below strongly needed Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-19 15:01 -0700
Re: switch/extension for see below strongly needed "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-19 15:15 -0700
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-20 09:24 +0200
Re: switch/extension for see below strongly needed Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-20 03:26 -0700
Re: switch/extension for see below strongly needed dave_thompson_2@comcast.net - 2026-06-06 17:55 -0400
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-19 13:29 +0200
Re: switch/extension for see below strongly needed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-19 16:46 +0200
Re: switch/extension for see below strongly needed scott@slp53.sl.home (Scott Lurndal) - 2026-05-19 13:56 +0000
Re: switch/extension for see below strongly needed Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-19 14:27 -0700
Re: switch/extension for see below strongly needed James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-19 12:35 -0400
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-18 11:57 +0100
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-18 13:57 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-18 14:18 +0100
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-18 16:07 +0200
Re: switch/extension for see below strongly needed Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-18 14:12 -0700
Re: switch/extension for see below strongly needed Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-18 07:17 +0000
Re: switch/extension for see below strongly needed Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-17 23:30 +0000
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-18 09:02 +0200
Re: switch/extension for see below strongly needed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-18 09:38 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-18 10:50 +0100
Re: switch/extension for see below strongly needed fir <profesor.fir@gmail.com> - 2026-05-18 10:00 +0200
Re: switch/extension for see below strongly needed "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-18 16:31 -0700
Re: switch/extension for see below strongly needed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-19 09:18 +0200
Re: switch/extension for see below strongly needed David Brown <david.brown@hesbynett.no> - 2026-05-19 10:00 +0200
Re: switch/extension for see below strongly needed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-19 10:34 +0200
Re: switch/extension for see below strongly needed "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-19 14:19 -0700
Re: switch/extension for see below strongly needed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-20 04:09 +0200
Re: switch/extension for see below strongly needed James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-19 11:43 -0400
Re: switch/extension for see below strongly needed cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-18 01:22 +0000
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-18 11:23 +0100
Re: switch/extension for see below strongly needed cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-18 11:07 +0000
Re: switch/extension for see below strongly needed fir <profesor.fir@gmail.com> - 2026-05-18 14:10 +0200
Re: switch/extension for see below strongly needed fir <profesor.fir@gmail.com> - 2026-05-18 15:01 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-18 14:33 +0100
Re: switch/extension for see below strongly needed fir <profesor.fir@gmail.com> - 2026-05-18 16:39 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-18 16:12 +0100
Re: switch/extension for see below strongly needed fir <profesor.fir@gmail.com> - 2026-05-18 17:35 +0200
Re: switch/extension for see below strongly needed fir <profesor.fir@gmail.com> - 2026-05-18 16:59 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-18 16:25 +0100
Re: switch/extension for see below strongly needed fir <profesor.fir@gmail.com> - 2026-05-18 17:50 +0200
Re: switch/extension for see below strongly needed fir <profesor.fir@gmail.com> - 2026-05-18 18:21 +0200
Re: switch/extension for see below strongly needed fir <profesor.fir@gmail.com> - 2026-05-18 17:29 +0200
Re: switch/extension for see below strongly needed fir <profesor.fir@gmail.com> - 2026-05-18 17:04 +0200
Re: switch/extension for see below strongly needed Bart <bc@freeuk.com> - 2026-05-18 16:31 +0100
Re: switch/extension for see below strongly needed fir <profesor.fir@gmail.com> - 2026-05-18 18:12 +0200
Re: switch/extension for see below strongly needed fir <profesor.fir@gmail.com> - 2026-05-18 18:24 +0200
Re: switch/extension for see below strongly needed Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-18 14:40 -0700
Re: switch/extension for see below strongly needed fir <profesor.fir@gmail.com> - 2026-05-17 14:57 +0200
Re: switch/extension for see below strongly needed fir <profesor.fir@gmail.com> - 2026-05-17 16:06 +0200
Re: multipass Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-17 05:50 +0000
Re: multipass Bart <bc@freeuk.com> - 2026-05-17 11:26 +0100
Re: multipass David Brown <david.brown@hesbynett.no> - 2026-05-18 09:08 +0200
Re: multipass Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-17 17:31 +0200
Re: multipass makendo <makendo@makendo.invalid> - 2026-05-24 01:14 +0800
Re: multipass Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-27 01:05 +0000
Page 9 of 13 — ← Prev page 1 … 7 8 [9] 10 11 … 13 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-05-21 15:04 +0000 |
| Message-ID | <paFPR.9635$MQ1.2513@fx37.iad> |
| In reply to | #399244 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
>Similarly, the RAII idiom prevalent in C++ and Rust uses object
>destructors that are automatically run when something goes out
>of scope to do the cleanup. C++ pairs that with
>exceptions (arguably worse than goto) while Rust represents
>errors with sum types and a little bit of syntactic sugar with
>the `?` operator. In either case, the descriptors run and do
>the cleanup, regardless of whether the return was an error path
>or a success path.
We used this in 1990 when implementing a fork() function in
an unix-compatible distributed operating system (although it
wasn't known formally as RAII in those days).
int
tProc::Fork(KnCap* PActUI, int Caller, tLwp *CrLwp, int IsVFork, boolean_t ForkAll)
{
int Error = 0;
int nlwp; // total number of active lwps in the child
int total_lwp; // total number of lwps in the child (active + zombies)
ASSERT((Caller == FORK_SYSCALL) || (Caller == FORK_BOOTPROC));
KnCap *ChildCap = Actor.GetCap();
// Hand crafted processes do not have a ParentP.
tProc *ParentP = CrLwp->MyProc();
// Initialise the global Ops event that is used for global Ops
// synchronisation
EVENT_INIT(&GlobalEvt);
//
// Only Single threaded processes can vfork().
// Currently, we don't support vfork.
if (IsVFork && (!(ParentP->LwpList.SingleThreaded()))) {
return EINVAL;
}
if (ForkAll) {
nlwp = ParentP->LwpList.GetCountLwp();
total_lwp = ParentP->LwpList.GetTotalLwp();
} else {
nlwp = 1;
total_lwp = 1;
}
//
// Check to see if we will be exceeding the quota.
// XXXKYS: Check the interface for picking up quota tokens.
// Would prefer an interface that accepted the number of
// tokens needed - proc + lwps.
// NOTE: The number of LWP tokens picked up will be equal to the
// total number of LWPs in the child (including zombie LWPs).
if (UidQuota.Fork(ProcCred->GetUid(), ProcCred->GetEuid(), total_lwp)) {
return EAGAIN;
}
tForkFailure ff(this, CrLwp, ChildCap, nlwp, total_lwp);
.
.
.
}
=== The tForkfailure class encapsulated the resources allocated
to the thread. The fork function could return at any time
after this and the destructor for tForkFailure would clean up
any allocated resources.
//
// Destructor: undo what fork has done upon failure.
//
tForkFailure::~tForkFailure()
{
if (ret == 0) {
return;
}
if (PActUI != NULL) {
procp->Mem.Exit(ChildCap);
}
//
// XXXKYS: the DeleteAll() needs to take
// into account that some of the LWPs
// in the list may be zombies.
//
procp->LwpList.DeleteAll();
if (rgn == B_TRUE) {
procp->Rgn.ShmExit(CrLwp, procp);
}
if (semundo == B_TRUE) {
procp->Undo.SemUnFork();
}
if (file == B_TRUE) {
procp->File.ForkUndo();
}
procp->ProcRlim->rlFree(nlwp + 1);
procp->ProcCred->CrFree(nlwp + 1);
procp->UidQuota.FreeProc(B_TRUE, total_lwp, 1);
}
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-05-20 16:47 -0700 |
| Message-ID | <10ulh7g$coh9$1@dont-email.me> |
| In reply to | #399218 |
On 5/20/2026 8:18 AM, Dan Cross wrote: > In article <10ujm3r$3pnbb$1@dont-email.me>, > David Brown <david.brown@hesbynett.no> wrote: >> [snip] I have almost never had need of "goto" or labels (excluding >> switch case labels, of course), and don't expect ever to do so in the >> future. > > While I generally try to avoid it, there are times (in C in > particular) when it really is the right tool; the inventors of C > understood that. From the Plan 9 `fortunes` file: "If you want > to go somewhere, goto is the best way to get there. K Thompson" Oh shit. Side note. Did you ever hear about a nasty race condition in Plan 9 wrt some lock-free thing, or even a mutex acquisition? The Plan9 problem. I remember conversing about with with Alex Terekhov way back in comp.programming.threads. [...]
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-21 02:55 +0000 |
| Message-ID | <10uls6p$fni$1@reader1.panix.com> |
| In reply to | #399229 |
In article <10ulh7g$coh9$1@dont-email.me>, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >On 5/20/2026 8:18 AM, Dan Cross wrote: >> In article <10ujm3r$3pnbb$1@dont-email.me>, >> David Brown <david.brown@hesbynett.no> wrote: >>> [snip] I have almost never had need of "goto" or labels (excluding >>> switch case labels, of course), and don't expect ever to do so in the >>> future. >> >> While I generally try to avoid it, there are times (in C in >> particular) when it really is the right tool; the inventors of C >> understood that. From the Plan 9 `fortunes` file: "If you want >> to go somewhere, goto is the best way to get there. K Thompson" > >Oh shit. Side note. Did you ever hear about a nasty race condition in >Plan 9 wrt some lock-free thing, or even a mutex acquisition? The Plan9 >problem. I remember conversing about with with Alex Terekhov way back in >comp.programming.threads. > >[...] Yes. There were issues discovered with multiprocessor sleep and wakeup on x86 during the early Pentium Pro days, due to a misunderstanding of the memory model. Russ Cox has a summary write-up here: https://swtch.com/spin/ I have no idea who Alex Terekhov is. This has very, very little to do with C. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-05-23 21:12 -0700 |
| Message-ID | <86ldd9fnt8.fsf@linuxsc.com> |
| In reply to | #399218 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
> In article <10ujm3r$3pnbb$1@dont-email.me>,
> David Brown <david.brown@hesbynett.no> wrote:
>
>> [snip] I have almost never had need of "goto" or labels (excluding
>> switch case labels, of course), and don't expect ever to do so in the
>> future.
>
> While I generally try to avoid it, there are times (in C in
> particular) when it really is the right tool; [...]
Yes.
> Breaking out of nested loops without a lot of unnecessary
> ceremony is sort of an obvious example; [...]
Another scenario where using goto can be attractive is when
so-called "loop and a half" processing is needed. Something
like this
goto ENTRY;
do {
....
ENTRY:
....
} while( ..condition.. );
is in many cases more attractive than goto-less alternatives.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-05-23 21:31 -0700 |
| Message-ID | <86h5nxfmxx.fsf@linuxsc.com> |
| In reply to | #399383 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>
>> In article <10ujm3r$3pnbb$1@dont-email.me>,
>> David Brown <david.brown@hesbynett.no> wrote:
>>
>>> [snip] I have almost never had need of "goto" or labels (excluding
>>> switch case labels, of course), and don't expect ever to do so in the
>>> future.
>>
>> While I generally try to avoid it, there are times (in C in
>> particular) when it really is the right tool; [...]
>
> Yes.
>
>> Breaking out of nested loops without a lot of unnecessary
>> ceremony is sort of an obvious example; [...]
>
> Another scenario where using goto can be attractive is when
> so-called "loop and a half" processing is needed. Something
> like this
>
> goto ENTRY;
> do {
> ....
> ENTRY:
> ....
> } while( ..condition.. );
>
> is in many cases more attractive than goto-less alternatives.
I should add that, even though there are these and some other
well-known counterexamples, IME occasions where goto is needed
are exceedinly rare; under 0.02%, say. My heuristic is, when
considering possibly using a goto, write two or three versions
without using goto; then, only if a goto version is better than
all the others should goto be used.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-24 11:00 +0200 |
| Message-ID | <10uuemt$1s757$5@dont-email.me> |
| In reply to | #399383 |
On 2026-05-24 06:12, Tim Rentsch wrote:
>> [...]
>
> Another scenario where using goto can be attractive is when
> so-called "loop and a half" processing is needed. Something
> like this
>
> goto ENTRY;
> do {
> ....
> ENTRY:
> ....
> } while( ..condition.. );
>
> is in many cases more attractive than goto-less alternatives.
Yes, a (low-level) code-pattern that works well in "C".
May there be issues if you have declarations in the loop?
Other languages forbid that to not encounter inherent
problems when trying to enter inner scopes. - Just noting.
I think in "C" I'd prefer instead of
goto entry; do { A; entry: B; } while (condition);
for several reasons rather
while (1) { B; if (!condition) break; A; }
despite of the additional outer true-condition.
Janis
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-05-24 04:15 -0700 |
| Message-ID | <86cxylf497.fsf@linuxsc.com> |
| In reply to | #399383 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>
>> In article <10ujm3r$3pnbb$1@dont-email.me>,
>> David Brown <david.brown@hesbynett.no> wrote:
>>
>>> [snip] I have almost never had need of "goto" or labels (excluding
>>> switch case labels, of course), and don't expect ever to do so in the
>>> future.
>>
>> While I generally try to avoid it, there are times (in C in
>> particular) when it really is the right tool; [...]
>
> Yes.
>
>> Breaking out of nested loops without a lot of unnecessary
>> ceremony is sort of an obvious example; [...]
>
> Another scenario where using goto can be attractive is when
> so-called "loop and a half" processing is needed. Something
> like this
>
> goto ENTRY;
> do {
> ....
> ENTRY:
> ....
> } while( ..condition.. );
>
> is in many cases more attractive than goto-less alternatives.
Another log on the goto fire...
The code below is a transcription of Algorithm A in section 6.2.3
of Knuth TAOCP, for insertion into an AVL tree. It uses the same
variable names as in the original, except not capitalized.
I think it's fair to call this algorithm a candidate poster child
for showing abuse of goto. Ick.
It makes a good challenge problem: provide a more comprehensible
re-write, especially with respect to reducing use of goto.
#include <assert.h>
#include <stdlib.h>
typedef struct tree_node_s *Tree;
typedef signed int Key;
typedef signed int Balance;
struct tree_node_s {
Tree left, right;
Key key;
Balance b;
};
void
avl_insert( Tree head, Key k ){
Tree t, s, p, q, r;
Balance a;
A1:
t = head, s = p = head->right;
/* fall through */
A2:
if( k < p->key ) goto A3;
if( k > p->key ) goto A4;
return;
A3:
q = p->left;
if( !q ){
p->left = q = malloc( sizeof *q );
goto A5;
}
if( q->b != 0 ) t = p, s = q;
p = q;
goto A2;
A4:
q = p->right;
if( !q ){
p->right = q = malloc( sizeof *q );
goto A5;
}
if( q->b != 0 ) t = p, s = q;
p = q;
goto A2;
A5:
q->left = q->right = 0, q->key = k, q->b = 0;
/* fall through */
A6:
if( k < s->key ) r = p = s->left;
else r = p = s->right;
while( p != q ){
if( k < p->key ) p->b = -1, p = p->left;
else p->b = +1, p = p->right;
}
/* fall through */
A7:
if( k < s->key ) a = -1;
else a = +1;
if( s->b == 0 ){
s->b = a;
return;
}
if( s->b == -a ){
s->b = 0;
return;
}
if( s->b == a ){
if( r->b == a ) goto A8;
if( r->b == -a ) goto A9;
assert( 0 );
}
assert( 0 );
A8:
p = r;
if( a == 1 ) s->right = r->left, r->left = s;
else s->left = r->right, r->right = s;
s->b = r->b = 0;
goto A10;
A9:
if( a == 1 ){
p = r->right;
r->right = p->left, p->left = r;
s->left = p->right, p->right = s;
} else {
p = r->left;
r->left = p->right, p->right = r;
s->right = p->left, p->left = s;
}
if( p->b == a ) s->b = -a, r->b = 0;
if( p->b == 0 ) s->b = 0, r->b = 0;
if( p->b == -a ) s->b = 0, r->b = -a;
p->b = 0;
/* fall through */
A10:
if( s == t->right ) t->right = p;
else t->left = p;
}
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-05-20 10:40 -0400 |
| Message-ID | <10ukh4b$u23$1@dont-email.me> |
| In reply to | #399186 |
On 19/05/2026 23:16, Bart wrote: > On 19/05/2026 20:58, David Brown wrote: >> On 19/05/2026 19:47, Bart wrote: ... > Implementing C's three namespaces doesn't require knowing why they > exist, only that they do. "namespaces" are a C++ feature, which means something quite different from "name spaces". Both C and C++ have name spaces. C++ has only three: labels, macros, and ordinary identifiers. However, C has 4 name spaces and an unlimited number of members of each of two families of name spaces: 1. Label Names 2. Struct, union, and enumeration tags 3. Each struct or uninon has a namespace for it's members 4. Standard attributes and attribute specifiers 5. Each attribute prefix has a namespace for it's trailing identifiers 6. All other identifiers. The reason for the different name spaces is primarily syntactic. Each name space has different syntax for defining and using the corresponding identifiers, so you can never be unclear about which name space an identifier should be from. Label names are declared by following them with ":" at the start of a logical line in block scope, and are used only in a goto statement. Neither of those are locations where any of the other kinds of identifiers are legal. Similarly, in C, tags are always immediately preceded by one of the "struct", "union" or "enum" keywords, something that cannot be done with any other kind of identifier. They can occur without those keywords in C++, which is why C++ doesn't have a separate name space for them. Struct and union member names can only appear in struct or union identifiers or as the right operand of member selection operators for and expression of the type of the struct or union they are members of. No other types of identifiers can appear in those locations. Attributes can only be used inside of [[]], and trailing identifiers can only occur immediately after the corresponding attribute. Again, no other identifiers can occur in those locations. >> who has implemented a C compiler.) ... > I'm not sure why you say I'm claiming to have written one; you don't > believe me? OK. As far as I can tell, C doesn't have any feature too simple for you to misunderstand it. It's hard to believe that you have correctly implemented C despite having such an awful understand of what it takes to correctly implement it. In particular, your claim that C has only three name spaces argues against you having correctly implemented that fact in your C compiler. C's attributes are a relatively new feature, and I could imagine that you haven't bothered implementing that feature. However, the other four items in that list go all the way back to the first C standard, one of which is an unlimited family of name spaces. Possibly you have correctly handled all of the name spaces correctly, despite not realizing that they are called name spaces, just because each name space other than the ordinary identifiers name space has it's own unique syntax in which it is relevant.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-05-20 16:52 -0700 |
| Message-ID | <10ulhf6$crnp$1@dont-email.me> |
| In reply to | #399216 |
On 5/20/2026 7:40 AM, James Kuyper wrote: > On 19/05/2026 23:16, Bart wrote: >> On 19/05/2026 20:58, David Brown wrote: >>> On 19/05/2026 19:47, Bart wrote: > ... >> Implementing C's three namespaces doesn't require knowing why they >> exist, only that they do. > > "namespaces" are a C++ feature, which means something quite different > from "name spaces". Both C and C++ have name spaces. C++ has only three: > labels, macros, and ordinary identifiers. However, C has 4 name spaces > and an unlimited number of members of each of two families of name spaces: [...] Namespaces in C: ct_vector_field_*** (namespace)_(feature)_(drill-down)_*** ? ;^D
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-20 14:56 +0000 |
| Message-ID | <10uki2o$hvr$1@reader1.panix.com> |
| In reply to | #399186 |
In article <10uijv9$3i6dl$1@dont-email.me>, Bart <bc@freeuk.com> wrote: >On 19/05/2026 20:58, David Brown wrote: >> On 19/05/2026 19:47, Bart wrote: > >>> (I still don't know why C has a separate namespace for labels.) >> >> There's a lot you don't know about C. > >It sounds like you don't know either. It's fine not to know everything about something. I doubt anyone posting here regularly knows *every* detail of C. The difference is being able to admit that it's ok to consult a reference before loudly proclaiming how much something about C sucks. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-20 06:38 +0200 |
| Message-ID | <10ujdsu$jvhi$13@dont-email.me> |
| In reply to | #399178 |
On 2026-05-19 18:48, David Brown wrote: > On 19/05/2026 18:31, Bart wrote: >> [...] > > OK. So there was a real language that worked that way, half a century ago. It's not that clear, IMO; all I see in his post is the result of a specific tool he uses, and for a specific case (not for variables). (See my recent post a few minutes ago for the details.) BTW, that language still _works_ (not "worked"). - Whether with the detail of behavior Bart showed, or more sensibly defined, as we'd expect it to be for a thoroughly designed language like Algol 68. (I wouldn't talk too pejorative about that language. There's a high quality and actively maintained interpreter (a68g), and there's the actual GNU project to add Algol 68 support to their compiler suite, the 'ga68' tool. - I haven't checked the latter; it appears to me to be still work in progress and unfinished. - That the user community is small is hardly a sensible valuation of its language concepts.) Janis
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-21 02:45 +0200 |
| Message-ID | <10ulkji$k0ug$9@dont-email.me> |
| In reply to | #399200 |
On 2026-05-20 06:38, Janis Papanagnou wrote: > On 2026-05-19 18:48, David Brown wrote: >> On 19/05/2026 18:31, Bart wrote: >>> [...] >> >> OK. So there was a real language that worked that way, half a century >> ago. > > It's not that clear, IMO; all I see in his post is the result of a > specific tool he uses, and for a specific case (not for variables). > (See my recent post a few minutes ago for the details.) David, the answer of my emailed question arrived; the behavior of the Genie interpreter in case of identity relations is just a bug! (Bart wrongly assumed and without evidence from the standard that the Algol 68 language would support his claim.) Algol 68 is a well designed language and the scope rules are as we expect sensibly chosen; entities are valid within the block scope and their "existence", when you can use them, starts with their declaration (not before). Most people don't know Algol 68. I suggest to take Bart's opinions on that language with the same reservations as his opinions about the "C" language. He's widely ignorant and unwilling to understand the facts. Take his statements with a grain of salt - and, if in doubt, better just ignore him. Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-21 02:31 +0100 |
| Message-ID | <10uln9q$dikl$2@dont-email.me> |
| In reply to | #399232 |
On 21/05/2026 01:45, Janis Papanagnou wrote:
> On 2026-05-20 06:38, Janis Papanagnou wrote:
>> On 2026-05-19 18:48, David Brown wrote:
>>> On 19/05/2026 18:31, Bart wrote:
>>>> [...]
>>>
>>> OK. So there was a real language that worked that way, half a
>>> century ago.
>>
>> It's not that clear, IMO; all I see in his post is the result of a
>> specific tool he uses, and for a specific case (not for variables).
>> (See my recent post a few minutes ago for the details.)
>
> David, the answer of my emailed question arrived; the behavior of
> the Genie interpreter in case of identity relations is just a bug!
>
> (Bart wrongly assumed and without evidence from the standard that
> the Algol 68 language would support his claim.)
>
> Algol 68 is a well designed language and the scope rules are as we
> expect sensibly chosen; entities are valid within the block scope
> and their "existence", when you can use them, starts with their
> declaration (not before).
So why does this work:
fred(9999);
PROC fred = (INT n)VOID: print((n, newline));
print("end")
Another bug?
> Most people don't know Algol 68. I suggest to take Bart's opinions
> on that language with the same reservations as his opinions about
> the "C" language. He's widely ignorant and unwilling to understand
> the facts. Take his statements with a grain of salt - and, if in
> doubt, better just ignore him.
Oh, of course. The fact that A68G has existed for 25 years with this
'bug' that nobody has detected or bothered to check for is perfectly fine.
I guess you're going to get the credit for finding this bug rather than me!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-21 10:16 +0200 |
| Message-ID | <10umf0r$hnml$2@dont-email.me> |
| In reply to | #399232 |
On 21/05/2026 02:45, Janis Papanagnou wrote: > On 2026-05-20 06:38, Janis Papanagnou wrote: >> On 2026-05-19 18:48, David Brown wrote: >>> On 19/05/2026 18:31, Bart wrote: >>>> [...] >>> >>> OK. So there was a real language that worked that way, half a >>> century ago. >> >> It's not that clear, IMO; all I see in his post is the result of a >> specific tool he uses, and for a specific case (not for variables). >> (See my recent post a few minutes ago for the details.) > > David, the answer of my emailed question arrived; the behavior of > the Genie interpreter in case of identity relations is just a bug! > > (Bart wrongly assumed and without evidence from the standard that > the Algol 68 language would support his claim.) > > Algol 68 is a well designed language and the scope rules are as we > expect sensibly chosen; entities are valid within the block scope > and their "existence", when you can use them, starts with their > declaration (not before). > > Most people don't know Algol 68. I suggest to take Bart's opinions > on that language with the same reservations as his opinions about > the "C" language. He's widely ignorant and unwilling to understand > the facts. Take his statements with a grain of salt - and, if in > doubt, better just ignore him. > > Janis > OK. I know very little about Algol 68, and don't have the interest to bother checking such details myself. Your description makes sense to me, both of the way the language is intended to work, and that there is an oddity or bug in a particular implementation. "It makes sense to me" is, of course, not a particularly strong argument. But I don't think it is worth going into more detail here in c.l.c. Bart does have a tendency to mix up "this is how the language is designed" and "this is what a particular implementation does". With his own languages, that's fine - there is only one implementation, and only a rough description of the language, so the two coincide. It is also how pre-standardisation languages tend to work. But it is not how C works, nor, as I understand it, how Algol68 works.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-22 04:48 +0200 |
| Subject | [OT] Genie bug and fix (was Re: switch/extension for see below strongly needed) |
| Message-ID | <10uog6b$jvhi$18@dont-email.me> |
| In reply to | #399241 |
On 2026-05-21 10:16, David Brown wrote:
> On 21/05/2026 02:45, Janis Papanagnou wrote:
>>> [...]
>> David, the answer of my emailed question arrived; the behavior of
>> the Genie interpreter in case of identity relations is just a bug!
>> [...]
>> Algol 68 is a well designed language and the scope rules are as we
>> expect sensibly chosen; entities are valid within the block scope
>> and their "existence", when you can use them, starts with their
>> declaration (not before).
>> [...]
>
> OK. I know very little about Algol 68, and don't have the interest to
> bother checking such details myself. Your description makes sense to
> me, both of the way the language is intended to work, and that there is
> an oddity or bug in a particular implementation. "It makes sense to me"
> is, of course, not a particularly strong argument. But I don't think it
> is worth going into more detail here in c.l.c.
>
> Bart does have a tendency to mix up "this is how the language is
> designed" and "this is what a particular implementation does". With his
> own languages, that's fine - there is only one implementation, and only
> a rough description of the language, so the two coincide. It is also
> how pre-standardisation languages tend to work. But it is not how C
> works, nor, as I understand it, how Algol68 works.
Short update on that (for those interested); my question I recently
sent to Marcel about Genie's behavior made him not only explain that
it's a bug, but he also immediately fixed it. - The current Genie
release 3.12.2 (published a few hours ago) now reports:
a68g: runtime error: 1: attempt to use an uninitialised INT value,
in [] "SIMPLOUT" collateral-clause starting at "(" in this line.
Janis
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-22 05:02 +0200 |
| Subject | Re: [OT] Genie bug and fix (was Re: switch/extension for see below strongly needed) |
| Message-ID | <10uoh0a$k0ug$12@dont-email.me> |
| In reply to | #399288 |
On 2026-05-22 04:48, Janis Papanagnou wrote:
> On 2026-05-21 10:16, David Brown wrote:
>> [...]
>
> Short update on that (for those interested); my question I recently
> sent to Marcel about Genie's behavior made him not only explain that
> it's a bug, but he also immediately fixed it. - The current Genie
> release 3.12.2 (published a few hours ago) now reports:
>
> a68g: runtime error: 1: attempt to use an uninitialised INT value,
> in [] "SIMPLOUT" collateral-clause starting at "(" in this line.
BTW, thanks to Bart for (inadvertently!) detecting a bug in Genie.
While his statement had been only an uninformed attempt to support
an inappropriate claim of him he contributed to a fix that way. :-)
>
> Janis
>
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-22 11:18 +0100 |
| Subject | Re: [OT] Genie bug and fix (was Re: switch/extension for see below strongly needed) |
| Message-ID | <10upahg$1croh$1@dont-email.me> |
| In reply to | #399288 |
On 22/05/2026 03:48, Janis Papanagnou wrote:
> On 2026-05-21 10:16, David Brown wrote:
>> On 21/05/2026 02:45, Janis Papanagnou wrote:
>>>> [...]
>>> David, the answer of my emailed question arrived; the behavior of
>>> the Genie interpreter in case of identity relations is just a bug!
>>> [...]
>>> Algol 68 is a well designed language and the scope rules are as we
>>> expect sensibly chosen; entities are valid within the block scope
>>> and their "existence", when you can use them, starts with their
>>> declaration (not before).
>>> [...]
>>
>> OK. I know very little about Algol 68, and don't have the interest to
>> bother checking such details myself. Your description makes sense to
>> me, both of the way the language is intended to work, and that there
>> is an oddity or bug in a particular implementation. "It makes sense
>> to me" is, of course, not a particularly strong argument. But I don't
>> think it is worth going into more detail here in c.l.c.
>>
>> Bart does have a tendency to mix up "this is how the language is
>> designed" and "this is what a particular implementation does". With
>> his own languages, that's fine - there is only one implementation, and
>> only a rough description of the language, so the two coincide. It is
>> also how pre-standardisation languages tend to work. But it is not
>> how C works, nor, as I understand it, how Algol68 works.
>
> Short update on that (for those interested); my question I recently
> sent to Marcel about Genie's behavior made him not only explain that
> it's a bug, but he also immediately fixed it. - The current Genie
> release 3.12.2 (published a few hours ago) now reports:
>
> a68g: runtime error: 1: attempt to use an uninitialised INT value,
> in [] "SIMPLOUT" collateral-clause starting at "(" in this line.
Thanks, now we get can some definite answers. If I try this program:
INT a=1234;
PROC fred = (INT n)INT:
BEGIN
print((a, newline));
INT a=777;
print((a, newline));
a
END;
INT x;
x:=fred(23);
print(x)
Then the older A68G showed +0 +777 +777. The new one reports an error on
that first print.
If I change 'a=' to 'a:=', then both report an attempt to use an
uninitialised REF INT value.
If I remove that nested declaration of 'a', then both show +1234 +1234
+1234.
So what has been fixed is that an attempt to use an uninitialised INT
value (when using '=' rather than ':=') is now reported.
But unfortunately it does look in that case as though the scope of the
second 'a' does run from the preceding BEGIN. It's just there's no way
to practically make use of it there (I tried a few ways).
A similar thing happens in Python, but there you can use the earlier 'a'
legally if you void using the the uninitialised version:
a=1
def F():
i=0
for j in range(2):
if i:
print ("Ai",a)
a=2
print ("Aii",a)
i=1
F()
print(a)
(The absence of 'global a' inside the function, and the assignment to
'a', I believe makes 'a' a local, whose scope is function-wide.)
There was something else: you said this:
> entities are valid within the block scope
> and their "existence", when you can use them, starts with their
> declaration (not before).
and I asked why this works:
fred(9999);
PROC fred = (INT n)VOID: print((n, newline));
print("end")
I speculated it was the same bug. But it still works with 3.12.2. So
this case, it is possible to call 'fred' even though it has not yet been
defined.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-23 09:21 +0200 |
| Subject | Re: [OT] Genie bug and fix (was Re: switch/extension for see below strongly needed) |
| Message-ID | <10urkhi$1s757$3@dont-email.me> |
| In reply to | #399301 |
On 2026-05-22 12:18, Bart wrote:
> [...]
> and I asked why this works:
>
> fred(9999);
>
> PROC fred = (INT n)VOID: print((n, newline));
>
> print("end")
>
> I speculated it was the same bug. But it still works with 3.12.2. So
> this case, it is possible to call 'fred' even though it has not yet been
> defined.
Concerning procedures I just want to give you this example:
PROC fred = (INT n) VOID: ( magic | barney (1) );
PROC barney = (INT n) VOID: ( magic | fred (2) );
How do you think mutual reference can work if the declarations of
procedures (or their names) are not visible in the whole context?
Chapter 5.4. of the Genie documentation might answer your question.
Otherwise I'd suggest to send an inquiry (or bug report) to Marcel.
Generally I suggest to read some tutorial or textbook thoroughly
and from start instead of randomly doing behavioral analysis of
pieces of Algol 68 code (or what you think is Algol 68). - This
place is not for discussing subtle details of Algol 68 or Genie.
Janis
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-20 06:24 +0200 |
| Message-ID | <10ujd10$k0ug$7@dont-email.me> |
| In reply to | #399173 |
On 2026-05-19 18:31, Bart wrote: > On 19/05/2026 14:40, David Brown wrote: >> [...] >> >> Can you give me an example of a real-world programming language in >> which the scope of a local variable begins at the start of the >> enclosing block, rather than at its declaration / definition? > > In Algo68: > > BEGIN > print((a, newline)); > INT a=777; > print((a, newline)); > END > > This prints 0 then 777. If I comment out the declaration, it says 'a' > has not been declared. 1. The original post was talking about "variables" (not about identity declarations). 2. Are you sure that above code is valid (error-free) Algol 68 code? I'm not sure about that. - My old textbook says that you can use these identifiers *after* you've set them (not before). And skimming through the standard document, the Revised Report, I could not find anything. If there is; can you point me to the relevant chapter, please? It could also just not have been defined in the standard. (The above code or Genie's behavior would then not tell anything relevant about the language. - It would just expose yet another example of code that an experienced programmer would just not write that way.) You seem to have tested that with the Genie interpreter? - This would not say anything about what the Algol 68 standard says, mind. - I've sent a mail to Marcel to clarify that, i.e. the behavior of Genie, and whether that's standard behavior, undefined, or an oversight or bug. > > Here, 'a' is a named constant; if I use a:=777 instead, which defines a > variable, it says the first 'a' has not been initialised (I guess 'INT > a' creates a reference to a local), a different error from not having > the INT line at all. This is expected behavior, as we know it and also expect it from other languages. - It's actually reflecting the point that David made. Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-20 11:55 +0100 |
| Message-ID | <10uk3vn$3t7f6$2@dont-email.me> |
| In reply to | #399199 |
On 20/05/2026 05:24, Janis Papanagnou wrote:
> On 2026-05-19 18:31, Bart wrote:
>> On 19/05/2026 14:40, David Brown wrote:
>>> [...]
>>>
>>> Can you give me an example of a real-world programming language in
>>> which the scope of a local variable begins at the start of the
>>> enclosing block, rather than at its declaration / definition?
>>
>> In Algo68:
>>
>> BEGIN
>> print((a, newline));
>> INT a=777;
>> print((a, newline));
>> END
>>
>> This prints 0 then 777. If I comment out the declaration, it says 'a'
>> has not been declared.
>
> 1. The original post was talking about "variables" (not about identity
> declarations).
The whole sub-topic is about the scope of identifiers, no matter what
they are for. (It excluded tag and label namespaces.)
Part of it was about what is in scope in the first half of this block:
int a=1234;
{
... // ?
int a=777;
...
}
I was asked which real programming languages have the scope of that
second 'a' extend back to the start of its block.
This is a fuller Algol68 program which runs with A68G:
INT a=1234;
PROC fred = (INT n)INT:
BEGIN
print((a, newline));
INT a=777;
print((a, newline));
a
END;
INT x;
x:=fred(23);
print(x)
All the extra bits are to avoid error messages. It seems that the scope
of that 'a' which is set to 777 does indeed go back to that BEGIN, or
rather its name, if not its value.
Try this version:
BEGIN
print((a, newline));
a
END
This shows '1234'. Now add this declaration:
BEGIN
print((a, newline));
INT a:=777;
a
END
Now it says that 'a' is uninitialised. The looks very strongly as the
'a' it attempts to print is the 'a' in the following declaration, even
this is usually a coding error.
> 2. Are you sure that above code is valid (error-free) Algol 68 code?
>
> I'm not sure about that. - My old textbook says that you can use these
> identifiers *after* you've set them (not before). And skimming through
> the standard document, the Revised Report, I could not find anything.
> If there is; can you point me to the relevant chapter, please?
>
> It could also just not have been defined in the standard. (The above
> code or Genie's behavior would then not tell anything relevant about
> the language. - It would just expose yet another example of code that
> an experienced programmer would just not write that way.)
> You seem to have tested that with the Genie interpreter? - This would
> not say anything about what the Algol 68 standard says, mind.
You seem determined to prove Bart wrong, aren't you?
[toc] | [prev] | [next] | [standalone]
Page 9 of 13 — ← Prev page 1 … 7 8 [9] 10 11 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web