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-06-12 06:05 +0100 |
| Articles | 20 on this page of 250 — 21 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: switch/extension for see below strongly needed Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-06-12 06:15 +0100
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
Re: switch/extension for see below strongly needed Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-06-12 06:05 +0100
Page 1 of 13 [1] 2 3 … 13 Next page →
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-05-17 00:03 +0200 |
| Subject | switch/extension for see below strongly needed |
| Message-ID | <10uapjs$19723$1@dont-email.me> |
the fact that in c a language/compiler sees only functions or variables that are up in code is a disaster it is a disaster becouse it dont alow you to split code on N files each file has realted functions and variables and not to care on the global order of it you should not care becouse it has no sense those separate files are then like in parralel dimensions and that is good (they will not go in conflict as it had to have unique names anyway) the thing that yu need to care is some kind of bad annoying design flaw as those historic goto abuse or other like that So the solution is give at least compiler extension that would allow you to have it changed that it see up and down the fact thet this switch is not present is another flaw..so you have two flaws here
[toc] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-17 01:08 +0100 |
| Message-ID | <10ub0u0$1anme$1@dont-email.me> |
| In reply to | #399062 |
On 16/05/2026 23:03, fir wrote: > the fact that in c a language/compiler sees only functions or variables > that are up in code is a disaster > > it is a disaster becouse it dont alow you to split code on N files > each file has realted functions and variables and not to care on the > global order of it > I mentioned something like this a week ago, suggesting that in C it was harder work than necessary to split one source file up into two or more. However, some of the regulars here seemed to think it was a non-problem: Keith Thompson: >If you have something to say about splitting a C translation unit (something I don't think I've ever had a need to do), perhaps because you've had difficulties doing so yourself, feel free to elaborate. Scott Lurndal: >I don't recall refactoring existing code, primarily because the original programmers used multiple translation units logically dividing the code into functionly related segments, where necessary, from the start. Tim Rentch: >Having said that, I don't remember it ever being a big deal. If some source file needs to be subdivided, you simply subdivide it and move on. Somebody never had to do it; somebody else said they get the perfect split right from the start; and yet another said it was not a big deal. So nobody is that bothered (or people are just conditioned to oppose anything I say). > you should not care becouse it has no sense those separate files are > then like in parralel dimensions and that is good (they will not go in > conflict as it had to have unique names anyway) > > the thing that yu need to care is some kind of bad annoying design flaw > as those historic goto abuse or other like that > > So the solution is give at least compiler extension that would allow you > to have it changed that it see up and down > > the fact thet this switch is not present is another flaw..so you have > two flaws here The context a week ago was that a module scheme would make refactoring across files simpler. But you still need to manage visibility across the new set of files. Adding such a scheme to C would be a huge change. However, doing away with forward references for functions within one file, so that no local prototypes are needed, is doable and would be a significant convenience.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-16 18:21 -0700 |
| Message-ID | <10ub56e$1bupb$1@kst.eternal-september.org> |
| In reply to | #399065 |
Bart <bc@freeuk.com> writes:
> On 16/05/2026 23:03, fir wrote:
>> the fact that in c a language/compiler sees only functions or
>> variables that are up in code is a disaster
>> it is a disaster becouse it dont alow you to split code on N files
>> each file has realted functions and variables and not to care on the
>> global order of it
>
> I mentioned something like this a week ago, suggesting that in C it
> was harder work than necessary to split one source file up into two or
> more.
And you offered no evidence for your claim, not even telling us
that you had tried it and found it difficult.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-17 12:16 +0100 |
| Message-ID | <10uc81u$1kd2r$1@dont-email.me> |
| In reply to | #399066 |
On 17/05/2026 02:21, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 16/05/2026 23:03, fir wrote:
>>> the fact that in c a language/compiler sees only functions or
>>> variables that are up in code is a disaster
>>> it is a disaster becouse it dont alow you to split code on N files
>>> each file has realted functions and variables and not to care on the
>>> global order of it
>>
>> I mentioned something like this a week ago, suggesting that in C it
>> was harder work than necessary to split one source file up into two or
>> more.
>
> And you offered no evidence for your claim, not even telling us
> that you had tried it and found it difficult.
Everyone here will know what is involved. But nobody wants to admit that
it can be onerous.
Here is a very simple example of one 'module', which involves two source
files, 'a.h' and 'a.c':
====================
//a.h:
T C();
T D();
====================
// a.c:
#include a.h
static T A();
static T B();
static T E();
static T F();
T A(){}
T B(){}
T C(){}
T D(){}
T E(){}
T F(){}
====================
In this file, let's say that each function can call any other, so that
those forward declarations are needed. Two functions are also exported
to other 'source files'.
Suppose now I want to split 'a.c' into two files, a.c and b.c, exactly
in the middle so that A B C stay in a.c, and D E F go in b.c. You now
have to shuffle things around like this, ending up with 4 source files:
====================
//a.h:
T A();
T B();
T C();
====================
//a.c:
#include a.h
#include b.h
T A(){}
T B(){}
T C(){}
====================
//b.h:
T D()
T E()
T F()
====================
//b.c:
#include a.h
#include b.h
T D(){}
T E(){}
T F(){}
====================
I've kept it simple by having only functions, and ignoring variables,
types, enumerations, macros and #includes (maybe some functions need
that include, but not all).
Other files that previously included 'a.h', /may/ now also need 'b.h'
(if they call D, E or F). Or maybe they can drop 'a.h' if they don't
call A, B or C).
There may also be new global name clashes to sort out, say if A() was
already exported from elsewhere.
So, it's a bit messy. In my language with its module scheme, the
equivalent 'a' module might be:
====================
#a.m:
func A:T = end # (real code needs a suitable return value)
func B:T = end
global func C:T = end
global func D:T = end
func E:T = end
func F:T = end
====================
After the same split, you get these two files instead of one:
====================
#a.m:
global func A:T = end
global func B:T = end
global func C:T = end
====================
#b.m:
global func D:T = end
global func E:T = end
global func F:T = end
====================
The lead module needs this line added to project info: "module b".
There could also be clashes here with an existing A() for example, which
can either be renamed, or namespace qualifiers used (needed at all
call-sites); or the two new modules can form their own private group.
(In that case, C and D need 'export' scope to be visible from outside as
before.)
In this languages, variables, types, enumerations and macro are handled
with the exact same mechanism.
So, yes, I believe a decent module scheme means stuff like this is less
work than in C.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-05-17 15:04 +0200 |
| Message-ID | <10ucedp$1m6a0$2@dont-email.me> |
| In reply to | #399074 |
Bart pisze:
> static T A();
> static T B();
> static T E();
> static T F();
>
> T A(){}
> T B(){}
> T C(){}
> T D(){}
imo the variables (call if file variables or block of code variables)
makes probably more problem than functions
good way of design is imo to have few functions and variables/arrays who
work on this together - like in small c file...in another file you make
another set of functions and variables...bad design is to split those
variables out of its functions, and today i would need move the
variables like up (enforcing BAD DESIGN) of make extern declarations for
visibility (enforcing even more BAD DESIGN imo) it also involves CODE
JUMPING which is BAD
solution - add this f**kin switch to compiler...what i said is
mathematical (logical) proof its bad design
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-05-17 15:08 +0200 |
| Message-ID | <10uceko$1m6a0$3@dont-email.me> |
| In reply to | #399077 |
fir pisze:
> Bart pisze:
>> static T A();
>> static T B();
>> static T E();
>> static T F();
>>
>> T A(){}
>> T B(){}
>> T C(){}
>> T D(){}
>
> imo the variables (call if file variables or block of code variables)
> makes probably more problem than functions
>
> good way of design is imo to have few functions and variables/arrays who
> work on this together - like in small c file...in another file you make
> another set of functions and variables...bad design is to split those
> variables out of its functions, and today i would need move the
> variables like up (enforcing BAD DESIGN) of make extern declarations for
> visibility (enforcing even more BAD DESIGN imo) it also involves CODE
> JUMPING which is BAD
>
> solution - add this f**kin switch to compiler...what i said is
> mathematical (logical) proof its bad design
facing such proof its totally not important if
Keith Thompson, Scott Lurndal, Tim Rentch have different opinion, a
proof is a proof
and either youre burdened with bad design or you at leas make compiler
switch to take it out your back/neck :/
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-05-17 06:48 -0700 |
| Message-ID | <86tss6gnah.fsf@linuxsc.com> |
| In reply to | #399074 |
Bart <bc@freeuk.com> writes: > On 17/05/2026 02:21, Keith Thompson wrote: > >> Bart <bc@freeuk.com> writes: >> >>> On 16/05/2026 23:03, fir wrote: >>> >>>> the fact that in c a language/compiler sees only functions or >>>> variables that are up in code is a disaster >>>> it is a disaster becouse it dont alow you to split code on N files >>>> each file has realted functions and variables and not to care on the >>>> global order of it >>> >>> I mentioned something like this a week ago, suggesting that in C it >>> was harder work than necessary to split one source file up into two or >>> more. >> >> And you offered no evidence for your claim, not even telling us >> that you had tried it and found it difficult. > > Everyone here will know what is involved. But nobody wants to admit > that it can be onerous. It could be onerous. The point is, in actual practice it almost never is onerous. > Here is a very simple example [...] The example is not evidence but a strawman argument. It just doesn't match the experience of actual practice of other C developers (speaking for myself, and other developers I have known personally, and the comments of other newsgroup folks who have participated in the conversation).
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2026-05-17 14:43 +0000 |
| Message-ID | <10uck6g$1mspc$1@dont-email.me> |
| In reply to | #399079 |
On Sun, 17 May 2026 06:48:06 -0700, Tim Rentsch wrote: > Bart <bc@freeuk.com> writes: > >> On 17/05/2026 02:21, Keith Thompson wrote: >> >>> Bart <bc@freeuk.com> writes: >>> >>>> On 16/05/2026 23:03, fir wrote: >>>> >>>>> the fact that in c a language/compiler sees only functions or >>>>> variables that are up in code is a disaster >>>>> it is a disaster becouse it dont alow you to split code on N files >>>>> each file has realted functions and variables and not to care on the >>>>> global order of it fir, "You are doing it wrong". >>>> I mentioned something like this a week ago, suggesting that in C it >>>> was harder work than necessary to split one source file up into two or >>>> more. Bart, in reality, a smart developer almost never has to "split one source file up into two or more". Instead, they /plan/ for isolation and encapsulation of the functional parts of their code, and /intentionally/ develop multiple source files from the start. That's the way professionals do it. You, for instance, might write the parser, calling external functions to generate output code. For your purposes, those external functions can be debugging stubs in a separate source or object module. Fir, OTOH, might write the code generator functions, with a simple debugging driver as a separate source or object module. Once both of you have tested your parts to success, you can combine your two works, with fir supplying the code generator and you the parser, to create a single compiler program. None of this has to be "onerous". The hard part is agreeing on the contract between your code and fir's code, and that's part of what a professional does /before/ (s)he starts coding. >>> And you offered no evidence for your claim, not even telling us >>> that you had tried it and found it difficult. >> >> Everyone here will know what is involved. But nobody wants to admit >> that it can be onerous. > > It could be onerous. The point is, in actual practice it almost > never is onerous. > >> Here is a very simple example [...] > > The example is not evidence but a strawman argument. It just > doesn't match the experience of actual practice of other C > developers (speaking for myself, and other developers I have > known personally, and the comments of other newsgroup folks who > have participated in the conversation). Agreed. Bart and fir have a "special" view of coding, which is at odds with my 30+ years experience in the profession (and my 20+ years of post-professional (amateur) programming. -- Lew Pitcher "In Skills We Trust" Not LLM output - I'm just like this.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-17 16:53 +0100 |
| Message-ID | <10ucoaj$1pflo$1@dont-email.me> |
| In reply to | #399081 |
On 17/05/2026 15:43, Lew Pitcher wrote: > On Sun, 17 May 2026 06:48:06 -0700, Tim Rentsch wrote: > >> Bart <bc@freeuk.com> writes: >> >>> On 17/05/2026 02:21, Keith Thompson wrote: >>> >>>> Bart <bc@freeuk.com> writes: >>>> >>>>> On 16/05/2026 23:03, fir wrote: >>>>> >>>>>> the fact that in c a language/compiler sees only functions or >>>>>> variables that are up in code is a disaster >>>>>> it is a disaster becouse it dont alow you to split code on N files >>>>>> each file has realted functions and variables and not to care on the >>>>>> global order of it > > fir, "You are doing it wrong". > >>>>> I mentioned something like this a week ago, suggesting that in C it >>>>> was harder work than necessary to split one source file up into two or >>>>> more. > > Bart, in reality, a smart developer almost never has to "split one source > file up into two or more". Instead, they /plan/ for isolation and encapsulation > of the functional parts of their code, and /intentionally/ develop > multiple source files from the start. That's the way professionals do it. > > You, for instance, might write the parser, calling external functions > to generate output code. For your purposes, those external functions > can be debugging stubs in a separate source or object module. > Fir, OTOH, might write the code generator functions, with a simple > debugging driver as a separate source or object module. Once both of > you have tested your parts to success, you can combine your two works, > with fir supplying the code generator and you the parser, to create a > single compiler program. None of this has to be "onerous". The hard > part is agreeing on the contract between your code and fir's code, and > that's part of what a professional does /before/ (s)he starts coding. None of that is about taking one source file and splitting it, or taking multiple sources and combining them, which is where module support would help. Your example is simply about modular programming. >>>> And you offered no evidence for your claim, not even telling us >>>> that you had tried it and found it difficult. >>> >>> Everyone here will know what is involved. But nobody wants to admit >>> that it can be onerous. >> >> It could be onerous. The point is, in actual practice it almost >> never is onerous. >> >>> Here is a very simple example [...] >> >> The example is not evidence but a strawman argument. It just >> doesn't match the experience of actual practice of other C >> developers (speaking for myself, and other developers I have >> known personally, and the comments of other newsgroup folks who >> have participated in the conversation). > > Agreed. Bart and fir have a "special" view of coding, which is > at odds with my 30+ years experience in the profession (and > my 20+ years of post-professional (amateur) programming. I can't speak for fir. But it is very common in my work to start with a module that does a specific job, and find it gets too large. Or I find it is really two or more kinds of tasks, or task that can be segregated. Both may demand a split. It is also common to find some modules end up with not much in them and can combined with each or each incorporated into another. Yet another situation is where certain modules export functions for an API, and it is convenient to combine all such functions into the same module. Or there might be a set of helper functions across modules, which can be combined into one support module. Or, I want to port my app to another OS, and decide to collect OS-specific routines into a dedicated OS-specific module which is easier to swap with another. Or I want to have multiple configurations of my app, and I want to arrange it so that, switching configuration means swapping one self-contained module for another. There, you want common functions to stay within the main program (so no duplication). An actual example from two of the my projects, is where I have a compiler and an assembler, both generate EXEs and initially maintained their own backends. I wanted them to share backend modules, but this meant a lot of refactoring so that the assembler backend didn't see references to the compiler front end and vice versa. But I guess no amount of examples will cut any ice because your experience is different, and that's the one that counts? You always know right from the start of any project exactly what needs to go where. So, if your project is 50Kloc, say, split over 50 modules and 1000 functions, you write all 50K lines, including all the functions, data types, global data, enumerations, imports, macros etc, before you even submit it to a compiler. Oh, you don't do that? So your projects can gradually evolve, converge and diverge, make 3 steps forward and two back, algorithms etc can change, just like everyone else's? But you still know the exact layout from the outset! Please accept that other people especially sole developers have different working practices.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-05-17 18:24 +0200 |
| Message-ID | <10ucq46$1q161$1@dont-email.me> |
| In reply to | #399081 |
Lew Pitcher pisze: > On Sun, 17 May 2026 06:48:06 -0700, Tim Rentsch wrote: > >> Bart <bc@freeuk.com> writes: >> >>> On 17/05/2026 02:21, Keith Thompson wrote: >>> >>>> Bart <bc@freeuk.com> writes: >>>> >>>>> On 16/05/2026 23:03, fir wrote: >>>>> >>>>>> the fact that in c a language/compiler sees only functions or >>>>>> variables that are up in code is a disaster >>>>>> it is a disaster becouse it dont alow you to split code on N files >>>>>> each file has realted functions and variables and not to care on the >>>>>> global order of it > > fir, "You are doing it wrong". > >>>>> I mentioned something like this a week ago, suggesting that in C it >>>>> was harder work than necessary to split one source file up into two or >>>>> more. > > Bart, in reality, a smart developer almost never has to "split one source > file up into two or more". Instead, they /plan/ for isolation and encapsulation > of the functional parts of their code, and /intentionally/ develop > multiple source files from the start. That's the way professionals do it. > > You, for instance, might write the parser, calling external functions > to generate output code. For your purposes, those external functions > can be debugging stubs in a separate source or object module. > Fir, OTOH, might write the code generator functions, with a simple > debugging driver as a separate source or object module. Once both of > you have tested your parts to success, you can combine your two works, > with fir supplying the code generator and you the parser, to create a > single compiler program. None of this has to be "onerous". The hard > part is agreeing on the contract between your code and fir's code, and > that's part of what a professional does /before/ (s)he starts coding. > >>>> And you offered no evidence for your claim, not even telling us >>>> that you had tried it and found it difficult. >>> >>> Everyone here will know what is involved. But nobody wants to admit >>> that it can be onerous. >> >> It could be onerous. The point is, in actual practice it almost >> never is onerous. >> >>> Here is a very simple example [...] >> >> The example is not evidence but a strawman argument. It just >> doesn't match the experience of actual practice of other C >> developers (speaking for myself, and other developers I have >> known personally, and the comments of other newsgroup folks who >> have participated in the conversation). > > Agreed. Bart and fir have a "special" view of coding, which is > at odds with my 30+ years experience in the profession (and > my 20+ years of post-professional (amateur) programming. > were talking here about pices of c code..name it c files for example say you have N of such pices - when i code my app i got the pices just as i sait ..one is for example setup_window.c another is timer.c another is blitter.c and so on each have set of functions and "global" variables related to them..mostly to them but some of them also may be accesed by other pices/files if you have such system that those functions in each pice see all other pieces up and down its ideal and proper situation becouse all thise files like orthogonal one to another and thus like separated only they see other by names adding a rigiud constrain that you must keep that files in artifical linear order from up to down ias absolute crazyy becuose 1) naturally given order dont exist 2) ist absolutly sill and tiresome to manage such stupid order its absolute FLAW and its a disaster bartc simplyhas a dose of intelligence to see it too (though such things some may see in different extent..with time im even more angry than before (when i was writing on this many years ago) c also has other flaws (also mentioned) - language should be designed such way not to make code jumping and unnecessary dependencies which kill codes making work on it more tiresome and stupid
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-17 17:56 +0100 |
| Message-ID | <10ucrv1$1qefe$1@dont-email.me> |
| In reply to | #399084 |
On 17/05/2026 17:24, fir wrote:
> Lew Pitcher pisze:
>> Agreed. Bart and fir have a "special" view of coding, which is
>> at odds with my 30+ years experience in the profession (and
>> my 20+ years of post-professional (amateur) programming.
>>
>
> were talking here about pices of c code..name it c files for example
>
> say you have N of such pices - when i code my app i got the pices just
> as i sait ..one is for example setup_window.c another is timer.c another
> is blitter.c and so on
>
> each have set of functions and "global" variables related to
> them..mostly to them but some of them also may be accesed by other
> pices/files
>
> if you have such system that those functions in each pice see all other
> pieces up and down its ideal and proper situation becouse all thise
> files like orthogonal one to another and thus like separated only they
> see other by names
>
>
> adding a rigiud constrain that you must keep that files in artifical
> linear order from up to down ias absolute crazyy becuose
>
> 1) naturally given order dont exist
> 2) ist absolutly sill and tiresome to manage such stupid order
C does allow you to have them in arbitrary order.
But it means writing and maintaining function prototypes at the top of
the file. That is what's tiresome.
>
> its absolute FLAW and its a disaster
>
> bartc simplyhas a dose of intelligence to see it too (though such things
> some may see in different extent..with time im even more angry than
> before (when i was writing on this many years ago)
>
> c also has other flaws (also mentioned) - language should be designed
> such way not to make code jumping and unnecessary dependencies which
> kill codes making work on it more tiresome and stupid
My personal language allows anything to be defined in any order,
including types, variables, enums and macros, at module scope or inside
a function.
So if you wanted, you could define all local variables at the end of a
function rather than at the top; in C syntax:
void GF() {
F(&x, &y, &z);
...
int x, y, z;
}
This doesn't look that useful at first, but in a current project where I
am generating code in that language, it is invaluable, as I don't know
exactly how many tempory variables need to be defined until I'm done
generating code for the body.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-05-17 21:07 +0200 |
| Message-ID | <10ud3kr$1tiib$1@dont-email.me> |
| In reply to | #399085 |
Bart pisze:
> On 17/05/2026 17:24, fir wrote:
>> Lew Pitcher pisze:
>
>>> Agreed. Bart and fir have a "special" view of coding, which is
>>> at odds with my 30+ years experience in the profession (and
>>> my 20+ years of post-professional (amateur) programming.
>>>
>>
>> were talking here about pices of c code..name it c files for example
>>
>> say you have N of such pices - when i code my app i got the pices just
>> as i sait ..one is for example setup_window.c another is timer.c
>> another is blitter.c and so on
>>
>> each have set of functions and "global" variables related to
>> them..mostly to them but some of them also may be accesed by other
>> pices/files
>>
>> if you have such system that those functions in each pice see all
>> other pieces up and down its ideal and proper situation becouse all
>> thise files like orthogonal one to another and thus like separated
>> only they
>> see other by names
>>
>>
>> adding a rigiud constrain that you must keep that files in artifical
>> linear order from up to down ias absolute crazyy becuose
>>
>> 1) naturally given order dont exist
>> 2) ist absolutly sill and tiresome to manage such stupid order
>
> C does allow you to have them in arbitrary order.
>
> But it means writing and maintaining function prototypes at the top of
> the file. That is what's tiresome.
>
i know it as you for sure know i know it
if i wuld guess what is more nonsense keeping all in this up-down
artificil order (and constant trouble of managing it) or the adding
thos redundant not neede declaration (and this dependency)
i dont know but probably those declarations are even worse
1. you need to write them, move them up etc and this a lot of work
2. it spoils the fact that then you dont know which file this variable
naturally belong
3. there could be differences between declaration and function and that
makes error
so
I. artifical up - down order is hell
II. artifical declarations are hell
no need to say more imo, case closed i would say, some should make this
flag.switch that i could turn it on in compiler and stop to worry with
this up down shit
>>
>> its absolute FLAW and its a disaster
>>
>> bartc simplyhas a dose of intelligence to see it too (though such
>> things some may see in different extent..with time im even more angry
>> than before (when i was writing on this many years ago)
>>
>> c also has other flaws (also mentioned) - language should be designed
>> such way not to make code jumping and unnecessary dependencies which
>> kill codes making work on it more tiresome and stupid
>
> My personal language allows anything to be defined in any order,
> including types, variables, enums and macros, at module scope or inside
> a function.
>
> So if you wanted, you could define all local variables at the end of a
> function rather than at the top; in C syntax:
>
> void GF() {
> F(&x, &y, &z);
> ...
> int x, y, z;
> }
>
> This doesn't look that useful at first, but in a current project where I
> am generating code in that language, it is invaluable, as I don't know
> exactly how many tempory variables need to be defined until I'm done
> generating code for the body.
>
>
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-18 08:56 +0200 |
| Message-ID | <10ued7n$29vhi$1@dont-email.me> |
| In reply to | #399085 |
On 17/05/2026 18:56, Bart wrote:
> On 17/05/2026 17:24, fir wrote:
>> Lew Pitcher pisze:
>
>>> Agreed. Bart and fir have a "special" view of coding, which is
>>> at odds with my 30+ years experience in the profession (and
>>> my 20+ years of post-professional (amateur) programming.
>>>
>>
>> were talking here about pices of c code..name it c files for example
>>
>> say you have N of such pices - when i code my app i got the pices just
>> as i sait ..one is for example setup_window.c another is timer.c
>> another is blitter.c and so on
>>
>> each have set of functions and "global" variables related to
>> them..mostly to them but some of them also may be accesed by other
>> pices/files
>>
>> if you have such system that those functions in each pice see all
>> other pieces up and down its ideal and proper situation becouse all
>> thise files like orthogonal one to another and thus like separated
>> only they
>> see other by names
>>
>>
>> adding a rigiud constrain that you must keep that files in artifical
>> linear order from up to down ias absolute crazyy becuose
>>
>> 1) naturally given order dont exist
>> 2) ist absolutly sill and tiresome to manage such stupid order
>
> C does allow you to have them in arbitrary order.
>
> But it means writing and maintaining function prototypes at the top of
> the file. That is what's tiresome.
>
/If/ you want to write your functions in an arbitrary order, then you
need to declare your static functions before you use them. That is
certainly true.
But remember this is a personal preference for the way you want to write
code - arbitrary order of declarations and definitions is /not/
necessarily a good thing. I accept that you like it, and I appreciate
that you are not alone in that. But other people have different
preferences. I /like/ having a fixed order. I almost never declare
static functions, and when programming in a language that allows
arbitrary order (such as Python), I still order my code bottom-up. This
means when you look at my code, if you want to know the definition of an
identifier, you only need to look in one direction - upwards.
I am not saying that this ordering is somehow universally or objectively
better than arbitrary order. But I am saying that arbitrary order is
not universally or objectively better in a programming language.
Flexibility has its downsides, and there's a lot of personal opinion and
preferences involved.
But I agree that if you use a language that has a "declare before use"
rule (as many languages do), and you want to write in an arbitrary
order, then it will involve extra effort. Such effort may be annoying,
but it is entirely self-imposed.
>>
>> its absolute FLAW and its a disaster
>>
>> bartc simplyhas a dose of intelligence to see it too (though such
>> things some may see in different extent..with time im even more angry
>> than before (when i was writing on this many years ago)
>>
>> c also has other flaws (also mentioned) - language should be designed
>> such way not to make code jumping and unnecessary dependencies which
>> kill codes making work on it more tiresome and stupid
>
> My personal language allows anything to be defined in any order,
> including types, variables, enums and macros, at module scope or inside
> a function.
>
> So if you wanted, you could define all local variables at the end of a
> function rather than at the top; in C syntax:
>
> void GF() {
> F(&x, &y, &z);
> ...
> int x, y, z;
> }
>
> This doesn't look that useful at first, but in a current project where I
> am generating code in that language, it is invaluable, as I don't know
> exactly how many tempory variables need to be defined until I'm done
> generating code for the body.
>
It does not just look useless at first sight, it looks horrible. But I
write my code myself, for the most part - generated code does not need
to be as easily read and understood. (I can't imagine how this
"feature" is useful for generating code - surely it would be negligible
effort to build up your list of variables as you build up the generated
statements, and output the whole function in one lump. You are no
longer trying to fit this into a few KB of ram on a Z80.)
Much better, IMHO, is to use a language that lets you mix declarations
and statements as needed. I see declaring your local variables in a
list at the top of a function - or, far worse, at the bottom - as
archaic style.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-18 09:22 +0200 |
| Message-ID | <10ueen5$jvhi$2@dont-email.me> |
| In reply to | #399095 |
On 2026-05-18 08:56, David Brown wrote: > [...] > > Much better, IMHO, is to use a language that lets you mix declarations > and statements as needed. Indeed. But not "mixing" as a value per se, but to keep declarations locally is a good thing, IMO. > I see declaring your local variables in a > list at the top of a function - or, far worse, at the bottom - as > archaic style. Well, "archaic" expresses a time-related qualification. But even in earlier times we saw, depending on the actual programming language, both styles existing. Anyway we need forward declarations or other means (e.g. multi-pass) to make mutual recursions or circular data structures possible. Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-18 10:35 +0200 |
| Message-ID | <10uej0o$2besu$1@dont-email.me> |
| In reply to | #399100 |
On 18/05/2026 09:22, Janis Papanagnou wrote: > On 2026-05-18 08:56, David Brown wrote: >> [...] >> >> Much better, IMHO, is to use a language that lets you mix declarations >> and statements as needed. > > Indeed. But not "mixing" as a value per se, but to keep declarations > locally is a good thing, IMO. > Yes - it is not the mixing itself that is good, it is what it allows. You get to keep your scopes small, you don't need to declare variables until you have an initial value for them (who cares if reading an uninitialised variable is UB if you never have them!), and you can often declare your variables as const. That means it's easy to know what the variable holds because it is only set once, and never changed. >> I see declaring your local variables in a list at the top of a >> function - or, far worse, at the bottom - as archaic style. > > Well, "archaic" expresses a time-related qualification. But even in > earlier times we saw, depending on the actual programming language, > both styles existing. Sure. But in the C world, pre-C99 code is often written in a style with local variables all declared at the top of the function - after C99, it is common to declare them when you need them. So as a C programmer, I see declaring local variables in one clump together as archaic. (Of course there are situations where it makes sense to declare local variables without initial values.) > > Anyway we need forward declarations or other means (e.g. multi-pass) > to make mutual recursions or circular data structures possible. > Of course.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-18 10:41 +0200 |
| Message-ID | <10uejb5$k0ug$4@dont-email.me> |
| In reply to | #399104 |
On 2026-05-18 10:35, David Brown wrote: > > [...] But in the C world, pre-C99 code is often written in a style with > local variables all declared at the top of the function - after C99, it > is common to declare them when you need them. So as a C programmer, I > see declaring local variables in one clump together as archaic. Ah, I forgot, even though I've learned "C" from K&R. - As soon as it became possible I had switched to the local style; a no-brainer. Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-05-18 16:47 +0000 |
| Message-ID | <10uffq4$m4se$1@paganini.bofh.team> |
| In reply to | #399104 |
David Brown <david.brown@hesbynett.no> wrote:
>
> Sure. But in the C world, pre-C99 code is often written in a style with
> local variables all declared at the top of the function - after C99, it
> is common to declare them when you need them. So as a C programmer, I
> see declaring local variables in one clump together as archaic.
I agree about style. But AFAICS even in very early C there is block
structure and one can put variable declarations in the middle of
sequence, just at the cost of introducing extra blocks. So C99
looks nicer as there is no need for extra blocks, but pre C99
already one could keep scopes tight and initialize variables in
declarations.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-18 18:58 +0200 |
| Message-ID | <10ufgg4$2l9ge$1@dont-email.me> |
| In reply to | #399130 |
On 18/05/2026 18:47, Waldek Hebisch wrote: > David Brown <david.brown@hesbynett.no> wrote: >> >> Sure. But in the C world, pre-C99 code is often written in a style with >> local variables all declared at the top of the function - after C99, it >> is common to declare them when you need them. So as a C programmer, I >> see declaring local variables in one clump together as archaic. > > I agree about style. But AFAICS even in very early C there is block > structure and one can put variable declarations in the middle of > sequence, just at the cost of introducing extra blocks. So C99 > looks nicer as there is no need for extra blocks, but pre C99 > already one could keep scopes tight and initialize variables in > declarations. > Certainly you can do that. But it quickly gets ugly and inconvenient if you have a lot of extra blocks. It's fair enough if you have a block already, from a loop or conditional.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2026-05-19 05:48 +0000 |
| Subject | Using "extra" blocks to declare local variables (Was: switch/extension for see below strongly needed) |
| Message-ID | <10ugtih$298li$1@news.xmission.com> |
| In reply to | #399131 |
In article <10ufgg4$2l9ge$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
...
>> I agree about style. But AFAICS even in very early C there is block
>> structure and one can put variable declarations in the middle of
>> sequence, just at the cost of introducing extra blocks. So C99
>> looks nicer as there is no need for extra blocks, but pre C99
>> already one could keep scopes tight and initialize variables in
>> declarations.
>
>Certainly you can do that. But it quickly gets ugly and inconvenient if
>you have a lot of extra blocks. It's fair enough if you have a block
>already, from a loop or conditional.
I have always liked this feature of C - that you can create an "extra"
block anywhere and then have locals declared there, like this:
...
puts("This is regular code");
{
int i = 10;
...
}
puts("More code here");
...
This is useful if you are modifying code you didn't write and don't
understand, but you just want to add some new feature (and declare some
variables for your own use), without disturbing (i.e., conflicting with)
anything that is already there. And, as noted, this works in all versions
of C, going back ...
--
Christianity is not a religion.
- Rick C Hodgin -
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-19 08:18 +0200 |
| Subject | Re: Using "extra" blocks to declare local variables (Was: switch/extension for see below strongly needed) |
| Message-ID | <10ugvb2$324u3$1@dont-email.me> |
| In reply to | #399145 |
On 19/05/2026 07:48, Kenny McCormack wrote:
> In article <10ufgg4$2l9ge$1@dont-email.me>,
> David Brown <david.brown@hesbynett.no> wrote:
> ...
>>> I agree about style. But AFAICS even in very early C there is block
>>> structure and one can put variable declarations in the middle of
>>> sequence, just at the cost of introducing extra blocks. So C99
>>> looks nicer as there is no need for extra blocks, but pre C99
>>> already one could keep scopes tight and initialize variables in
>>> declarations.
>>
>> Certainly you can do that. But it quickly gets ugly and inconvenient if
>> you have a lot of extra blocks. It's fair enough if you have a block
>> already, from a loop or conditional.
>
> I have always liked this feature of C - that you can create an "extra"
> block anywhere and then have locals declared there, like this:
>
> ...
> puts("This is regular code");
> {
> int i = 10;
> ...
> }
> puts("More code here");
> ...
>
> This is useful if you are modifying code you didn't write and don't
> understand, but you just want to add some new feature (and declare some
> variables for your own use), without disturbing (i.e., conflicting with)
> anything that is already there. And, as noted, this works in all versions
> of C, going back ...
>
I agree it can sometimes be useful. It is not often needed - especially
in C99 onwards - but sometimes it can be the neatest way to structure code.
I think probably the most common situation where I create "extra" blocks
would be in switch cases. It lets you pretend that "switch" is more
structured than it really is.
[toc] | [prev] | [next] | [standalone]
Page 1 of 13 [1] 2 3 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web