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 3 of 13 — ← Prev page 1 2 [3] 4 5 … 13 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-19 17:58 +0200 |
| Message-ID | <10ui1bi$3c4ur$1@dont-email.me> |
| In reply to | #399169 |
On 19/05/2026 17:23, Janis Papanagnou wrote: > On 2026-05-19 17:07, David Brown wrote: >> On 19/05/2026 16:41, Janis Papanagnou wrote: >>> On 2026-05-19 15: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? >>> >>> If I'm asking Google it tells me that Python and Javascript (when >>> using 'var') would be two prominent examples. >> >> I don't know about Javascript, > > I did JS programming but never tried to put the declaration behind > the point of use of the declared items. > > I mean that is the whole point; even if some language (for whatever > reason) would allow that, why should a sane programmer make use of > such obfuscation! Agreed. I've done a little Javascript, but not enough to know if the language allows such constructions that I'd never imagine using. > >> but it's wrong about Python. > > I don't know the details of and also don't program in python. > >> >> def foo() : >> print(a) >> a = 1 >> print(a) >> >> "a" is not in scope until the line "a = 1". Try it and see. > > $ python > ksh93: python: not found > Way OT - but what kind of OS are you running that does not have Python installed? Even if you don't program in Python, there must surely be some Python programs on your system. (Of the 3900 files in my /usr/bin, some 211 of them are in Python. I don't program in Perl, but I have perl on my system for the 169 Perl programs in my /usr/bin.) Maybe you don't have it as "python", but as "python3" (or "python2") ? > I trust your words. :-) > >> [snip] > > (I was just quoting search results. Never mind.) > Well, the challenge is really for Bart.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-19 18:31 +0200 |
| Message-ID | <10ui39c$jvhi$10@dont-email.me> |
| In reply to | #399172 |
On 2026-05-19 17:58, David Brown wrote: > On 19/05/2026 17:23, Janis Papanagnou wrote: >> >> $ python >> ksh93: python: not found > > Way OT - but what kind of OS are you running that does not have Python > installed? Even if you don't program in Python, there must surely be > some Python programs on your system. (Of the 3900 files in my /usr/bin, > some 211 of them are in Python. I don't program in Perl, but I have > perl on my system for the 169 Perl programs in my /usr/bin.) > > Maybe you don't have it as "python", but as "python3" (or "python2") ? Yes, I saw that 'man python' works, and there's also '/usr/bin/python3' existing. I'll certainly never use it! $ python3 Python 3.12.3 (main, Mar 23 2026, 19:04:32) [GCC 13.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> help Type help() for interactive help, or help(object) for help about object. >>> quit Use quit() or Ctrl-D (i.e. EOF) to exit >>> Really? It first suggests to type "help" and then reports that I should type "help()" instead? It prints that I should type "quit()" instead of "quit", or Ctrl-D, but it will not _just do_ that quit. Is that contemporary software interface ergonomy? Sensible design? Useful interactive information? - I mean, we're obviously already in the 3rd major release, and there's still such quality exhibited. (I'm really getting angry if I encounter such interfaces.) Yes, way OT, as you said, and nothing I'd like to dispute about. Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-19 18:38 +0200 |
| Message-ID | <10ui3m8$3d4jn$1@dont-email.me> |
| In reply to | #399174 |
On 19/05/2026 18:31, Janis Papanagnou wrote: > On 2026-05-19 17:58, David Brown wrote: >> On 19/05/2026 17:23, Janis Papanagnou wrote: >>> >>> $ python >>> ksh93: python: not found >> >> Way OT - but what kind of OS are you running that does not have Python >> installed? Even if you don't program in Python, there must surely be >> some Python programs on your system. (Of the 3900 files in my /usr/ >> bin, some 211 of them are in Python. I don't program in Perl, but I >> have perl on my system for the 169 Perl programs in my /usr/bin.) >> >> Maybe you don't have it as "python", but as "python3" (or "python2") ? > > Yes, I saw that 'man python' works, and there's also '/usr/bin/python3' > existing. > > > I'll certainly never use it! > > $ python3 > Python 3.12.3 (main, Mar 23 2026, 19:04:32) [GCC 13.3.0] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> help > Type help() for interactive help, or help(object) for help about object. > >>> quit > Use quit() or Ctrl-D (i.e. EOF) to exit > >>> > > > Really? > > It first suggests to type "help" and then reports that I should type > "help()" instead? > > It prints that I should type "quit()" instead of "quit", or Ctrl-D, > but it will not _just do_ that quit. > It does not sound unreasonable to me. It's a programming language. "quit" and "help" are functions. If you try to write 'printf "Hello world!" ' in C code, you would not expect the compiler to treat it as though you'd included the parentheses. But you'd be happy if the compiler gave you helpful hints in its error messages. It's the same here. Of course, Python could have had "quit" as a statement (Python 2 had "print" as a statement, and changed it to a function in Python 3 - backwards compatibility is not as important between Python major versions as in the C world). But given that it is a function, I expect to have to use function syntax to call it. (And just like a discussion on C, an explanation of why things are the way they are in Python is not necessarily an endorsement of any given design decision.) > Is that contemporary software interface ergonomy? Sensible design? > Useful interactive information? - I mean, we're obviously already > in the 3rd major release, and there's still such quality exhibited. > > (I'm really getting angry if I encounter such interfaces.) > > > Yes, way OT, as you said, and nothing I'd like to dispute about. > > Janis >
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-19 18:54 +0200 |
| Message-ID | <10ui4jf$jvhi$11@dont-email.me> |
| In reply to | #399176 |
On 2026-05-19 18:38, David Brown wrote: > On 19/05/2026 18:31, Janis Papanagnou wrote: >> [ python3 interface stuff ] > > It does not sound unreasonable to me. It's a programming language. It's an _interface_ not conforming to any basic interface standards I'd expect. (I was not discussing the language, and neither intend to discuss the Python language nor the interface of the Python tool.) Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-19 17:44 +0100 |
| Message-ID | <10ui40r$3d4gs$2@dont-email.me> |
| In reply to | #399168 |
On 19/05/2026 16:07, David Brown wrote:
> On 19/05/2026 16:41, Janis Papanagnou wrote:
>> On 2026-05-19 15: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?
>>
>> If I'm asking Google it tells me that Python and Javascript (when
>> using 'var') would be two prominent examples.
>>
>> Janis
>>
>
> I don't know about Javascript, but it's wrong about Python.
>
> def foo() :
> print(a)
> a = 1
> print(a)
>
> "a" is not in scope until the line "a = 1". Try it and see.
>
> It is possible that "a" blocks access to a global "a" before it is
> declared - since programmers rarely intentionally shadow other
> variables, and even more rarely try to access variables before they are
> defined, it's not a situation that is going to turn up in real code.
> Such subtle details are best checked in a Python newsgroup.
>
> Note also that Python doesn't really have a concept of declaring a
> variable. You initialise a reference to an object, you don't declare a
> variable as such. (So "a = 1" here creates a constant integer object
> with the value 1 on the heap, or increases a reference count to an
> existing such object, and creates "a" as an identifier that references
> that object. "a" is not a variable in the sense used in compiled
> imperative languages.)
>
In Lua:
function fred()
print(a)
local a
a=1
print(a)
end
a=999
fred()
print(a)
This outputs 999 1 999. So the global a is visible from that first
'print' line; its scope must be start earlier than its initialisation.
However these are both dynamic languages where you might find that that
static-looking 'function' is really something executed at runtime. If I
try the same in mine I get Void 1 999.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-19 18:59 +0200 |
| Message-ID | <10ui4u1$3d4jn$3@dont-email.me> |
| In reply to | #399177 |
On 19/05/2026 18:44, Bart wrote: > On 19/05/2026 16:07, David Brown wrote: >> On 19/05/2026 16:41, Janis Papanagnou wrote: >>> On 2026-05-19 15: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? >>> >>> If I'm asking Google it tells me that Python and Javascript (when >>> using 'var') would be two prominent examples. >>> >>> Janis >>> >> >> I don't know about Javascript, but it's wrong about Python. >> >> def foo() : >> print(a) >> a = 1 >> print(a) >> >> "a" is not in scope until the line "a = 1". Try it and see. >> >> It is possible that "a" blocks access to a global "a" before it is >> declared - since programmers rarely intentionally shadow other >> variables, and even more rarely try to access variables before they >> are defined, it's not a situation that is going to turn up in real >> code. Such subtle details are best checked in a Python newsgroup. >> >> Note also that Python doesn't really have a concept of declaring a >> variable. You initialise a reference to an object, you don't declare >> a variable as such. (So "a = 1" here creates a constant integer >> object with the value 1 on the heap, or increases a reference count to >> an existing such object, and creates "a" as an identifier that >> references that object. "a" is not a variable in the sense used in >> compiled imperative languages.) >> > > In Lua: > > function fred() > print(a) > local a > a=1 > print(a) > end > > a=999 > fred() > print(a) > > This outputs 999 1 999. So the global a is visible from that first > 'print' line; its scope must be start earlier than its initialisation. > > However these are both dynamic languages where you might find that that > static-looking 'function' is really something executed at runtime. If I > try the same in mine I get Void 1 999. > You have explained it yourself. Although Lua has another effect - any attempt to access a missing variable is considered a declaration of the variable with value "nil".
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-19 17:31 +0100 |
| Message-ID | <10ui38p$3d4gs$1@dont-email.me> |
| In reply to | #399163 |
On 19/05/2026 14:40, David Brown wrote:
> On 19/05/2026 15:08, Bart wrote:
>> {...} is a block in C, and C has block scopes. Given that, people
>> might expect a scope to be delimited by the enclosing spaces.
>
> People expect scopes to begin with a declaration, and end at the end of
> the block (or file, for file-scope identifiers). This is the normal
> handling of scoping in most imperative programming languages. There are
> some languages (such as Python) where scopes begin when a variable is
> first assigned, and continue to the end of the function rather than the
> block. And declarative programming languages may do things differently
> - they do many things differently.
>
> Languages may differ in the details - given "int a = foo(a);", for
> example, the scope of the new "a" in C begins after "int a" - in some
> languages, it may not begin until the end of the semicolon. But that's
> a small detail, rarely relevant in real code. (For the record, I'd have
> preferred if the scope of variables in C did not begin until the end of
> the declaration / definition.)
>
> 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.
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.
Now, you said real-world not mainstream, so all mine currently do that.
Anything declared in a function body has function-wide scope, including
to any depth of nested block.
Outside of a function, it has module-wide scope. If also declared
'global', it has sub-program-wide scope (although other modules can
shadow it).
Here, obviously, exactly where in a module a name has been defined, is
irrelevant.
In C, the same of thing happens when you introduced a forward
declaration of a function: you move its lexical scope to near the top.
In this case, it wouldn't be shadowing anything; there can't be anything
at an outer scope. So there wouldn't be a problem in scope starting from
the top of the file.
> Perhaps you are mixing up "scope" and "lifetime" ? These are not the
> same things.
I'm talking about static, lexical code, which can be determined at
compile-time.
>>
>> But names don't come into existence until declared, which can be in
>> the middle of a block. Until then, the outer version of 'a' is still
>> in scope.
>>
>
> Yes. Scope is all about the names.
>
>> The point at each that happens, in a busy section of code with lots of
>> declarations, can be unclear, with overlaps:
>>
>> double a;
>> .... // a2 b1 c1
>> double b;
>> .... // a2 b2 c1
>> double c;
>> .... // a2 b2 c2
>>
>> These all shadow a, b, c in an outer scope, but at different times.
>
> Yes. (Although this is again a strawman argument - people don't
> normally write code that shadows outer scope variables.)
Funny you should say that:
Lua sources: 190
SQLite sources: 300
Tiny C sources 30
MZlib sources: 80
The number shown is the number of times that the same local variable
name occurs more than once in the same function, shadowing or not. I
count only one instance per unique name per function.
Maybe 10% of the time, types are different. In some cases, local
variable exist that differ only in letter case (not counted above).
(Note many of these arise from macro expansions.)
>>
>> The simplest scoping rule in C is for labels: they have function-wide
>> scope, regardless of block nesting label.
>>
>
> The rule for C labels exists because you have to be able to jump
> backwards and forwards for "goto" to be of much use. In C programming,
> labels (excluding case labels) are rarely used except sometimes for
> error handling. I don't think I've written "goto" in C more than a
> couple of times in my programming career.
>
> C labels are unstructured. This is not a good thing in a programming
> language - it is an unfortunate necessary evil.
A good thing in this case; imagine the same L23 label occurring half a
dozen times in the same function, even if labels had block scopes.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-19 18:48 +0200 |
| Message-ID | <10ui48o$3d4jn$2@dont-email.me> |
| In reply to | #399173 |
On 19/05/2026 18:31, Bart wrote:
> On 19/05/2026 14:40, David Brown wrote:
>> On 19/05/2026 15:08, Bart wrote:
>
>>> {...} is a block in C, and C has block scopes. Given that, people
>>> might expect a scope to be delimited by the enclosing spaces.
>>
>> People expect scopes to begin with a declaration, and end at the end
>> of the block (or file, for file-scope identifiers). This is the
>> normal handling of scoping in most imperative programming languages.
>> There are some languages (such as Python) where scopes begin when a
>> variable is first assigned, and continue to the end of the function
>> rather than the block. And declarative programming languages may do
>> things differently - they do many things differently.
>>
>> Languages may differ in the details - given "int a = foo(a);", for
>> example, the scope of the new "a" in C begins after "int a" - in some
>> languages, it may not begin until the end of the semicolon. But
>> that's a small detail, rarely relevant in real code. (For the record,
>> I'd have preferred if the scope of variables in C did not begin until
>> the end of the declaration / definition.)
>>
>> 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.
>
> 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.
OK. So there was a real language that worked that way, half a century ago.
>
> Now, you said real-world not mainstream, so all mine currently do that.
> Anything declared in a function body has function-wide scope, including
> to any depth of nested block.
>
I don't count your language as "real world". But if you prefer the term
"mainstream", I'll go along with that, and then skip your descriptions
of it. Note that Algol68 is not mainstream either (though it once was).
> Outside of a function, it has module-wide scope. If also declared
> 'global', it has sub-program-wide scope (although other modules can
> shadow it).
>
> Here, obviously, exactly where in a module a name has been defined, is
> irrelevant.
>
> In C, the same of thing happens when you introduced a forward
> declaration of a function: you move its lexical scope to near the top.
Yes, C is exactly the same but for the minor detail of being completely
different.
> In this case, it wouldn't be shadowing anything; there can't be anything
> at an outer scope. So there wouldn't be a problem in scope starting from
> the top of the file.
>
>> Perhaps you are mixing up "scope" and "lifetime" ? These are not the
>> same things.
>
> I'm talking about static, lexical code, which can be determined at
> compile-time.
Again, I think you are mixing up "scope" and "lifetime". Can you
demonstrate that you understand the difference? It would be
particularly nice if you could show you know the difference for local
variables in C.
>> C labels are unstructured. This is not a good thing in a programming
>> language - it is an unfortunate necessary evil.
>
> A good thing in this case; imagine the same L23 label occurring half a
> dozen times in the same function, even if labels had block scopes.
>
Imagine, instead, that most people who program know how to write
sensible code. Not everyone does, but most people do. Worrying about
how badly people could misuse any given feature is not helpful, and of
course there are endless ways to write terrible code using your language
or any other language.
If I told you I like the green colour of my car, you'd tell me that your
car is red, and red is the only good colour for a car. After all, if
green aliens hid my car in a field of broccoli and surrounded it with
green frogs it would be hard to find, while your red car would be
clearly visible.
Please cut down on the inane straw man arguments.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-19 18:47 +0100 |
| Message-ID | <10ui7n3$3eguh$1@dont-email.me> |
| In reply to | #399178 |
On 19/05/2026 17:48, David Brown wrote:
> On 19/05/2026 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.
>>
>> 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.
>
> OK. So there was a real language that worked that way, half a century ago.
While I don't care for it, a LOT of thought went into its design, by
some very clever people.
>>
>> Now, you said real-world not mainstream, so all mine currently do
>> that. Anything declared in a function body has function-wide scope,
>> including to any depth of nested block.
>>
>
> I don't count your language as "real world". But if you prefer the term
> "mainstream", I'll go along with that, and then skip your descriptions
> of it.
You would dismiss potentially good ideas for petty reasons?
There is a fuzzy area in programming lanuages when you declare things in
the middle of a block.
You declare X in the middle, and its scope lasts until the end of the
block. But that happens between the start of the block and its declaration?
If this new X is not visible, then what happens if you try and use 'X'?
Apparently in C, you just get whatever outer X happens to be visible
from an outer scope. There are other choices, including hiding outer Xs
but now allowing you to access this new X either.
If you want the current behaviour, you can create a new {} block, then
there are fewer surprises.
>> In C, the same of thing happens when you introduced a forward
>> declaration of a function: you move its lexical scope to near the top.
>
> Yes, C is exactly the same but for the minor detail of being completely
> different.
So, having functions, variables, types and macro generally declared near
the top of a source file, has no similarity with declaring local
variables near the top of a function?
OK..
>>> Perhaps you are mixing up "scope" and "lifetime" ? These are not the
>>> same things.
>>
>> I'm talking about static, lexical [scope], which can be determined at
>> compile-time.
>
> Again, I think you are mixing up "scope" and "lifetime".
I think you are. I said this can be determined at /compile-time/. It is
purely to do with visibility from a particular spot in source code.
> Can you
> demonstrate that you understand the difference? It would be
> particularly nice if you could show you know the difference for local
> variables in C.
Why don't you explain the difference?
> Imagine, instead, that most people who program know how to write
> sensible code.
I suspect I've seen more reams of nightmare C source code than you have.
> Not everyone does, but most people do. Worrying about
> how badly people could misuse any given feature is not helpful,
People like to push languages to the limits. They like to show off and
be clever. They will abuse any feature.
> and of
> course there are endless ways to write terrible code using your language
> or any other language.
In my language they can't have have 64 variations of the same 'abcdef'
identifier IN THE SAME SCOPE by varying case. They can't have unlimited
unrelated instances of even the exact same 'abcdef' identifier IN THE
SAME FUNCTION, thanks to block scope.
They can't have one block sharing two instances of the same 'abcdef'
name with the second being declared part-way through.
There's only one 'abcdef' identifier per function, whatever case mix is
used, and that's your lot.
Sure, they can /deliberately/ write bad code in my language, but they
have to work much harder than in C, where you can do it without trying.
> If I told you I like the green colour of my car, you'd tell me that your
> car is red, and red is the only good colour for a car. After all, if
> green aliens hid my car in a field of broccoli and surrounded it with
> green frogs it would be hard to find, while your red car would be
> clearly visible.
And yet, my now white car (it used to be red), is next to impossible to
spot in a car-park where 50% of cars are white. I have to identify it
from the number-plate.
So if I told you that, I'd have a valid point.
(I still don't know why C has a separate namespace for labels.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-19 21:58 +0200 |
| Message-ID | <10uifdl$3gs6h$1@dont-email.me> |
| In reply to | #399181 |
On 19/05/2026 19:47, Bart wrote:
> On 19/05/2026 17:48, David Brown wrote:
>> On 19/05/2026 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.
>>>
>>> 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.
>>
>> OK. So there was a real language that worked that way, half a century
>> ago.
>
> While I don't care for it, a LOT of thought went into its design, by
> some very clever people.
And a lot of the very clever people that worked on the design of Algol68
concluded that in the end, the language was a disaster. Clever people
rarely agree - appeals to authority are not good arguments.
>
>>>
>>> Now, you said real-world not mainstream, so all mine currently do
>>> that. Anything declared in a function body has function-wide scope,
>>> including to any depth of nested block.
>>>
>>
>> I don't count your language as "real world". But if you prefer the
>> term "mainstream", I'll go along with that, and then skip your
>> descriptions of it.
>
> You would dismiss potentially good ideas for petty reasons?
>
No, but I think it's useful to know what features have been
battle-tested. (A single user of their own language does not count.)
> There is a fuzzy area in programming lanuages when you declare things in
> the middle of a block.
>
> You declare X in the middle, and its scope lasts until the end of the
> block. But that happens between the start of the block and its declaration?
If you understood the difference between lifetime and scope, you might
know. The details may differ between languages - obviously it is C that
is important here. The lifetime of a local variable (excluding VLAs) in
C begins when the block containing it is entered, and ends at the end of
the block. The scope begins at the declaration of the variable and ends
at the end of the enclosing block. Usually this does not make much
difference, but it can be relevant if you use goto and jump earlier in
the block.
(There is also the difference that when you call a function inside the
scope of a local variable, the variable's lifetime continues but it is
not in the scope of the called function - hopefully that is obvious.)
>
> If this new X is not visible, then what happens if you try and use 'X'?
If it has been assigned a value at some point, then you can use it (but
not via the name). Scoping is about the name, lifetime is about the
object itself.
>
> Apparently in C, you just get whatever outer X happens to be visible
> from an outer scope.
Yes. That is how scopes work.
> There are other choices, including hiding outer Xs
> but now allowing you to access this new X either.
>
A language could make that choice, but it is common in compiled
imperative languages for local scopes to overrule outer scopes.
Otherwise adding a new file-scope variable could break existing working
functions, which would be a daft idea.
> If you want the current behaviour, you can create a new {} block, then
> there are fewer surprises.
>
You are not making sense. If you are surprised by having a new variable
declaration hide the scope of an outer scope variable, why would it be
more or less of a surprise depending on the braces?
>>> In C, the same of thing happens when you introduced a forward
>>> declaration of a function: you move its lexical scope to near the top.
>>
>> Yes, C is exactly the same but for the minor detail of being
>> completely different.
>
> So, having functions, variables, types and macro generally declared near
> the top of a source file, has no similarity with declaring local
> variables near the top of a function?
>
> OK..
You prefer to move the goalposts than to read my comment? You said that
C is just like your language in that you can define functions in any
order - as long as you put forward declarations at the top of the file.
The point is that in C, /declarations/ have scope extending from the
declaration, wherever that might be - scopes are not global across the file.
>
>>>> Perhaps you are mixing up "scope" and "lifetime" ? These are not
>>>> the same things.
>>>
>>> I'm talking about static, lexical [scope], which can be determined at
>>> compile-time.
>>
>> Again, I think you are mixing up "scope" and "lifetime".
>
> I think you are. I said this can be determined at /compile-time/. It is
> purely to do with visibility from a particular spot in source code.
>
Scope is a compile-time property of the name of a variable. Lifetime is
a run-time property of the object itself.
>> Can you demonstrate that you understand the difference? It would be
>> particularly nice if you could show you know the difference for local
>> variables in C.
>
> Why don't you explain the difference?
>
See above. Or, perhaps, shock everyone by looking in the C standards.
>> Imagine, instead, that most people who program know how to write
>> sensible code.
>
> I suspect I've seen more reams of nightmare C source code than you have.
>
Try waking up. I am getting tired of your imagined horrors that C
allows, while pretending that your own language does not allow bad code.
And I'm tired of your cherry-picking the worst examples you can find.
Please do not respond by giving more of them.
>
>> Not everyone does, but most people do. Worrying about how badly
>> people could misuse any given feature is not helpful,
>
> People like to push languages to the limits. They like to show off and
> be clever. They will abuse any feature.
>
>> and of course there are endless ways to write terrible code using your
>> language or any other language.
>
> In my language they can't have have 64 variations of the same 'abcdef'
> identifier IN THE SAME SCOPE by varying case. They can't have unlimited
> unrelated instances of even the exact same 'abcdef' identifier IN THE
> SAME FUNCTION, thanks to block scope.
>
That's fantastic! Amazing! If only other language designers had a
fraction of your genius - then software bugs would be a thing of the past.
You have marginally reduced the possibility of certain kinds of errors
while simultaneously making it harder to write good code so we get other
errors instead.
> They can't have one block sharing two instances of the same 'abcdef'
> name with the second being declared part-way through.
>
> There's only one 'abcdef' identifier per function, whatever case mix is
> used, and that's your lot.
>
> Sure, they can /deliberately/ write bad code in my language, but they
> have to work much harder than in C, where you can do it without trying.
>
>> If I told you I like the green colour of my car, you'd tell me that
>> your car is red, and red is the only good colour for a car. After
>> all, if green aliens hid my car in a field of broccoli and surrounded
>> it with green frogs it would be hard to find, while your red car would
>> be clearly visible.
>
> And yet, my now white car (it used to be red), is next to impossible to
> spot in a car-park where 50% of cars are white. I have to identify it
> from the number-plate.
>
> So if I told you that, I'd have a valid point.
>
> (I still don't know why C has a separate namespace for labels.)
There's a lot you don't know about C. (Some of it, of course, doesn't
matter. But it's strange how you wear your ignorance like a merit badge
while simultaneously claiming to be an expert in language design who has
implemented a C compiler.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-19 22:16 +0100 |
| Message-ID | <10uijv9$3i6dl$1@dont-email.me> |
| In reply to | #399182 |
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. > But it's strange how you wear your ignorance like a merit badge > while simultaneously claiming to be an expert in language design Implementing C's three namespaces doesn't require knowing why they exist, only that they do. Plus of course an infinite number of block scopes in a language which averages 3 local variables per function. > who has > implemented a C compiler.) I implemented a C-subset compiler in 2017 (written in a language I designed and implemented) which was tested on some half million lines of open source C code, much of it brutal. That actually taught me quite a lot, but mostly that C was an even worse language than I'd thought. I also got to see a LOT of ugly code. The code it processes is definitely C. I'm not sure why you say I'm claiming to have written one; you don't believe me? OK. I can see why it might annoy some people here.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-20 08:59 +0200 |
| Message-ID | <10ujm3r$3pnbb$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: > >>> (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. I don't know for sure - but I don't care that they are in separate namespaces, and I don't care about why other than for curiosity. I think any code for which it matters, and code shares the same identifier for a label and a variable, is hopelessly badly written or extremely niche. 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. > >> But it's strange how you wear your ignorance like a merit badge while >> simultaneously claiming to be an expert in language design > > Implementing C's three namespaces doesn't require knowing why they > exist, only that they do. Plus of course an infinite number of block > scopes in a language which averages 3 local variables per function. > Okay. > > >> who has implemented a C compiler.) > > I implemented a C-subset compiler in 2017 (written in a language I > designed and implemented) which was tested on some half million lines of > open source C code, much of it brutal. > > That actually taught me quite a lot, but mostly that C was an even worse > language than I'd thought. I also got to see a LOT of ugly code. > > The code it processes is definitely C. > > I'm not sure why you say I'm claiming to have written one; you don't > believe me? OK. > I find it hard to reconcile accurately writing a C compiler with your misconceptions and misunderstandings about the language, and your reluctance to actually look at how the language is defined. I believe you have written a compiler that compiles the language you think C is, and that is a close enough match to C for it to work (or appear to work) with a fair bit of C code. I have no doubt that it works fine for the C code you personally write or generate. > I can see why it might annoy some people here.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-20 14:20 +0100 |
| Message-ID | <10ukcf2$dis$1@dont-email.me> |
| In reply to | #399206 |
On 20/05/2026 07:59, David Brown 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:
>>
>>>> (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.
>
> I don't know for sure - but I don't care that they are in separate
> namespaces, and I don't care about why other than for curiosity. I
> think any code for which it matters, and code shares the same identifier
> for a label and a variable, is hopelessly badly written or extremely
> niche.
So it /is/ pointless to have that separate namespace.
> 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.
Is this what people here like to call a 'non sequitur'? Whether /you/
goto use it is not relevant. If I test some codebases (not many are kept
lying around these days):
SQLite3 645 gotos
Lua 5.4 40
Tiny C 300
MZLib 40
bcc 9000 (when transpiled to low-level C)
Linux kernel 150000 (iirc)
(The low-level C has no high-level control flow, only goto and if-goto.
The Linux figure is from some years ago when the line count was only
21MLoc, and it was estimated via string processing, not actual compilation.)
>> I'm not sure why you say I'm claiming to have written one; you don't
>> believe me? OK.
>>
>
> I find it hard to reconcile accurately writing a C compiler with your
> misconceptions and misunderstandings about the language, and your
> reluctance to actually look at how the language is defined.
There are lots of different qualities of general purpose C compilers, if
you look outside the big 3 (gcc, clang, msvc).
I used to use DMC, Pelles C, lccwin32 extensively, and still use Tiny C.
There are also lots of lesser known ones that don't pretend to be full,
conforming implementations. Pico C for example (an interpreter); Smlr C;
Small C; I forget the names.
The point is that there are a vast number of products that purport to
run or compile C code.
Mine is just another one of those, and these days has a number of
use-cases outside of just compiling C (including quickly doing ad hoc
surveys).
> I believe
> you have written a compiler that compiles the language you think C is,
> and that is a close enough match to C for it to work (or appear to work)
> with a fair bit of C code.
Yes. Especially C90 applications such as Lua source code. But since 2017
a lot more open source code has started to use C99 features I did't
support, such as compound literals, designated initialisers, runtime
expressions in {...} initialisers, VLAs and so on.
I'm not planning to support those; many are poorly documented IMO and
unintuitive to understand, hard to implement, and may have hidden depths
of complexity.
> I have no doubt that it works fine for the C
> code you personally write or generate.
It works perfectly, except that it targets x64 with Win64 ABI, and
doesn't optimise. It's when I want to target non-Windows OSes, and/or
have optimised code, that I use the C transpiler!
However it is still useful as an instant test of the generated code,
which otherwise takes 30-40 times longer with gcc-O0.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-20 16:22 +0200 |
| Message-ID | <10ukg34$rn3$1@dont-email.me> |
| In reply to | #399214 |
On 20/05/2026 15:20, Bart wrote:
> On 20/05/2026 07:59, David Brown 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:
>>>
>>>>> (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.
>>
>> I don't know for sure - but I don't care that they are in separate
>> namespaces, and I don't care about why other than for curiosity. I
>> think any code for which it matters, and code shares the same
>> identifier for a label and a variable, is hopelessly badly written or
>> extremely niche.
>
> So it /is/ pointless to have that separate namespace.
I did not say that, and I can't fathom how you would conclude that -
either from your own lack of relevant knowledge, or from what I wrote.
I would imagine that having them as a separate namespace would be more
convenient in a compiler - the scoping and lookup rules are
significantly different from the namespace for variables and functions,
and having separate namespaces means compilers don't have to check for
conflicts. There may be other good reasons for the separation, or it
might be a historical artifact inherited from a predecessor language, or
it might be that the C designers preferred separate namespaces and would
only have combined them if they had good reason to do so.
>
>> 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.
>
> Is this what people here like to call a 'non sequitur'? Whether /you/
> goto use it is not relevant.
It is highly relevant to my "I don't care".
>
>
>> I believe you have written a compiler that compiles the language you
>> think C is, and that is a close enough match to C for it to work (or
>> appear to work) with a fair bit of C code.
>
> Yes. Especially C90 applications such as Lua source code. But since 2017
> a lot more open source code has started to use C99 features I did't
> support, such as compound literals, designated initialisers, runtime
> expressions in {...} initialisers, VLAs and so on.
>
> I'm not planning to support those; many are poorly documented IMO and
> unintuitive to understand, hard to implement, and may have hidden depths
> of complexity.
>
You can make up your own mind about how difficult these features are to
implement in your own compiler, though I question the reality of these
concerns - I think you just like to complain that they are hard. And
you can have the opinion that they are poorly documented, but we both
know the reality is that you haven't bothered to try to read the
documentation. The fact that people use these features should indicate
that they are well enough documented and understood for C programmers to
use. So are you trying to claim that you are particularly inept at
reading and understanding about C language features? I doubt that.
I'd be happier with an honest reason - such as you don't like these
features (for some non-technical reason), you don't find them useful
yourself (fair enough), and you therefore can't be bothered implementing
them in your own tools (again, fair enough). You made your C compiler
for fun, no one else uses it, and you have no obligations to anyone
else. It's entirely up to you to pick the features you choose to
support (as long as you don't make any claims to conformity). You don't
have to make up bullshit excuses for choosing not to implement C99 features.
>> I have no doubt that it works fine for the C code you personally
>> write or generate.
>
> It works perfectly, except that it targets x64 with Win64 ABI, and
> doesn't optimise. It's when I want to target non-Windows OSes, and/or
> have optimised code, that I use the C transpiler!
>
> However it is still useful as an instant test of the generated code,
> which otherwise takes 30-40 times longer with gcc-O0.
>
>
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-20 16:41 +0100 |
| Message-ID | <10ukknp$2umi$1@dont-email.me> |
| In reply to | #399215 |
On 20/05/2026 15:22, David Brown wrote:
> On 20/05/2026 15:20, Bart wrote:
>> On 20/05/2026 07:59, David Brown 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:
>>>>
>>>>>> (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.
>>>
>>> I don't know for sure - but I don't care that they are in separate
>>> namespaces, and I don't care about why other than for curiosity. I
>>> think any code for which it matters, and code shares the same
>>> identifier for a label and a variable, is hopelessly badly written or
>>> extremely niche.
>>
>> So it /is/ pointless to have that separate namespace.
>
> I did not say that, and I can't fathom how you would conclude that -
You said that code which depends on it is 'hopelessly badly written' or
'extremely niche'. That implies the vast majority of decent code will
never need that feature. Ergo it is pointless.
Unless you can think of a use-case where it would be essential?
> either from your own lack of relevant knowledge, or from what I wrote.
What exactly is lacking from that knowledge? Do you even know yourself?
> I would imagine that having them as a separate namespace would be more
> convenient in a compiler - the scoping and lookup rules are
> significantly different from the namespace for variables and functions,
> and having separate namespaces means compilers don't have to check for
> conflicts. There may be other good reasons for the separation, or it
> might be a historical artifact inherited from a predecessor language, or
> it might be that the C designers preferred separate namespaces and would
> only have combined them if they had good reason to do so.
Having such an extra namespace for labels because it makes a compiler
simpler does not make that useful for users.
Yes, maybe the namespace trick makes it a little simpler to check for
duplicates of labels and locals.
But it also relies on label names only appearing in certain contexts.
That means extensions such as gcc's label pointers need special syntax
such as &&L, whereas function names can become pointers without even one
'&' needed.
Example (using gnu extension):
void* P = &&fred;
goto *P;
puts("One");
fred:
puts("Two");
In my language:
ref label P := fred
goto P
println "One"
fred:
println "Two"
Cleaner code /because/ label names are not special. And more typesafe:
my language needs a label pointer; C is happy to jump to a float* pointer!
Oh, I forgot, C *must* be superior here because I know nothing about
these things. And you never use 'goto' anyway, not even computed goto,
so this is irrelevant to you.
>> I'm not planning to support those; many are poorly documented IMO and
>> unintuitive to understand, hard to implement, and may have hidden
>> depths of complexity.
>>
>
> You can make up your own mind about how difficult these features are to
> implement in your own compiler, though I question the reality of these
> concerns - I think you just like to complain that they are hard.
Try it yourself first then your opinions will carry more weight.
> And
> you can have the opinion that they are poorly documented, but we both
> know the reality is that you haven't bothered to try to read the
> documentation.
I have, that's why I can say they are poorly documented.
(A classic example is the C preprocessor, which is covered in a few
paragraphs, but a full treatment would need 20 pages. And it shows: in
2017 when I did my project, there were all kinds of corner cases
involving the preprocessor that would give different results in
different compilers.
Now they are more standardised, although I suspect that implementations
are sharing the one working version!)
> The fact that people use these features should indicate
> that they are well enough documented and understood for C programmers to
> use.
Sure, especially VLAs: most uses I've seen of these seem to be
inadvertent such as using N in 'const int N = 10' as the dimension.
Meanwhile, how many know that you can write:
{.p.y = 200, p.x = 100}
as well as:
{.p = {.x = 100, .y = 200}}
So to any depth, in any order and with any number of duplicates.
> So are you trying to claim that you are particularly inept at
> reading and understanding about C language features? I doubt that.
>
> I'd be happier with an honest reason - such as you don't like these
> features (for some non-technical reason), you don't find them useful
> yourself (fair enough),
These too.
> and you therefore can't be bothered implementing
> them in your own tools (again, fair enough). You made your C compiler
> for fun, no one else uses it, and you have no obligations to anyone
> else. It's entirely up to you to pick the features you choose to
> support (as long as you don't make any claims to conformity). You don't
> have to make up bullshit excuses for choosing not to implement C99
> features.
I remember it took quite a few years for C99 features to become
widespread. I imagine they would have been known about well in advance
of 1999 too.
So it can't have been that trivial.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-20 19:51 +0200 |
| Message-ID | <10uksag$63on$1@dont-email.me> |
| In reply to | #399221 |
On 20/05/2026 17:41, Bart wrote: > On 20/05/2026 15:22, David Brown wrote: >> On 20/05/2026 15:20, Bart wrote: >>> On 20/05/2026 07:59, David Brown 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: >>>>> >>>>>>> (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. >>>> >>>> I don't know for sure - but I don't care that they are in separate >>>> namespaces, and I don't care about why other than for curiosity. I >>>> think any code for which it matters, and code shares the same >>>> identifier for a label and a variable, is hopelessly badly written >>>> or extremely niche. >>> >>> So it /is/ pointless to have that separate namespace. >> >> I did not say that, and I can't fathom how you would conclude that - > > You said that code which depends on it is 'hopelessly badly written' or > 'extremely niche'. That implies the vast majority of decent code will > never need that feature. Ergo it is pointless. No. First, a niche use is not pointless. Second, there can be reasons for defining a language in a particular way, even if users never take advantage of it. It can, for example, mean the implementation is easier. That's the case for a fair amount of what you might call "compile-time undefined behaviour" in C - some things are defined the way they are because it makes it easier for the implementation. If local variables and labels shared the same name space, then compilers would have to check for conflicts - as it stands, they do not. > > Unless you can think of a use-case where it would be essential? > I can't think of one. But then, I almost never use labels and gotos. Maybe someone else can think of one. >> either from your own lack of relevant knowledge, or from what I wrote. > > What exactly is lacking from that knowledge? Do you even know yourself? > You don't know why the name spaces are separate. I don't know either, as I have said. >> I would imagine that having them as a separate namespace would be more >> convenient in a compiler - the scoping and lookup rules are >> significantly different from the namespace for variables and >> functions, and having separate namespaces means compilers don't have >> to check for conflicts. There may be other good reasons for the >> separation, or it might be a historical artifact inherited from a >> predecessor language, or it might be that the C designers preferred >> separate namespaces and would only have combined them if they had good >> reason to do so. > > Having such an extra namespace for labels because it makes a compiler > simpler does not make that useful for users. > So? Clearly, usefulness for users is more important than convenience for implementers. But if there is no harm to users either way, then simpler for implementers is a good idea. (Again, I do not know if there are other reasons for the separate name spaces. Maybe they do make things easier for users, or did so long ago when the design decision was made.) > Yes, maybe the namespace trick makes it a little simpler to check for > duplicates of labels and locals. > > But it also relies on label names only appearing in certain contexts. And that's fine. They can only appear in certain circumstances - preceding a colon to define the label, or as the subject of a "goto". > That means extensions such as gcc's label pointers need special syntax > such as &&L, whereas function names can become pointers without even one > '&' needed. Oddly enough, I don't think the original designers of the C language made their decisions based on what a future compiler would add as an extension. gcc label pointers have no relevance to this discussion. > >> And you can have the opinion that they are poorly documented, but we >> both know the reality is that you haven't bothered to try to read the >> documentation. > > I have, that's why I can say they are poorly documented. Really? Is this you finally saying you have read a part of one C standard version?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-20 21:14 +0100 |
| Message-ID | <10ul4ml$96it$1@dont-email.me> |
| In reply to | #399222 |
On 20/05/2026 18:51, David Brown wrote: > On 20/05/2026 17:41, Bart wrote: > First, a niche use is not pointless. A niche use that takes advantage of some accidental quirk in a language? One that wouldn't exist if the quirk wasn't there; that sort of niche use? Over 50 years of use, every misfeature of C has been exploited by /somebody/. One reason why the language couldn't properly evolve. > You don't know why the name spaces are separate. I don't know either, > as I have said. But I can have a good idea of the implications both by there being a separate namespace, or not. You snipped my example where it caused a limitation in the syntax. >> Yes, maybe the namespace trick makes it a little simpler to check for >> duplicates of labels and locals. >> >> But it also relies on label names only appearing in certain contexts. > > And that's fine. They can only appear in certain circumstances - > preceding a colon to define the label, or as the subject of a "goto". As I said, limitations; 'goto (L)' is not allowed, for example, but '(F)()' is as well as 'case (A):'. >> I have, that's why I can say they are poorly documented. > > Really? Is this you finally saying you have read a part of one C > standard version? I've read plenty of the standard especially in 2017. Information for implementing C and providing headers had to be gleaned from multiple sources. There is also testing: the C standard doesn't provide a test-suite to verify an implementation. Since then, then no, I don't routinely look inside it. So what? People can have opinions on languages, compare one to another, speculate on possible new features or modifying existing ones, etc, based on their long personal experiences as /users/. Some may also have experience as developers, and some even of developing languages in a similar field. I also admit my implementation was casual. I had a particular set of aims, which were largely achieved. (The first language I implemented, not one of mine, didn't have a formal standard. You just picked it up from examples. But it was also a machine-oriented language, so it was adapted to the target to a certain extent. That also was the case for other languages I used in the 70s, in that the implementation for a particular platform became the standard, and you used reference manuals for that version. TLDR: you guys place too much importance on 'the C standard', and mainly use it to batter me over the head with. You don't 'own' C. There is no copyright on it. Anyone can use it as casually or as intensely as they like. Anyone can choose to create as professional or as casual a version as they like. Anyone choose to pontificate on things they like or dislike. Anyone can choose to fork C and create a language that is slightly different, or a lot different, but they would ideally make that clear. Hmm, still a bit long! In that case: TLDR: I like to deal with C casually (like every language I use). If you don't like it, then too bad.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-21 08:45 +0200 |
| Message-ID | <10um9mn$hnok$2@dont-email.me> |
| In reply to | #399224 |
On 20/05/2026 22:14, Bart wrote: > On 20/05/2026 18:51, David Brown wrote: >> On 20/05/2026 17:41, Bart wrote: > >> First, a niche use is not pointless. > > A niche use that takes advantage of some accidental quirk in a language? > One that wouldn't exist if the quirk wasn't there; that sort of niche use? > > Over 50 years of use, every misfeature of C has been exploited by / > somebody/. One reason why the language couldn't properly evolve. > So do you have an example of where code has been written to take advantage of the separate name spaces? I don't - I merely can't rule out niche cases. I could imagine some situations - perhaps from machine or human translation from other languages, or old implementations with very short identifier lengths. You seem obsessed with calling every aspect of C a "misfeature". This is, IMHO, neither a feature nor a misfeature of the language - it is basically irrelevant to almost everyone. I don't know why it upsets you so much. The C language /has/ evolved, and has evolved some features that are mostly liked, a few that are disliked by many, and others that some people like and some dislike. But it certainly evolves slowly - the standards committee have a strong commitment to backwards compatibility of code and to keeping the language stable, only making changes when there are very significant benefits. Their aim is not to make a "perfect" language or a language for all purposes - rather, it is simply to let people continue to use C for purposes for which C works well. When you have a home-made language and are the language designer, compiler implementer, and sole user, you can muck around with the language as you choose - changing things daily. You don't have to consider other users. Real-world (sorry, "mainstream") languages are not like that. >> You don't know why the name spaces are separate. I don't know either, >> as I have said. > > But I can have a good idea of the implications both by there being a > separate namespace, or not. You snipped my example where it caused a > limitation in the syntax. > Yes, it was irrelevant. >>> Yes, maybe the namespace trick makes it a little simpler to check for >>> duplicates of labels and locals. >>> >>> But it also relies on label names only appearing in certain contexts. >> >> And that's fine. They can only appear in certain circumstances - >> preceding a colon to define the label, or as the subject of a "goto". > > As I said, limitations; 'goto (L)' is not allowed, for example, but '(F) > ()' is as well as 'case (A):'. > And I can't fit my car in my bedroom cupboard. I don't consider that a limitation of my choice of car. >>> I have, that's why I can say they are poorly documented. >> >> Really? Is this you finally saying you have read a part of one C >> standard version? > > I've read plenty of the standard especially in 2017. Information for > implementing C and providing headers had to be gleaned from multiple > sources. There is also testing: the C standard doesn't provide a test- > suite to verify an implementation. > All the features you have whined about as "poorly documented" are documented in the standards. There are also countless other perfectly good resources around describing how to use them. (For an implementation, you need to read the standard in detail - for using them, tutorials or other references are usually fine for sensible use.) The C standards are standards, not test suites. There are plenty of test suites and conformance tests available for C compilers - most cost money, or are written in connection with compilers. > Since then, then no, I don't routinely look inside it. > > So what? People can have opinions on languages, compare one to another, > speculate on possible new features or modifying existing ones, etc, > based on their long personal experiences as /users/. > You can have an opinion from ignorance, as many people have told you. You can't expect that opinion to be respected. > Some may also have experience as developers, and some even of developing > languages in a similar field. > > I also admit my implementation was casual. I had a particular set of > aims, which were largely achieved. > OK. And that's fine. I've no problem with that. I have a problem with you then using it as evidence that you are an expert on languages, compilers or C. > (The first language I implemented, not one of mine, didn't have a formal > standard. You just picked it up from examples. But it was also a > machine-oriented language, so it was adapted to the target to a certain > extent. > > That also was the case for other languages I used in the 70s, in that > the implementation for a particular platform became the standard, and > you used reference manuals for that version. > > > TLDR: you guys place too much importance on 'the C standard', and mainly > use it to batter me over the head with. > C is a language defined by the standards. That makes the standards important. > You don't 'own' C. There is no copyright on it. Anyone can use it as > casually or as intensely as they like. Anyone can choose to create as > professional or as casual a version as they like. Anyone choose to > pontificate on things they like or dislike. The C23 draft open on my desktop at the moment says "© ISO 2024 - All rights reserved" on every page. It /is/ copyrighted, and it is a defined and standardised language. People are free to write C code however they want. They are free to write compilers for C. They can write a compiler for a language somewhat like C, but not fully. But if they try to give the impression that it is a "C compiler" - especially if they imply it conforms to a particular standard - then we are free to call them out. > > Anyone can choose to fork C and create a language that is slightly > different, or a lot different, but they would ideally make that clear. > Yes - if they make it clear that the language is not C. > Hmm, still a bit long! In that case: TLDR: I like to deal with C > casually (like every language I use). If you don't like it, then too bad. > I've no problem with people treating C casually. But I /do/ have a problem with people claiming C is something that it is not, or deliberately lying about it or misrepresenting it (or anything else - it just happens that C is the topic of this newsgroup). Getting things wrong is not lying - continuing to repeat the misinformation when you have been corrected is lying.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-21 12:56 +0100 |
| Message-ID | <10umrua$nckr$1@dont-email.me> |
| In reply to | #399239 |
On 21/05/2026 07:45, David Brown wrote: > On 20/05/2026 22:14, Bart wrote: >> On 20/05/2026 18:51, David Brown wrote: >>> On 20/05/2026 17:41, Bart wrote: >> >>> First, a niche use is not pointless. >> >> A niche use that takes advantage of some accidental quirk in a >> language? One that wouldn't exist if the quirk wasn't there; that sort >> of niche use? >> >> Over 50 years of use, every misfeature of C has been exploited by / >> somebody/. One reason why the language couldn't properly evolve. >> > > So do you have an example of where code has been written to take > advantage of the separate name spaces? No. This is why I claimed it was pointless. (I did do a survey of my codebases to find examples of label names shadowing local identifiers, but found no instances. I didn't post the results (afaicr) since the code sample was too small, but it would be a massive job to do a bigger test.) > I don't - I merely can't rule > out niche cases. I could imagine some situations - perhaps from machine > or human translation from other languages, or old implementations with > very short identifier lengths. Yeah, a C implementation that only has 'a' to 'z' variables, but also has a separate set of 'a' to 'z' labels! > You seem obsessed with calling every aspect of C a "misfeature". Yes, it is astounding how much there is. Some can be excused due to its age, but also lots could have been fixed long ago. Some of it is an actual nuisance, but quite a bit is also aesthetically displeasing. You didn't like my example of being able to write '(F)(x)' (or 'int (a);') but not 'goto (L)', but the anomaly is there. There is also not being able to write 'L:}'; this one bites. >> But I can have a good idea of the implications both by there being a >> separate namespace, or not. You snipped my example where it caused a >> limitation in the syntax. >> > > Yes, it was irrelevant. And it's irrelevant because? It was a minor consequence due to restrictions on where labels can appear, in turn due to not sharing the same namespace as ordinary identifiers. Irrelevant because it's part of a language extension? Those tend to become standard. > You can have an opinion from ignorance, as many people have told you. > You can't expect that opinion to be respected. That's just rubbish, and an attempt to stifle criticism. Somebody asks why do I have to do X and not Y? Y makes more sense, it is easier etc. The response here will be because the Standard says so. End of discussion. Somebody was able to voice that opinion using their own experience and common sense. It may be valid; maybe other languages do do Y instead of X. However all anyone here wants to suggest that that person is ignorant because they haven't read the standard. Well, they might read the standard then find that Y is still better! >> You don't 'own' C. There is no copyright on it. Anyone can use it as >> casually or as intensely as they like. Anyone can choose to create as >> professional or as casual a version as they like. Anyone choose to >> pontificate on things they like or dislike. > > The C23 draft open on my desktop at the moment says "© ISO 2024 - All > rights reserved" on every page. It /is/ copyrighted, and it is a > defined and standardised language. The standards document itself might be copyrighted, not the language.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-21 14:55 +0200 |
| Message-ID | <10umvcu$obiv$1@dont-email.me> |
| In reply to | #399243 |
On 21/05/2026 13:56, Bart wrote:
> On 21/05/2026 07:45, David Brown wrote:
>> On 20/05/2026 22:14, Bart wrote:
>>> On 20/05/2026 18:51, David Brown wrote:
>>>> On 20/05/2026 17:41, Bart wrote:
>>>
>>>> First, a niche use is not pointless.
>>>
>>> A niche use that takes advantage of some accidental quirk in a
>>> language? One that wouldn't exist if the quirk wasn't there; that
>>> sort of niche use?
>>>
>>> Over 50 years of use, every misfeature of C has been exploited by /
>>> somebody/. One reason why the language couldn't properly evolve.
>>>
>>
>> So do you have an example of where code has been written to take
>> advantage of the separate name spaces?
>
> No. This is why I claimed it was pointless.
>
> (I did do a survey of my codebases to find examples of label names
> shadowing local identifiers, but found no instances. I didn't post the
> results (afaicr) since the code sample was too small, but it would be a
> massive job to do a bigger test.)
So in conclusion, we have not seen a case where people have had the same
identifier as a label and a variable, typedef or function name. But we
can't rule out the possibility. It is certainly feasible that it
happens sometimes by accident or coincidence.
(The separation of the struct/union/enum tag name space from variable
namespace /is/ a feature that people use - it is not uncommon to see
"struct thing thing;" in code, whether or not either of us thinks it is
clear coding. And separate name spaces for the members of each struct
or union is trivially useful.)
We have no idea of a user benefit from /not/ having separate name spaces
here. (gcc's extension to let you take the value of a label with the &&
operator is orthogonal to the separation of the name spaces.)
As far as we can see, it does not make a difference to users one way or
the other. But I can easily see how it might be convenient for
implementers.
So are you justified in claiming it is pointless? No, you are not -
because we haven't ruled out any possibility of user benefits, there is
a definite implementer benefit, and having the opposite choice would be
less likely to be of any benefit to anyone. But I think we can
reasonably say it is a very minor matter that makes little practical
difference to anyone.
>
>> I don't - I merely can't rule out niche cases. I could imagine some
>> situations - perhaps from machine or human translation from other
>> languages, or old implementations with very short identifier lengths.
>
> Yeah, a C implementation that only has 'a' to 'z' variables, but also
> has a separate set of 'a' to 'z' labels!
>
>> You seem obsessed with calling every aspect of C a "misfeature".
>
> Yes, it is astounding how much there is. Some can be excused due to its
> age, but also lots could have been fixed long ago.
>
> Some of it is an actual nuisance, but quite a bit is also aesthetically
> displeasing.
>
> You didn't like my example of being able to write '(F)(x)' (or 'int
> (a);') but not 'goto (L)', but the anomaly is there.
>
Your example was pointless. The fact that function names in C act as
pointers and can be used in expressions, and that expressions evaluating
to function pointers can be used to call functions, does not mean people
typically go around writing "(printf)("hello");". Disallowing
parentheses around the function name, on the other hand, would require
additional rules in the grammar of C - so it would not make sense to
disallow it. Similarly, the extra parentheses in "int (a);" are allowed
because parentheses can be useful in complex declarations (perhaps
mixing pointers, arrays, and function types) - disallowing them in some
circumstances would complicate the grammar of the language.
But labels are inherently simpler - you can only "goto" directly to a
defined label. Parentheses could be of no benefit, so /allowing/ them
would complicate the grammar.
It is not an anomaly when very different things have different rules.
> There is also not being able to write 'L:}'; this one bites.
I don't see why that "bites", unless it is some weird smiley. I would
expect most people to have a the close brace on a separate line from the
label, but it is legitimate for people to want to jump to the end of a
block.
>
>
>>> But I can have a good idea of the implications both by there being a
>>> separate namespace, or not. You snipped my example where it caused a
>>> limitation in the syntax.
>>>
>>
>> Yes, it was irrelevant.
>
> And it's irrelevant because? It was a minor consequence due to
> restrictions on where labels can appear, in turn due to not sharing the
> same namespace as ordinary identifiers.
>
It was irrelevant because it is not relevant to standard C, but mostly
because it is not relevant to the dead horse we've been flogging. gcc
has a syntax to take the address of a label - it uses "&&label". The
choice of syntax is not in any way related to the name spaces. Or do
you think that labels should automatically be treated as constants of
type "void *" ? Getting the "value" of a label is a highly unusual
situation - but it's useful in things like byte-code interpreters. It
/should/ involve a special syntax that is clearly recognisable.
> Irrelevant because it's part of a language extension? Those tend to
> become standard.
No, most language extensions do not become standard. This one has been
in gcc for maybe three decades or more, and is not part of the standard.
>
>
>> You can have an opinion from ignorance, as many people have told you.
>> You can't expect that opinion to be respected.
>
> That's just rubbish, and an attempt to stifle criticism.
No, it is perfectly true.
>
> Somebody asks why do I have to do X and not Y? Y makes more sense, it is
> easier etc.
That's okay as far as it goes, but is missing context. Y makes more
sense /to you/. Y makes more sense /for your specific needs/. Y makes
more sense /in your personal language/. Your opinions and preferences
are not fact, and your likes and dislikes do not generalise to all
programmers and all languages.
>
> The response here will be because the Standard says so. End of discussion.
>
In issues of facts about the C language, yes. You are free to like or
dislike something the standard says, but not to pretend it doesn't say
what it does.
> Somebody was able to voice that opinion using their own experience and
> common sense. It may be valid; maybe other languages do do Y instead of X.
>
> However all anyone here wants to suggest that that person is ignorant
> because they haven't read the standard. Well, they might read the
> standard then find that Y is still better!
>
As many people have told you countless times, pretty much everybody has
dislikes about some aspects of C. We all have things that we think
would have been better if they had been different. That does not in any
way change what C /is/, or how the language is defined.
As has been said, "There are two kinds of languages - the ones people
complain about, and the ones nobody uses".
>
>>> You don't 'own' C. There is no copyright on it. Anyone can use it as
>>> casually or as intensely as they like. Anyone can choose to create as
>>> professional or as casual a version as they like. Anyone choose to
>>> pontificate on things they like or dislike.
>>
>> The C23 draft open on my desktop at the moment says "© ISO 2024 - All
>> rights reserved" on every page. It /is/ copyrighted, and it is a
>> defined and standardised language.
>
> The standards document itself might be copyrighted, not the language.
>
The point of a language standard, and a language that has a standard, is
that the standard defines the language. No one is likely to sue you for
copyright infringement if you use the term "C" to refer to a different
language, but it's not helpful to any discussion.
[toc] | [prev] | [next] | [standalone]
Page 3 of 13 — ← Prev page 1 2 [3] 4 5 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web