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 7 of 13 — ← Prev page 1 … 5 6 [7] 8 9 … 13 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-22 17:47 +0200 |
| Message-ID | <10uptqr$1hfpm$2@dont-email.me> |
| In reply to | #399316 |
On 22/05/2026 17:16, Bart wrote: > On 22/05/2026 15:04, Scott Lurndal wrote: >> Bart <bc@freeuk.com> writes: >>> On 22/05/2026 01:24, Keith Thompson wrote: > >>>> <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2496.pdf> >>> >>> This is very interesting. So perhaps tens of millions of C programmers >>> encountered the quirk, found it annoying, and moved on. >> >> The vast majority of C programmers have likely never used goto. > > Source? Oh, 'likely', so it is just a random guess. > > In any case the issue (labels at the end of a compound statement) > applied also to case labels and to 'default:'. If a programmer wants a case label or default label at the end of a switch, doing nothing, then (prior to C23, and excluding compiler extensions) they have to put in an empty statement - "default : ;". (Or they could use "break;" to make code feel more symmetrical.) I can imagine that happening, and I can imagine that is the most likely situation where you would want a label right before an end brace. This seems to be the main motivation for the change in C23. It is much harder to imagine that this "bites" anyone, or even annoys people in any significant way. > > Now you're going to say the vast majority of C programmers have never > used 'switch' either! 'Probably...' > I think you might need to switch out your crystal ball - your predictions about what people will say or do have rarely come close to reality. Or, perhaps, you should stop saying such stupid things.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-22 17:35 +0100 |
| Message-ID | <10uq0jr$1kk65$1@dont-email.me> |
| In reply to | #399317 |
On 22/05/2026 16:47, David Brown wrote:
> On 22/05/2026 17:16, Bart wrote:
>> On 22/05/2026 15:04, Scott Lurndal wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> On 22/05/2026 01:24, Keith Thompson wrote:
>>
>>>>> <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2496.pdf>
>>>>
>>>> This is very interesting. So perhaps tens of millions of C programmers
>>>> encountered the quirk, found it annoying, and moved on.
>>>
>>> The vast majority of C programmers have likely never used goto.
>>
>> Source? Oh, 'likely', so it is just a random guess.
>>
>> In any case the issue (labels at the end of a compound statement)
>> applied also to case labels and to 'default:'.
> If a programmer wants a case label or default label at the end of a
> switch, doing nothing, then (prior to C23, and excluding compiler
> extensions) they have to put in an empty statement - "default : ;". (Or
> they could use "break;" to make code feel more symmetrical.) I can
> imagine that happening, and I can imagine that is the most likely
> situation where you would want a label right before an end brace. This
> seems to be the main motivation for the change in C23.
>
> It is much harder to imagine that this "bites" anyone, or even annoys
> people in any significant way.
And yet, the link at the top was about somebody proposing to fix this
very thing. And it was accepted.
There was no reason whatsoever to ban:
L:}
L:int x;
other than the grammar happening to define labels in a certain way. That
there are workarounds is not the point.
>>
>> Now you're going to say the vast majority of C programmers have never
>> used 'switch' either! 'Probably...'
>>
> I think you might need to switch out your crystal ball - your
> predictions about what people will say or do have rarely come close to
> reality. Or, perhaps, you should stop saying such stupid things.
Scott Lurndal said something stupid and I responded with sarcasm. Yet
you attack me and not him. Biased at all?
This is what I responded to in his post:
* An assertion that the 'vast majority' of C programmers have never used
'goto'.
* The assumption that the labels issue was only about goto labels
Is that assertion true? I don't know, but it sounds unlikely more than
likely. If I look at some codebases:
gotos used?
Lua Yes (300 in 30Kloc)
SQLite Yes (Over 600 in 220Kloc of comment-heavy code)
Tiny C Yes (40 in 30Kloc
LibJPEG Yes (About 80 in 60Kloc)
CPython Yes (over 1000 just in Objects folder, about 100Kloc)
A68G Yes (a handful, but they exist, in 70Kloc)
GMP Yes (50 in mpn/generic, 36Kloc)
I struggled to find any sizeable project without it.
So if you had to put money on it would you say Scott was right? What
does 'vast majority' mean anyway?
(Of course, Scott said programmers rather than applications. Maybe 1000
people work on CPython, but there's only one who writes all the gotos!)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-05-22 20:57 +0000 |
| Message-ID | <Wq3QR.651257$ZRIe.139122@fx22.iad> |
| In reply to | #399319 |
Bart <bc@freeuk.com> writes: >On 22/05/2026 16:47, David Brown wrote: >> On 22/05/2026 17:16, Bart wrote: >>> On 22/05/2026 15:04, Scott Lurndal wrote: >>>> Bart <bc@freeuk.com> writes: >>>>> On 22/05/2026 01:24, Keith Thompson wrote: >>> >>>>>> <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2496.pdf> >>>>> >>>>> This is very interesting. So perhaps tens of millions of C programmers >>>>> encountered the quirk, found it annoying, and moved on. >>>> >>>> The vast majority of C programmers have likely never used goto. >>> >>> Source? Oh, 'likely', so it is just a random guess. >>> >>> In any case the issue (labels at the end of a compound statement) >>> applied also to case labels and to 'default:'. > >> If a programmer wants a case label or default label at the end of a >> switch, doing nothing, then (prior to C23, and excluding compiler >> extensions) they have to put in an empty statement - "default : ;". (Or >> they could use "break;" to make code feel more symmetrical.) I can >> imagine that happening, and I can imagine that is the most likely >> situation where you would want a label right before an end brace. This >> seems to be the main motivation for the change in C23. >> >> It is much harder to imagine that this "bites" anyone, or even annoys >> people in any significant way. > >And yet, the link at the top was about somebody proposing to fix this >very thing. And it was accepted. > >There was no reason whatsoever to ban: > > L:} > L:int x; > >other than the grammar happening to define labels in a certain way. That >there are workarounds is not the point. > >>> >>> Now you're going to say the vast majority of C programmers have never >>> used 'switch' either! 'Probably...' >>> >> I think you might need to switch out your crystal ball - your >> predictions about what people will say or do have rarely come close to >> reality. Or, perhaps, you should stop saying such stupid things. > >Scott Lurndal said something stupid and I responded with sarcasm. Yet >you attack me and not him. Biased at all? > >This is what I responded to in his post: > >* An assertion that the 'vast majority' of C programmers have never used >'goto'. Think about it. You cite 7 projects that have goto's in them. Google estimates there are 11 to 13 million C programmers.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-23 00:24 +0100 |
| Message-ID | <10uqoju$1rqeg$1@dont-email.me> |
| In reply to | #399326 |
On 22/05/2026 21:57, Scott Lurndal wrote: > Bart <bc@freeuk.com> writes: >> This is what I responded to in his post: >> >> * An assertion that the 'vast majority' of C programmers have never used >> 'goto'. > > Think about it. You cite 7 projects that have goto's in them. How many millions do you want me to look at? > Google estimates there are 11 to 13 million C programmers. I can't isolate the work of individual programmers. I can only look at C codebases. So let's say that a 'vast majority' of programmers equates to 90% of codebases being free of 'goto'. That is, only 1 in 10 projects have one or more 'goto'. Then the probably of the first 7 projects I look at all having gotos is near-zero (I worked it out as 1 in 10 million). If I look at more projects, the results are more varied, but it looks like more than half of them use goto. Certainly not as few as 1 in 10. So I don't think it's even a majority that avoid 'goto', and it's unlikely to be a 'vast' majority. There's more to it than that: an individual programmer will have worked on multiple projects. Some may have used goto and some not, if examined. But you claimed that nearly all have /never/ used it. That is not practical to test for.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-23 11:46 +0200 |
| Message-ID | <10urt15$25qmr$1@dont-email.me> |
| In reply to | #399319 |
On 22/05/2026 18:35, Bart wrote: > On 22/05/2026 16:47, David Brown wrote: >> On 22/05/2026 17:16, Bart wrote: >>> On 22/05/2026 15:04, Scott Lurndal wrote: >>>> Bart <bc@freeuk.com> writes: >>>>> On 22/05/2026 01:24, Keith Thompson wrote: >>> >>>>>> <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2496.pdf> >>>>> >>>>> This is very interesting. So perhaps tens of millions of C programmers >>>>> encountered the quirk, found it annoying, and moved on. >>>> >>>> The vast majority of C programmers have likely never used goto. >>> >>> Source? Oh, 'likely', so it is just a random guess. >>> >>> In any case the issue (labels at the end of a compound statement) >>> applied also to case labels and to 'default:'. > >> If a programmer wants a case label or default label at the end of a >> switch, doing nothing, then (prior to C23, and excluding compiler >> extensions) they have to put in an empty statement - "default : ;". >> (Or they could use "break;" to make code feel more symmetrical.) I >> can imagine that happening, and I can imagine that is the most likely >> situation where you would want a label right before an end brace. >> This seems to be the main motivation for the change in C23. >> >> It is much harder to imagine that this "bites" anyone, or even annoys >> people in any significant way. > > And yet, the link at the top was about somebody proposing to fix this > very thing. And it was accepted. > We all know that "L:;}" is used sometimes in code (typically with case or default labels). One day, someone who happened to use that construction regularly, and who was already a highly respected C developer and already worked with the C standards committee, took the time to figure out what wording would need to be changed in the standard to allow "L:}". This was not a change worth putting much effort into, but no one had to do much work for it. > There was no reason whatsoever to ban: > > L:} > L:int x; > > other than the grammar happening to define labels in a certain way. That > there are workarounds is not the point. For someone who is so proud of having "designed" several languages, you are remarkably ignorant about how languages are designed. Most of the time, people decide what they want to /allow/, not what they want to ban. And most of the time, the aim is to keep things as simple as possible (but no simpler) to be able to do what you want to do. For C, up until C23, one form of "statement" is "labelled statement" that looks like "label : statement". That's simple and easy to write in the standards, simple and easy to use in practice, and simple and easy to support in implementations. While I am not privy to the thoughts of either Ritchie or early C implementers and influencers, I cannot imagine "L:}" was /banned/ - it was simply not supported in the grammar of the language, probably because that would have been an unnecessary complication in the descriptions. > >>> >>> Now you're going to say the vast majority of C programmers have never >>> used 'switch' either! 'Probably...' >>> >> I think you might need to switch out your crystal ball - your >> predictions about what people will say or do have rarely come close to >> reality. Or, perhaps, you should stop saying such stupid things. > > Scott Lurndal said something stupid and I responded with sarcasm. Yet > you attack me and not him. Biased at all? > Scott can answer that if he wants to.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-23 11:31 +0100 |
| Message-ID | <10urvlm$26961$2@dont-email.me> |
| In reply to | #399348 |
On 23/05/2026 10:46, David Brown wrote: > On 22/05/2026 18:35, Bart wrote: >> And yet, the link at the top was about somebody proposing to fix this >> very thing. And it was accepted. >> > > We all know that "L:;}" is used sometimes in code (typically with case > or default labels). One day, someone who happened to use that > construction regularly, and who was already a highly respected C > developer and already worked with the C standards committee, Oh, right. So there would have been no point in my doing it. But Keith Thompson had a go a me for not doing that anyway: "Somebody (notably not you) took the time to write a proposal and submit it to the commmittee, which accepted it." > >> There was no reason whatsoever to ban: >> >> L:} >> L:int x; >> >> other than the grammar happening to define labels in a certain way. >> That there are workarounds is not the point. > > For someone who is so proud of having "designed" several languages, you > are remarkably ignorant about how languages are designed. Most of the > time, people decide what they want to /allow/, not what they want to > ban. And most of the time, the aim is to keep things as simple as > possible (but no simpler) to be able to do what you want to do. For C, > up until C23, one form of "statement" is "labelled statement" that looks > like "label : statement". That's simple and easy to write in the > standards, simple and easy to use in practice, and simple and easy to > support in implementations. While I am not privy to the thoughts of > either Ritchie or early C implementers and influencers, I cannot imagine > "L:}" was /banned/ - it was simply not supported in the grammar of the > language, probably because that would have been an unnecessary > complication in the descriptions. So, you're picking up on the word "ban". How would you have worded it? > For someone who is so proud of having "designed" several languages, All of which allow labels at the end of a block or before declarations, when the latter could be mixed within executable code. Actually, I probably allow labels in too many places, including in the middle of expressions, like here (expressed in A68G syntax): INT a, b:=2, c:=3, d:=4; a := IF b=c THEN fred: c ELSE d FI; GOTO fred; Declaring the label is not an error with A68G, but trying to jump into the expression doesn't work; presumably the scope of 'fred' is limited to the block so it just can't see it. Jumping out of the expression via GOTO is allowed however. My languages allow both. Jumping into the middle of a block is sometimes done and can be safe. Into the middle of an expression is less so, so should ideally be detected and blocked, probably in a later compiler pass.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-23 13:51 +0200 |
| Message-ID | <10us4b8$28g09$1@dont-email.me> |
| In reply to | #399352 |
On 23/05/2026 12:31, Bart wrote: > On 23/05/2026 10:46, David Brown wrote: >> On 22/05/2026 18:35, Bart wrote: > >>> And yet, the link at the top was about somebody proposing to fix this >>> very thing. And it was accepted. >>> >> >> We all know that "L:;}" is used sometimes in code (typically with case >> or default labels). One day, someone who happened to use that >> construction regularly, and who was already a highly respected C >> developer and already worked with the C standards committee, > > Oh, right. So there would have been no point in my doing it. But Keith > Thompson had a go a me for not doing that anyway: Do you think Keith, me, and perhaps the rest of the c.l.c. regulars all get together in secret meetings to discuss how we are going to attack you? Or do you think we are all the same person, with different pseudonyms? If not, why do you keep asking people to justify the opinions or statements made by others? Or, more often, why do you ask people to justify words and sentiments that you put in other peoples' mouths? Don't you think it would be more productive to read what people write, think about what they wrote, try to understand it, and perhaps ask them if you can't figure out what they are saying? > > "Somebody (notably not you) took the time to write a proposal and submit > it to the commmittee, which accepted it." > >> >>> There was no reason whatsoever to ban: >>> >>> L:} >>> L:int x; >>> >>> other than the grammar happening to define labels in a certain way. >>> That there are workarounds is not the point. >> >> For someone who is so proud of having "designed" several languages, >> you are remarkably ignorant about how languages are designed. Most of >> the time, people decide what they want to /allow/, not what they want >> to ban. And most of the time, the aim is to keep things as simple as >> possible (but no simpler) to be able to do what you want to do. For >> C, up until C23, one form of "statement" is "labelled statement" that >> looks like "label : statement". That's simple and easy to write in >> the standards, simple and easy to use in practice, and simple and easy >> to support in implementations. While I am not privy to the thoughts >> of either Ritchie or early C implementers and influencers, I cannot >> imagine "L:}" was /banned/ - it was simply not supported in the >> grammar of the language, probably because that would have been an >> unnecessary complication in the descriptions. > > So, you're picking up on the word "ban". How would you have worded it? If you "ban" something, you actively and explicitly choose not to allow it. > > > For someone who is so proud of having "designed" several languages, > > All of which ... ... are irrelevant.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-23 13:07 +0100 |
| Message-ID | <10us5av$28o7p$1@dont-email.me> |
| In reply to | #399357 |
On 23/05/2026 12:51, David Brown wrote: > On 23/05/2026 12:31, Bart wrote: >> On 23/05/2026 10:46, David Brown wrote: >>> On 22/05/2026 18:35, Bart wrote: >> >>>> And yet, the link at the top was about somebody proposing to fix >>>> this very thing. And it was accepted. >>>> >>> >>> We all know that "L:;}" is used sometimes in code (typically with >>> case or default labels). One day, someone who happened to use that >>> construction regularly, and who was already a highly respected C >>> developer and already worked with the C standards committee, >> >> Oh, right. So there would have been no point in my doing it. But Keith >> Thompson had a go a me for not doing that anyway: > > Do you think Keith, me, .... Irrelevant. That was clearly a snide comment aimed at me. KT: >> "Somebody (notably not you) took the time to write a proposal and >> submit it to the commmittee, which accepted it." >> So, you're picking up on the word "ban". How would you have worded it? > > If you "ban" something, you actively and explicitly choose not to allow it. So you don't like the word. Maybe it wasn't intentional at the start, and maybe neither was doing nothing about it for decades (unintentionally of course), but the end result was the same. >> >> > For someone who is so proud of having "designed" several languages, >> >> All of which ... > ... are irrelevant. My choices of label placement are irrelevant to the choices made in C in a paragraph about language design? OK. But you managed to squeeze in another snarky comment anyway. ALWAYS with the personal attacks in this group.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-05-23 14:35 +0200 |
| Message-ID | <10us6tu$29haf$1@dont-email.me> |
| In reply to | #399358 |
Bart pisze: > On 23/05/2026 12:51, David Brown wrote: >> On 23/05/2026 12:31, Bart wrote: >>> On 23/05/2026 10:46, David Brown wrote: >>>> On 22/05/2026 18:35, Bart wrote: >>> >>>>> And yet, the link at the top was about somebody proposing to fix >>>>> this very thing. And it was accepted. >>>>> >>>> >>>> We all know that "L:;}" is used sometimes in code (typically with >>>> case or default labels). One day, someone who happened to use that >>>> construction regularly, and who was already a highly respected C >>>> developer and already worked with the C standards committee, >>> >>> Oh, right. So there would have been no point in my doing it. But >>> Keith Thompson had a go a me for not doing that anyway: >> > >> Do you think Keith, me, .... > > Irrelevant. That was clearly a snide comment aimed at me. > KT: >>> "Somebody (notably not you) took the time to write a proposal and >>> submit it to the commmittee, which accepted it." > > >>> So, you're picking up on the word "ban". How would you have worded it? >> >> If you "ban" something, you actively and explicitly choose not to >> allow it. > > So you don't like the word. Maybe it wasn't intentional at the start, > and maybe neither was doing nothing about it for decades > (unintentionally of course), but the end result was the same. > > >>> >>> > For someone who is so proud of having "designed" several languages, >>> >>> All of which ... >> ... are irrelevant. > > My choices of label placement are irrelevant to the choices made in C in > a paragraph about language design? OK. > > But you managed to squeeze in another snarky comment anyway. > > ALWAYS with the personal attacks in this group. im not reading into that threads (it would need a very big focus not to get lost in that large branches of that trees) but i may say i find you and mclean as the most sense users of comp.lang.c - not that i hate this so called 'regulars' (im not - if the regulars would be not present the group would be empty and it would bo no place to post at all ;c esides thay talke on topic (thoug i would say only on part of it as they say most interesting part of topics too)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-05-23 14:38 +0200 |
| Message-ID | <10us742$29kbd$1@dont-email.me> |
| In reply to | #399359 |
fir pisze: > esides thay talke on topic (thoug i would say only on part of it as they > say most interesting part of topics too) errata: "besides they talk on topic (though, i would say, only on part of it, as they "skip" (left not risen) most interesting part of topics, too)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-23 20:46 -0700 |
| Message-ID | <10utsan$947a$2@kst.eternal-september.org> |
| In reply to | #399358 |
Bart <bc@freeuk.com> writes:
> On 23/05/2026 12:51, David Brown wrote:
[...]
>> Do you think Keith, me, ....
>
> Irrelevant. That was clearly a snide comment aimed at me.
> KT:
>>> "Somebody (notably not you) took the time to write a proposal and
>>> submit it to the commmittee, which accepted it."
Yes, it was a snide comment aimed at you. Not part of a conspiracy
or any biased attempt to reject ideas just because they're yours,
just a single snide comment.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-23 13:55 +0100 |
| Message-ID | <10us83g$28o7p$2@dont-email.me> |
| In reply to | #399352 |
On 23/05/2026 11:31, Bart wrote: > On 23/05/2026 10:46, David Brown wrote: > > For someone who is so proud of having "designed" several languages, > > All of which allow labels at the end of a block or before declarations, > when the latter could be mixed within executable code. > > Actually, I probably allow labels in too many places, including in the > middle of expressions, like here (expressed in A68G syntax): > > INT a, b:=2, c:=3, d:=4; > > a := IF b=c THEN fred: c ELSE d FI; > GOTO fred; > > Declaring the label is not an error with A68G, but trying to jump into > the expression doesn't work; presumably the scope of 'fred' is limited > to the block so it just can't see it. > > Jumping out of the expression via GOTO is allowed however. > > My languages allow both. Jumping into the middle of a block is sometimes > done and can be safe. Into the middle of an expression is less so, so > should ideally be detected and blocked, probably in a later compiler pass. I tried gnu C, which has statement expressions. That also lets you have labels inside expressions. Jumping into an expression from outside is not allowed (for a different reason than Algol68), but jumping out of it is.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-22 05:58 +0200 |
| Message-ID | <10uok9r$k0ug$14@dont-email.me> |
| In reply to | #399283 |
On 2026-05-22 02:24, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> [...]
>>
>> (Labels of course have their own namespace, for some obscure
>> reason. I'm sure 99% of C programmers don't know that.) "
>
> I suggest using the term "name space" rather than "namespace",
> which happens to be the name of a C++ feature.
The term "namespace" is, as I observe, a regular English word
(it's in my dictionary, at least).
So if you want to talk about a namespace there's nothing wrong
with using the term namespace (without any punctuation or any
arbitrary spacing).
I think (instead of a space) it's sensible to apply typographical
conventions to signify "features". I've, for example, generally
used single quotes to identify programming language entities or
keywords, as in 'namespace' (a C++ feature or keyword).
("A namespace in C++ is denoted by the keyword 'namespace'.")
Denoting such things with (for example) single quotes makes the
whole text also better readable, because the typical programming
languages' entities are (also) English words and interfere with
the surrounding texts.
Janis
> [...]
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-21 21:21 -0700 |
| Message-ID | <10uolku$1734o$2@kst.eternal-september.org> |
| In reply to | #399291 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-05-22 02:24, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> [...]
>>> (Labels of course have their own namespace, for some obscure
>>> reason. I'm sure 99% of C programmers don't know that.) "
>> I suggest using the term "name space" rather than "namespace",
>> which happens to be the name of a C++ feature.
>
> The term "namespace" is, as I observe, a regular English word
> (it's in my dictionary, at least).
It's not in dictionary.com or the online Merriam Webster (not
surprisingly, the OED has it), and I don't think it's a common term
outside programming.
> So if you want to talk about a namespace there's nothing wrong
> with using the term namespace (without any punctuation or any
> arbitrary spacing).
The problem is that "namespace" is a C++ keyword with a specific
meaning that doesn't apply to C. And the C standard consistently
uses the phrase "name space", and defines it as a technical term.
Of course C and C++ are two different languages, but they share a lot
in common. C++ has both C-style name spaces and its own namespaces.
Referring to C's name spaces as "namespaces" might not cause much
confusion, but it's likely to induce a reaction from the more
pedantic among us.
[snip]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-22 07:17 +0200 |
| Message-ID | <10uoota$jvhi$20@dont-email.me> |
| In reply to | #399292 |
On 2026-05-22 06:21, Keith Thompson wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> On 2026-05-22 02:24, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> [...]
>>>> (Labels of course have their own namespace, for some obscure
>>>> reason. I'm sure 99% of C programmers don't know that.) "
>>> I suggest using the term "name space" rather than "namespace",
>>> which happens to be the name of a C++ feature.
>>
>> The term "namespace" is, as I observe, a regular English word
>> (it's in my dictionary, at least).
>
> It's not in dictionary.com or the online Merriam Webster (not
> surprisingly, the OED has it), and I don't think it's a common term
> outside programming.
>
>> So if you want to talk about a namespace there's nothing wrong
>> with using the term namespace (without any punctuation or any
>> arbitrary spacing).
>
> The problem is that "namespace" is a C++ keyword with a specific
> meaning that doesn't apply to C. And the C standard consistently
> uses the phrase "name space", and defines it as a technical term.
>
> Of course C and C++ are two different languages, but they share a lot
> in common. C++ has both C-style name spaces and its own namespaces.
>
> Referring to C's name spaces as "namespaces" might not cause much
> confusion, but it's likely to induce a reaction from the more
> pedantic among us.
I wouldn't import the conventions of a specific language's "bible"
to colloquial communication, even if that communication is mostly
about that language. If we're talking about concepts ("namespaces")
it's fine and appropriate to simply name them as such. (YMMV.)
A subtle space is just an IMO inappropriate means; if compared to
the typographical suggestion I made. Specifically in the light that
we often see word-compounds written in many alternative forms (say,
"name space", "name-space", or "namespace").
I don't much care about the pedants - I know them by name :-) - if
they're missing the more important global picture; the clearness of
formulations (as I previously expanded on [in the part you trimmed]).
In the light of your suggestion (a space) I wanted to suggest a
(IMO better) typographical alternative (quoted technical entities).
Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-22 10:49 +0200 |
| Message-ID | <10up59u$19vfc$3@dont-email.me> |
| In reply to | #399291 |
On 22/05/2026 05:58, Janis Papanagnou wrote:
> On 2026-05-22 02:24, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>
>>> (Labels of course have their own namespace, for some obscure
>>> reason. I'm sure 99% of C programmers don't know that.) "
>>
>> I suggest using the term "name space" rather than "namespace",
>> which happens to be the name of a C++ feature.
>
> The term "namespace" is, as I observe, a regular English word
> (it's in my dictionary, at least).
>
> So if you want to talk about a namespace there's nothing wrong
> with using the term namespace (without any punctuation or any
> arbitrary spacing).
>
> I think (instead of a space) it's sensible to apply typographical
> conventions to signify "features". I've, for example, generally
> used single quotes to identify programming language entities or
> keywords, as in 'namespace' (a C++ feature or keyword).
>
> ("A namespace in C++ is denoted by the keyword 'namespace'.")
>
> Denoting such things with (for example) single quotes makes the
> whole text also better readable, because the typical programming
> languages' entities are (also) English words and interfere with
> the surrounding texts.
>
> Janis
>
There are two reasons to use the term "name space" rather than
"namespace". On is that C++, and many other languages, support
"namespaces" as a type of structuring of identifier scope. This is a
different concept from the "name spaces" we are discussing here.
The other reason to include the space is that the C standards use the
term "name space", so if anyone wants to look things up in the standards
and search for mentions of the concept, they will need to include the space.
It is unfortunate that there are no good, convenient ways to distinguish
between "identifier name spaces" in C (and other languages) and "scope
namespaces" in C++ (and other languages, but not C). Such collisions
occur all the time. We might colloquially say that functions and
variables are different types of objects - but "type" and "object" have
specific meanings in C that do not match such loose usage. (And the
meaning of "object" in C differs substantially from the same term in
many other languages.) So we can try other words, like "kind" (but
that's a keyword in Fortran), or "concept" (now a keyword in C++), and
so on.
The best we can do is try to be as accurate as we can about terms in the
C standards, since we are in c.l.c., and try to make the context clear.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-23 05:49 +0200 |
| Message-ID | <10ur83u$1s757$1@dont-email.me> |
| In reply to | #399299 |
On 2026-05-22 10:49, David Brown wrote: > [snip for brevity] All that you (and James downthread) wrote about namespaces I already knew (and acknowledge) from your earlier posts. My conclusions and suggestion are, for the already explained reasons, still the same. - So our opinions on that obviously differ. Never mind. Janis
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-05-22 18:37 -0400 |
| Message-ID | <10uqlrt$13u9n$1@dont-email.me> |
| In reply to | #399291 |
On 2026-05-21 23:58, Janis Papanagnou wrote:
> On 2026-05-22 02:24, Keith Thompson wrote:
...
>> I suggest using the term "name space" rather than "namespace",
>> which happens to be the name of a C++ feature.
>
> The term "namespace" is, as I observe, a regular English word
> (it's in my dictionary, at least).
...
> ("A namespace in C++ is denoted by the keyword 'namespace'.")
The term "name spaces" is officially defined by the C standard (6.2.3p1).
"Thus, there are separate _name spaces_ for various categories of
identifiers, as follows:"
Note that "name spaces" is in italics, an ISO convention indicating that
the sentence containing the term is the official definition of that
term, with a meaning more specific than that given in your dictionary.
Every use of "name space" in the C standard is consistent with it being
the singular term corresponding to the plural term "name spaces".
The C++ standard also uses the term "name space", but does not define it
- but seems to use it in a fashion consistent with C's definition,
except that C++ has a smaller variety of categories. It also uses the
term namespace without definition. It does formally define the terms
namespace-definition and namespace-body, and the keyword namespace.
Every appearance of "namespace" in the C++ standard has a meaning
inconsistent with the one defined by the C standard and used by the C++
standard for the term "name spaces".
Therefore, I think it's crucial not to confuse the two meanings, which
requires being careful about the difference between "name space" and
"namespace".
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-05-21 19:49 -0400 |
| Message-ID | <10uo5mk$13u9o$2@dont-email.me> |
| In reply to | #399275 |
On 2026-05-21 17:23, Keith Thompson wrote: ... > This entire discussion is pointless. It is a fact that C labels > are in their own name space. Nobody here has provided a rationale > for that fact. I did. I pointed out that the standard sets aside a separate name space for each kind of identifier which is usable only in syntactic contexts where an ordinary identifier would not be allowed. The Rationale says "The position adopted in the Standard is to permit as many separate name spaces as can be distinguished by context, ...". Apparently the Committee likes separate name spaces; you'll have to ask them why.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-21 17:27 -0700 |
| Message-ID | <10uo7tb$14o2h$2@kst.eternal-september.org> |
| In reply to | #399280 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 2026-05-21 17:23, Keith Thompson wrote:
> ...
>> This entire discussion is pointless. It is a fact that C labels
>> are in their own name space. Nobody here has provided a rationale
>> for that fact.
>
> I did. I pointed out that the standard sets aside a separate name space
> for each kind of identifier which is usable only in syntactic contexts
> where an ordinary identifier would not be allowed.
>
> The Rationale says "The position adopted in the Standard is to permit as
> many separate name spaces as can be distinguished by context, ...".
I stand corrected. (This wording appears in both the C89 and C99
Rationale documents.)
> Apparently the Committee likes separate name spaces; you'll have to ask
> them why.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
Page 7 of 13 — ← Prev page 1 … 5 6 [7] 8 9 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web