Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #389107 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2024-11-26 15:35 -0300 |
| Last post | 2024-11-30 09:31 -0300 |
| Articles | 20 on this page of 408 — 18 participants |
Back to article view | Back to comp.lang.c
question about linker Thiago Adams <thiago.adams@gmail.com> - 2024-11-26 15:35 -0300
Re: question about linker Bart <bc@freeuk.com> - 2024-11-26 20:00 +0000
Re: question about linker BGB <cr88192@gmail.com> - 2024-11-26 17:23 -0600
Re: question about linker fir <profesor.fir@gmail.com> - 2024-11-27 00:54 +0100
Re: question about linker BGB <cr88192@gmail.com> - 2024-11-26 18:10 -0600
Re: question about linker Bart <bc@freeuk.com> - 2024-11-27 00:59 +0000
Re: question about linker Thiago Adams <thiago.adams@gmail.com> - 2024-11-26 22:52 -0300
Re: question about linker Thiago Adams <thiago.adams@gmail.com> - 2024-11-27 06:37 -0300
Re: question about linker Bart <bc@freeuk.com> - 2024-11-27 11:57 +0000
Re: question about linker Bart <bc@freeuk.com> - 2024-11-27 12:10 +0000
Re: question about linker Thiago Adams <thiago.adams@gmail.com> - 2024-11-27 09:38 -0300
Re: question about linker Thiago Adams <thiago.adams@gmail.com> - 2024-11-27 09:57 -0300
Re: question about linker Thiago Adams <thiago.adams@gmail.com> - 2024-11-27 10:27 -0300
Re: question about linker Bart <bc@freeuk.com> - 2024-11-27 15:12 +0000
Re: question about linker Bart <bc@freeuk.com> - 2024-11-27 14:33 +0000
Re: question about linker Thiago Adams <thiago.adams@gmail.com> - 2024-11-27 09:32 -0300
Re: question about linker Bart <bc@freeuk.com> - 2024-11-27 14:25 +0000
Re: question about linker Thiago Adams <thiago.adams@gmail.com> - 2024-11-27 13:06 -0300
Re: question about linker Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-27 21:06 -0800
Re: question about linker Thiago Adams <thiago.adams@gmail.com> - 2024-11-26 16:11 -0300
Re: question about linker Bart <bc@freeuk.com> - 2024-11-26 19:25 +0000
Re: question about linker Thiago Adams <thiago.adams@gmail.com> - 2024-11-26 16:42 -0300
Re: question about linker BGB <cr88192@gmail.com> - 2024-11-26 17:37 -0600
Re: question about linker Bart <bc@freeuk.com> - 2024-11-27 01:11 +0000
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-11-27 10:53 +0100
Re: question about linker Thiago Adams <thiago.adams@gmail.com> - 2024-11-27 07:52 -0300
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-11-27 16:07 +0100
Re: question about linker Thiago Adams <thiago.adams@gmail.com> - 2024-11-27 13:20 -0300
Re: question about linker BGB <cr88192@gmail.com> - 2024-12-02 12:50 -0600
Re: question about linker Michael S <already5chosen@yahoo.com> - 2024-11-27 12:36 +0200
Re: question about linker Thiago Adams <thiago.adams@gmail.com> - 2024-11-27 08:08 -0300
Re: question about linker Michael S <already5chosen@yahoo.com> - 2024-11-27 15:01 +0200
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-11-27 16:12 +0100
Re: question about linker Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-27 15:18 -0800
Re: question about linker BGB <cr88192@gmail.com> - 2024-12-02 10:56 -0600
Re: question about linker Bart <bc@freeuk.com> - 2024-11-26 19:18 +0000
Re: question about linker Thiago Adams <thiago.adams@gmail.com> - 2024-11-26 16:38 -0300
Re: question about linker antispam@fricas.org (Waldek Hebisch) - 2024-11-27 10:29 +0000
Re: question about linker Thiago Adams <thiago.adams@gmail.com> - 2024-11-27 08:03 -0300
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-28 01:25 -0800
Re: question about linker Thiago Adams <thiago.adams@gmail.com> - 2024-11-28 08:19 -0300
Re: question about linker Bart <bc@freeuk.com> - 2024-11-28 11:38 +0000
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-28 11:58 -0800
Re: question about linker Bart <bc@freeuk.com> - 2024-11-28 22:23 +0000
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-28 14:38 -0800
Re: question about linker Bart <bc@freeuk.com> - 2024-11-28 23:05 +0000
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-28 15:20 -0800
Re: question about linker Bart <bc@freeuk.com> - 2024-11-29 00:32 +0000
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-28 18:15 -0800
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-11-29 08:38 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-11-29 11:04 +0000
Re: question about linker Ike Naar <ike@sdf.org> - 2024-11-29 12:06 +0000
Re: question about linker Michael S <already5chosen@yahoo.com> - 2024-11-29 14:28 +0200
Re: question about linker Bart <bc@freeuk.com> - 2024-11-29 13:33 +0000
Re: question about linker Michael S <already5chosen@yahoo.com> - 2024-11-29 16:15 +0200
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-11-29 17:42 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-11-29 18:26 +0000
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-29 12:35 -0800
Re: question about linker Bart <bc@freeuk.com> - 2024-11-29 21:52 +0000
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-29 15:44 -0800
Re: question about linker antispam@fricas.org (Waldek Hebisch) - 2024-11-30 00:55 +0000
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-29 17:02 -0800
Re: question about linker James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-29 20:38 -0500
Re: question about linker Michael S <already5chosen@yahoo.com> - 2024-11-30 19:08 +0200
Re: question about linker Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-03 11:31 -0800
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-01 14:50 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-12-01 14:23 +0000
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-01 16:50 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-12-01 20:12 +0000
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-02 11:30 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-12-02 12:24 +0000
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-02 16:24 +0100
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-02 19:23 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-12-02 19:12 +0000
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-02 22:16 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-12-02 21:53 +0000
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-03 15:34 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-12-03 15:47 +0000
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-03 19:02 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-12-03 18:42 +0000
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-04 10:02 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-12-04 15:09 +0000
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-04 21:55 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-12-04 21:31 +0000
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-05 15:00 +0100
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-05 16:15 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-12-05 15:29 +0000
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-06 16:41 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-12-06 18:41 +0000
Re: question about linker Ike Naar <ike@sdf.org> - 2024-12-06 19:14 +0000
Re: question about linker Bart <bc@freeuk.com> - 2024-12-06 19:27 +0000
Re: question about linker scott@slp53.sl.home (Scott Lurndal) - 2024-12-06 22:30 +0000
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-06 15:17 -0800
Re: question about linker Bart <bc@freeuk.com> - 2024-12-07 00:30 +0000
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-06 18:01 -0800
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-07 16:57 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-12-07 16:52 +0000
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-07 18:58 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-12-07 19:02 +0000
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-07 22:00 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-12-07 21:18 +0000
Re: question about linker Ben Bacarisse <ben@bsb.me.uk> - 2024-12-07 23:13 +0000
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-07 15:50 -0800
Re: question about linker Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-11 08:52 -0800
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-08 11:52 +0100
Re: question about linker antispam@fricas.org (Waldek Hebisch) - 2024-12-08 22:52 +0000
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-09 18:35 +0100
Re: question about linker bart <bc@freeuk.com> - 2024-12-10 12:10 +0000
Re: question about linker antispam@fricas.org (Waldek Hebisch) - 2024-12-05 03:11 +0000
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-05 16:46 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-12-05 17:42 +0000
Re: question about linker scott@slp53.sl.home (Scott Lurndal) - 2024-12-05 18:30 +0000
Re: question about linker Bart <bc@freeuk.com> - 2024-12-05 19:27 +0000
Re: question about linker scott@slp53.sl.home (Scott Lurndal) - 2024-12-05 20:21 +0000
Re: question about linker Bart <bc@freeuk.com> - 2024-12-05 21:46 +0000
Re: question about linker scott@slp53.sl.home (Scott Lurndal) - 2024-12-05 21:55 +0000
Re: question about linker Bart <bc@freeuk.com> - 2024-12-06 00:41 +0000
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-06 18:49 +0100
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-06 18:47 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-12-06 19:20 +0000
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-07 17:06 +0100
Re: question about linker bart <bc@freeuk.com> - 2024-12-10 13:56 +0000
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-10 17:16 +0100
Re: question about linker bart <bc@freeuk.com> - 2024-12-10 20:05 +0000
Re: question about linker bart <bc@freeuk.com> - 2024-12-10 20:12 +0000
Re: question about linker bart <bc@freeuk.com> - 2024-12-10 21:32 +0000
Re: question about linker James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-12-10 20:25 -0500
Re: question about linker scott@slp53.sl.home (Scott Lurndal) - 2024-12-11 01:32 +0000
Re: question about linker James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-12-11 23:38 -0500
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-12 06:07 +0100
Re: question about linker James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-12-12 14:39 -0500
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-12 21:27 +0100
Re: question about linker James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-12-12 20:31 -0500
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-13 14:10 +0100
Re: question about linker scott@slp53.sl.home (Scott Lurndal) - 2024-12-13 13:47 +0000
Re: question about linker James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-12-13 12:24 -0500
Re: question about linker Bart <bc@freeuk.com> - 2024-12-03 21:51 +0000
Re: question about linker Bart <bc@freeuk.com> - 2024-12-04 00:15 +0000
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-04 11:00 +0100
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-04 10:54 +0100
Re: question about linker scott@slp53.sl.home (Scott Lurndal) - 2024-12-04 16:55 +0000
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-04 21:57 +0100
Re: question about linker scott@slp53.sl.home (Scott Lurndal) - 2024-12-04 22:48 +0000
Re: question about linker Michael S <already5chosen@yahoo.com> - 2024-12-05 15:45 +0200
Re: question about linker scott@slp53.sl.home (Scott Lurndal) - 2024-12-05 15:43 +0000
Re: question about linker Michael S <already5chosen@yahoo.com> - 2024-12-05 22:30 +0200
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-06 19:04 +0100
Re: question about linker scott@slp53.sl.home (Scott Lurndal) - 2024-12-06 22:26 +0000
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-07 17:17 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-12-07 16:57 +0000
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-07 19:06 +0100
Re: question about linker scott@slp53.sl.home (Scott Lurndal) - 2024-12-07 22:12 +0000
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-08 11:57 +0100
Re: question about linker scott@slp53.sl.home (Scott Lurndal) - 2024-12-02 21:58 +0000
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-03 15:33 +0100
Re: question about linker scott@slp53.sl.home (Scott Lurndal) - 2024-12-02 19:58 +0000
Re: question about linker Bart <bc@freeuk.com> - 2024-12-02 21:00 +0000
Re: question about linker Bart <bc@freeuk.com> - 2024-12-02 18:27 +0000
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-02 22:06 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-12-02 22:11 +0000
Re: question about linker Michael S <already5chosen@yahoo.com> - 2024-12-03 00:27 +0200
Re: question about linker antispam@fricas.org (Waldek Hebisch) - 2024-12-04 02:04 +0000
Re: question about linker antispam@fricas.org (Waldek Hebisch) - 2024-12-04 12:29 +0000
Re: question about linker Bart <bc@freeuk.com> - 2024-12-04 15:46 +0000
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-04 15:09 -0800
Re: question about linker Bart <bc@freeuk.com> - 2024-12-05 00:10 +0000
Re: question about linker antispam@fricas.org (Waldek Hebisch) - 2024-12-05 03:23 +0000
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-01 16:37 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-11-30 00:57 +0000
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-29 17:28 -0800
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-30 04:25 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-11-30 11:59 +0000
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-01 10:36 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-12-01 11:52 +0000
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-01 16:08 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-12-01 16:42 +0000
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-02 18:32 +0100
Re: question about linker scott@slp53.sl.home (Scott Lurndal) - 2024-12-02 18:13 +0000
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-02 20:02 +0100
Re: question about linker scott@slp53.sl.home (Scott Lurndal) - 2024-12-02 19:57 +0000
Re: question about linker Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-02 17:23 -0800
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-03 16:00 +0100
Re: question about linker scott@slp53.sl.home (Scott Lurndal) - 2024-12-03 15:20 +0000
Re: question about linker BGB <cr88192@gmail.com> - 2024-12-03 19:09 -0600
Re: question about linker Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-03 17:19 -0800
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-03 16:36 +0100
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-03 16:09 +0100
Re: question about linker scott@slp53.sl.home (Scott Lurndal) - 2024-12-03 16:09 +0000
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-03 17:35 +0100
Re: question about linker BGB <cr88192@gmail.com> - 2024-12-03 12:57 -0600
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-03 20:27 +0100
Re: question about linker BGB <cr88192@gmail.com> - 2024-12-03 14:49 -0600
Re: question about linker Kaz Kylheku <643-408-1753@kylheku.com> - 2024-12-04 02:22 +0000
Re: question about linker Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-04 08:04 -0800
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-04 11:45 +0100
Re: question about linker scott@slp53.sl.home (Scott Lurndal) - 2024-12-04 16:49 +0000
Re: question about linker BGB <cr88192@gmail.com> - 2024-12-04 13:21 -0600
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-04 20:33 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-12-04 00:56 +0000
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-04 11:51 +0100
Re: question about linker scott@slp53.sl.home (Scott Lurndal) - 2024-12-04 16:57 +0000
Re: question about linker Bart <bc@freeuk.com> - 2024-12-04 17:43 +0000
Re: question about linker scott@slp53.sl.home (Scott Lurndal) - 2024-12-04 18:43 +0000
Re: question about linker BGB <cr88192@gmail.com> - 2024-12-04 13:54 -0600
Re: question about linker Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-05 07:16 -0800
Re: question about linker BGB <cr88192@gmail.com> - 2024-12-05 14:10 -0600
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-05 15:09 -0800
Re: question about linker BGB <cr88192@gmail.com> - 2024-12-05 17:32 -0600
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-04 15:29 -0800
Re: question about linker scott@slp53.sl.home (Scott Lurndal) - 2024-12-04 23:34 +0000
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-04 20:23 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-12-04 20:47 +0000
Re: question about linker scott@slp53.sl.home (Scott Lurndal) - 2024-12-04 22:31 +0000
Re: question about linker Bart <bc@freeuk.com> - 2024-12-04 23:21 +0000
Re: question about linker scott@slp53.sl.home (Scott Lurndal) - 2024-12-04 23:30 +0000
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-05 13:42 +0100
Re: question about linker James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-30 09:10 -0500
Re: question about linker Bart <bc@freeuk.com> - 2024-11-30 17:59 +0000
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-01 10:47 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-11-30 11:46 +0000
Re: question about linker Bart <bc@freeuk.com> - 2024-11-30 14:44 +0000
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-30 04:13 +0100
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-30 04:03 +0100
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-01 12:34 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-12-01 12:03 +0000
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-01 15:34 +0100
Re: question about linker Michael S <already5chosen@yahoo.com> - 2024-12-01 18:57 +0200
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-01 19:33 +0100
Re: question about linker antispam@fricas.org (Waldek Hebisch) - 2024-12-03 17:42 +0000
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-04 11:26 +0100
Re: question about linker antispam@fricas.org (Waldek Hebisch) - 2024-12-04 10:54 +0000
Re: question about linker Michael S <already5chosen@yahoo.com> - 2024-12-04 13:56 +0200
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-04 13:15 +0100
Re: question about linker Michael S <already5chosen@yahoo.com> - 2024-12-04 15:36 +0200
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-04 14:45 +0100
Re: question about linker Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-04 19:42 -0800
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-01 14:04 -0800
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-02 11:42 +0100
Re: question about linker Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-03 17:14 -0800
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-03 17:30 -0800
Re: question about linker Michael S <already5chosen@yahoo.com> - 2024-12-04 13:35 +0200
Re: question about linker James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-12-12 19:59 -0500
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-13 09:13 +0100
Re: question about linker James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-12-13 14:13 -0500
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-11-30 16:57 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-11-30 17:38 +0000
Re: question about linker Bart <bc@freeuk.com> - 2024-11-30 20:17 +0000
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-01 15:49 +0100
Re: question about linker antispam@fricas.org (Waldek Hebisch) - 2024-12-11 05:37 +0000
Re: question about linker Michael S <already5chosen@yahoo.com> - 2024-12-11 11:18 +0200
Re: question about linker bart <bc@freeuk.com> - 2024-12-11 11:57 +0000
Re: question about linker Michael S <already5chosen@yahoo.com> - 2024-12-11 16:26 +0200
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-11 16:15 +0100
Re: question about linker Michael S <already5chosen@yahoo.com> - 2024-12-11 19:22 +0200
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-11 21:35 +0100
Re: question about linker Michael S <already5chosen@yahoo.com> - 2024-12-12 00:26 +0200
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-12 09:27 +0100
Re: question about linker Michael S <already5chosen@yahoo.com> - 2024-12-12 14:13 +0200
Re: question about linker antispam@fricas.org (Waldek Hebisch) - 2024-12-12 19:30 +0000
Re: question about linker antispam@fricas.org (Waldek Hebisch) - 2024-12-11 23:33 +0000
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-11 16:04 -0800
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-11 16:10 +0100
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-11 16:03 +0100
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-12 15:03 +0100
Re: question about linker bart <bc@freeuk.com> - 2024-12-12 14:37 +0000
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-12 16:20 +0100
Re: question about linker bart <bc@freeuk.com> - 2024-12-12 18:17 +0000
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-12 22:18 +0100
Re: question about linker bart <bc@freeuk.com> - 2024-12-12 22:12 +0000
Re: question about linker antispam@fricas.org (Waldek Hebisch) - 2024-12-13 14:20 +0000
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-13 17:29 +0100
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-13 18:26 +0100
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-13 18:42 +0100
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-13 19:16 +0100
Re: question about linker bart <bc@freeuk.com> - 2024-12-13 17:41 +0000
Re: question about linker antispam@fricas.org (Waldek Hebisch) - 2024-12-14 04:36 +0000
Re: question about linker bart <bc@freeuk.com> - 2024-12-14 12:24 +0000
Re: question about linker antispam@fricas.org (Waldek Hebisch) - 2024-12-14 13:47 +0000
Re: question about linker Ben Bacarisse <ben@bsb.me.uk> - 2024-12-03 11:15 +0000
Re: question about linker Bart <bc@freeuk.com> - 2024-12-03 12:34 +0000
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-03 16:24 +0100
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-03 17:12 +0100
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-04 13:08 +0100
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-04 20:47 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-12-04 21:01 +0000
Re: question about linker Michael S <already5chosen@yahoo.com> - 2024-12-05 00:41 +0200
Re: question about linker Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-05 07:13 -0800
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-05 14:57 -0800
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-04 14:58 -0800
Re: question about linker Bart <bc@freeuk.com> - 2024-12-04 23:57 +0000
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-04 16:19 -0800
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-05 12:15 +0100
Re: question about linker Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-05 06:33 -0800
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-05 11:59 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-12-05 11:54 +0000
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-05 15:45 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-12-06 12:28 +0000
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-07 12:44 +0100
Re: question about linker Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-07 06:51 -0800
Re: question about linker Bart <bc@freeuk.com> - 2024-12-07 16:15 +0000
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-05 14:01 -0800
Re: question about linker scott@slp53.sl.home (Scott Lurndal) - 2024-12-04 22:59 +0000
Re: question about linker Opus <ifonly@youknew.org> - 2024-12-06 02:39 +0100
Re: question about linker Ike Naar <ike@sdf.org> - 2024-12-06 18:11 +0000
Re: question about linker antispam@fricas.org (Waldek Hebisch) - 2024-12-14 20:17 +0000
Re: question about linker bart <bc@freeuk.com> - 2024-12-14 21:34 +0000
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-14 14:22 -0800
Re: question about linker bart <bc@freeuk.com> - 2024-12-14 22:37 +0000
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-14 14:54 -0800
Re: question about linker bart <bc@freeuk.com> - 2024-12-14 23:14 +0000
Re: question about linker Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-04 17:29 -0800
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-05 11:20 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-12-05 12:00 +0000
Re: question about linker Ben Bacarisse <ben@bsb.me.uk> - 2024-12-04 11:16 +0000
Re: question about linker Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-04 08:38 -0800
Re: question about linker Bart <bc@freeuk.com> - 2024-12-04 17:26 +0000
Re: question about linker Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-07 06:16 -0800
Re: question about linker Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-05 12:39 -0800
Re: question about linker Bart <bc@freeuk.com> - 2024-12-05 21:34 +0000
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-05 16:50 -0800
Re: question about linker Bart <bc@freeuk.com> - 2024-12-06 01:20 +0000
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-05 18:10 -0800
Re: question about linker Bart <bc@freeuk.com> - 2024-12-06 11:34 +0000
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-06 10:14 -0800
Re: question about linker Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-07 07:00 -0800
Re: question about linker Bart <bc@freeuk.com> - 2024-12-07 16:17 +0000
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-07 12:34 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-12-07 13:04 +0000
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-07 15:36 +0100
Re: question about linker Bart <bc@freeuk.com> - 2024-12-07 15:33 +0000
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-07 13:38 -0800
Re: question about linker Bart <bc@freeuk.com> - 2024-12-07 22:47 +0000
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-09 19:46 +0100
Re: question about linker bart <bc@freeuk.com> - 2024-12-11 02:21 +0000
Re: question about linker antispam@fricas.org (Waldek Hebisch) - 2024-12-11 14:39 +0000
Re: question about linker bart <bc@freeuk.com> - 2024-12-11 15:34 +0000
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-11 14:06 -0800
Re: question about linker bart <bc@freeuk.com> - 2024-12-12 00:02 +0000
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-11 16:42 -0800
Re: question about linker bart <bc@freeuk.com> - 2024-12-12 01:14 +0000
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-11 17:27 -0800
Re: question about linker bart <bc@freeuk.com> - 2024-12-12 11:48 +0000
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-12 12:50 -0800
goto considered helpful (Was: question about linker) Michael S <already5chosen@yahoo.com> - 2024-12-12 14:44 +0200
Re: goto considered helpful Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-12 13:50 -0800
Re: goto considered helpful Kaz Kylheku <643-408-1753@kylheku.com> - 2024-12-12 22:33 +0000
Re: goto considered helpful David Brown <david.brown@hesbynett.no> - 2024-12-13 09:50 +0100
Re: goto considered helpful bart <bc@freeuk.com> - 2024-12-13 11:12 +0000
Re: goto considered helpful Michael S <already5chosen@yahoo.com> - 2024-12-13 14:39 +0200
Re: goto considered helpful David Brown <david.brown@hesbynett.no> - 2024-12-13 14:31 +0100
Re: goto considered helpful David Brown <david.brown@hesbynett.no> - 2024-12-13 14:19 +0100
Re: goto considered helpful bart <bc@freeuk.com> - 2024-12-13 14:26 +0000
Re: goto considered helpful David Brown <david.brown@hesbynett.no> - 2024-12-13 17:52 +0100
Re: goto considered helpful Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-13 10:11 -0800
Re: goto considered helpful scott@slp53.sl.home (Scott Lurndal) - 2024-12-13 14:16 +0000
Re: goto considered helpful Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-13 14:50 +0100
Re: goto considered helpful (Was: question about linker) Rosario19 <Ros@invalid.invalid> - 2024-12-20 13:52 +0100
Re: goto considered helpful (Was: question about linker) Michael S <already5chosen@yahoo.com> - 2024-12-20 15:27 +0200
Re: goto considered helpful (Was: question about linker) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-24 09:05 -0800
Re: goto considered helpful (Was: question about linker) Rosario19 <Ros@invalid.invalid> - 2024-12-26 13:33 +0100
Re: goto considered helpful (Was: question about linker) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-28 09:29 -0800
Re: question about linker Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-12 06:54 -0800
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-11 17:24 +0100
Re: question about linker bart <bc@freeuk.com> - 2024-12-12 12:11 +0000
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-12 15:56 +0100
Re: question about linker Ike Naar <ike@sdf.org> - 2024-12-11 08:43 +0000
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-11 16:28 +0100
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-11 17:46 +0100
Re: question about linker antispam@fricas.org (Waldek Hebisch) - 2024-12-12 02:31 +0000
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-11 17:30 +0100
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-11 17:47 +0100
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-11 17:51 +0100
Re: question about linker bart <bc@freeuk.com> - 2024-12-11 17:20 +0000
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-11 21:46 +0100
Re: question about linker bart <bc@freeuk.com> - 2024-12-11 21:19 +0000
Re: question about linker Michael S <already5chosen@yahoo.com> - 2024-12-12 00:03 +0200
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-12 11:08 +0100
Re: question about linker Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-23 16:02 -0800
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-12 05:50 +0100
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-11 21:35 -0800
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-12 12:38 +0100
Re: question about linker James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-12-18 16:04 -0500
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-19 01:35 +0100
Re: question about linker James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-12-19 06:39 -0500
Re: question about linker antispam@fricas.org (Waldek Hebisch) - 2024-12-19 14:58 +0000
Re: question about linker bart <bc@freeuk.com> - 2024-12-12 12:29 +0000
Re: question about linker Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-12 07:01 -0800
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-12-11 21:36 +0100
Re: question about linker antispam@fricas.org (Waldek Hebisch) - 2024-12-11 13:59 +0000
Re: question about linker Bart <bc@freeuk.com> - 2024-12-07 14:57 +0000
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-07 16:19 +0100
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-07 16:28 +0100
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-07 13:44 -0800
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-07 13:58 -0800
Re: question about linker scott@slp53.sl.home (Scott Lurndal) - 2024-12-07 22:15 +0000
Re: question about linker antispam@fricas.org (Waldek Hebisch) - 2024-12-11 22:51 +0000
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-11 15:12 -0800
Re: question about linker bart <bc@freeuk.com> - 2024-12-12 00:52 +0000
Re: question about linker Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-07 06:38 -0800
Re: question about linker Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-01 10:55 +0100
Re: question about linker Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-04 19:33 -0800
Re: question about linker Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-30 09:54 -0800
Re: question about linker Michael S <already5chosen@yahoo.com> - 2024-12-01 18:47 +0200
Re: question about linker David Brown <david.brown@hesbynett.no> - 2024-11-29 17:34 +0100
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-28 12:33 -0800
Re: question about linker Thiago Adams <thiago.adams@gmail.com> - 2024-11-29 09:30 -0300
Re: question about linker Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-29 12:53 -0800
Re: question about linker Thiago Adams <thiago.adams@gmail.com> - 2024-11-30 09:31 -0300
Page 4 of 21 — ← Prev page 1 2 3 [4] 5 6 … 21 Next page →
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2024-11-30 00:55 +0000 |
| Message-ID | <vidnp3$1ovvm$2@paganini.bofh.team> |
| In reply to | #389204 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Bart <bc@freeuk.com> writes:
>> It's another point of confusion. In my language I don't treat function
>> declarations like variable declarations. A function is not a
>> variable. There is no data storage associated with it.
>
> In C, declarations can declare objects, functions, types, etc. I fail
> to see how your language is relevant.
>
>> In C it is unfortunate, as it makes it hard to trivially distinguish a
>> function declaration (or the start of a function definition) from a
>> variable declaration.
>
> It's not as hard as you insist on pretending it is. A function
> declaration includes a pair of parentheses, either empty or
> containing a list of parameters or parameter types.
>
> Function declarations outside header files are valid, but tend to be
> rare in well-written C code.
Hmm, in well-written code static functions are likely to be a
majority. Some people prefer to declare all functions and
put declarations of static functions in the same file as the
functions itself. Conseqently, function declarations are not
rare in such code. Do you consider it well-written?
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-11-29 17:02 -0800 |
| Message-ID | <87y111r0so.fsf@nosuchdomain.example.com> |
| In reply to | #389206 |
antispam@fricas.org (Waldek Hebisch) writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
[...]
>> Function declarations outside header files are valid, but tend to be
>> rare in well-written C code.
>
> Hmm, in well-written code static functions are likely to be a
> majority. Some people prefer to declare all functions and
> put declarations of static functions in the same file as the
> functions itself. Conseqently, function declarations are not
> rare in such code. Do you consider it well-written?
Sure, I missed that case.
--
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 | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2024-11-29 20:38 -0500 |
| Message-ID | <vidqbb$1b5qv$1@dont-email.me> |
| In reply to | #389206 |
On 11/29/24 19:55, Waldek Hebisch wrote: ... > Hmm, in well-written code static functions are likely to be a > majority. Some people prefer to declare all functions and > put declarations of static functions in the same file as the > functions itself. Conseqently, function declarations are not > rare in such code. Do you consider it well-written? I wouldn't go so far as to say that it's poorly written, but I don't like the unnecessary redundancy of that approach. Whenever possible, I prefer to let each static function's definition serve as it's only declaration. This isn't possible, for instance, if you have a pair of mutually recursive functions. The redundancy between a header file's function declaration and the corresponding function definition is necessary, given the way that C works. Avoiding that is one of the reasons I like declaring static functions, where appropriate.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-11-30 19:08 +0200 |
| Message-ID | <20241130190829.00007193@yahoo.com> |
| In reply to | #389211 |
On Fri, 29 Nov 2024 20:38:51 -0500 James Kuyper <jameskuyper@alumni.caltech.edu> wrote: > On 11/29/24 19:55, Waldek Hebisch wrote: > ... > > Hmm, in well-written code static functions are likely to be a > > majority. Some people prefer to declare all functions and > > put declarations of static functions in the same file as the > > functions itself. Conseqently, function declarations are not > > rare in such code. Do you consider it well-written? > > I wouldn't go so far as to say that it's poorly written, but I don't > like the unnecessary redundancy of that approach. Whenever possible, I > prefer to let each static function's definition serve as it's only > declaration. This isn't possible, for instance, if you have a pair of > mutually recursive functions. > > The redundancy between a header file's function declaration and the > corresponding function definition is necessary, given the way that C > works. Avoiding that is one of the reasons I like declaring static > functions, where appropriate. Top-down-minded people don't like details textually preceding "big picture". [O.T.] Better solution would be if static function definition anywhere in the file serves like declaration (prototype) for the whole file, including preceding part. We are long past the time where single-pass compiler was a legit argument against such arrangement. Nowadays the only possible counter argument would be breaking existing code. But I don't see how such change breaks anything.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-12-03 11:31 -0800 |
| Message-ID | <86r06omum7.fsf@linuxsc.com> |
| In reply to | #389236 |
Michael S <already5chosen@yahoo.com> writes: > On Fri, 29 Nov 2024 20:38:51 -0500 > James Kuyper <jameskuyper@alumni.caltech.edu> wrote: > >> On 11/29/24 19:55, Waldek Hebisch wrote: >> ... >> >>> Hmm, in well-written code static functions are likely to be a >>> majority. Some people prefer to declare all functions and >>> put declarations of static functions in the same file as the >>> functions itself. Conseqently, function declarations are not >>> rare in such code. Do you consider it well-written? >> >> I wouldn't go so far as to say that it's poorly written, but I don't >> like the unnecessary redundancy of that approach. Whenever possible, I >> prefer to let each static function's definition serve as it's only >> declaration. This isn't possible, for instance, if you have a pair of >> mutually recursive functions. >> >> The redundancy between a header file's function declaration and the >> corresponding function definition is necessary, given the way that C >> works. Avoiding that is one of the reasons I like declaring static >> functions, where appropriate. > > Top-down-minded people don't like details textually preceding "big > picture". > > [O.T.] > Better solution would be if static function definition anywhere in the > file serves like declaration (prototype) for the whole file, including > preceding part. We are long past the time where single-pass compiler > was a legit argument against such arrangement. Nowadays the only > possible counter argument would be breaking existing code. But I don't > see how such change breaks anything. You have my vote. I also vote for whole-file declarations for defined objects as well as functions, and for whole-file declarations for definitions of entities that have external linkage as well as statics.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-12-01 14:50 +0100 |
| Message-ID | <vihpjh$2hgg1$1@dont-email.me> |
| In reply to | #389206 |
On 30/11/2024 01:55, Waldek Hebisch wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >> Bart <bc@freeuk.com> writes: >>> It's another point of confusion. In my language I don't treat function >>> declarations like variable declarations. A function is not a >>> variable. There is no data storage associated with it. >> >> In C, declarations can declare objects, functions, types, etc. I fail >> to see how your language is relevant. >> >>> In C it is unfortunate, as it makes it hard to trivially distinguish a >>> function declaration (or the start of a function definition) from a >>> variable declaration. >> >> It's not as hard as you insist on pretending it is. A function >> declaration includes a pair of parentheses, either empty or >> containing a list of parameters or parameter types. >> >> Function declarations outside header files are valid, but tend to be >> rare in well-written C code. > > Hmm, in well-written code static functions are likely to be a > majority. Some people prefer to declare all functions and > put declarations of static functions in the same file as the > functions itself. Conseqently, function declarations are not > rare in such code. Do you consider it well-written? > Without doubt, most functions (and non-local data) should be static. However, IMHO writing (non-defining) declarations for your static functions is a bad idea unless it is actually necessary to the code because you are using them in function pointers or have particularly good reasons for the way you order your code. I don't find redundant declarations of static functions at all useful - and I find them of significant cost in maintaining files. It is far too easy to forget to update them when you change, delete or add new functions. And a list of such declarations that you don't feel you can trust entirely, is worse than useless. Such lists might have been helpful to some people decades ago, when editors were more primitive. If I need a list of functions in a file (maybe it's someone else's code, or old code of mine), any programmer's editor or IDE will give me it - updated correctly in real-time, and not out of sync.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2024-12-01 14:23 +0000 |
| Message-ID | <vihrh1$2hk5l$1@dont-email.me> |
| In reply to | #389254 |
On 01/12/2024 13:50, David Brown wrote: > On 30/11/2024 01:55, Waldek Hebisch wrote: >> Hmm, in well-written code static functions are likely to be a >> majority. Some people prefer to declare all functions and >> put declarations of static functions in the same file as the >> functions itself. Conseqently, function declarations are not >> rare in such code. Do you consider it well-written? >> > > Without doubt, most functions (and non-local data) should be static. I have a tool that translates C programs to my syntax. Most functions of codebases I tried are marked 'global', because the C version did not use 'static'. Generally those functions don't need to be exported. This is just laziness or ignorance on the part of the program, not helped by C using the wrong default. > However, IMHO writing (non-defining) declarations for your static > functions is a bad idea unless it is actually necessary to the code > because you are using them in function pointers or have particularly > good reasons for the way you order your code. A good reason might be NOT CARING how the code is ordered. I have to constantly keep that in mind when writing C programs. I don't like movings functions about after they've been written, it is easier to add a forward declaration, even though I'd rather not do that at all. It is just another annoyance. Some people may also prefer top-down ordering of their functions. > I don't find redundant declarations of static functions at all useful - > and I find them of significant cost in maintaining files. It is far too > easy to forget to update them when you change, delete or add new > functions. And a list of such declarations that you don't feel you can > trust entirely, is worse than useless. Why doesn't the compiler report a declaration that doen't match the definition? > > Such lists might have been helpful to some people decades ago, when > editors were more primitive. If I need a list of functions in a file > (maybe it's someone else's code, or old code of mine), any programmer's > editor or IDE will give me it - updated correctly in real-time, and not > out of sync. Why isn't this a problem for exported/shared functions? That is, for all sorts of functions and variables declared in headers where there is a declaration in header, and a definition in some 'home' module.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-12-01 16:50 +0100 |
| Message-ID | <vii0jp$2jkd9$1@dont-email.me> |
| In reply to | #389255 |
On 01/12/2024 15:23, Bart wrote:
> On 01/12/2024 13:50, David Brown wrote:
>> On 30/11/2024 01:55, Waldek Hebisch wrote:
>
>>> Hmm, in well-written code static functions are likely to be a
>>> majority. Some people prefer to declare all functions and
>>> put declarations of static functions in the same file as the
>>> functions itself. Conseqently, function declarations are not
>>> rare in such code. Do you consider it well-written?
>>>
>>
>> Without doubt, most functions (and non-local data) should be static.
>
> I have a tool that translates C programs to my syntax. Most functions of
> codebases I tried are marked 'global', because the C version did not use
> 'static'.
>
> Generally those functions don't need to be exported. This is just
> laziness or ignorance on the part of the program, not helped by C using
> the wrong default.
>
I agree that the default for a language should be small scope (in this
case, functions should be static to the file) rather than large scope.
But it's not difficult to have a habit of adding "static" to all your
functions that are not exported - even for a C generator.
>> However, IMHO writing (non-defining) declarations for your static
>> functions is a bad idea unless it is actually necessary to the code
>> because you are using them in function pointers or have particularly
>> good reasons for the way you order your code.
>
> A good reason might be NOT CARING how the code is ordered.
I care how my code is organised and structured. I care, regardless of
whether or not the language cares. I might be a little freer in the the
ordering if the language does not require or promote a particular
ordering - but I pick the order intentionally.
I'd be quite happy with code in Python, or any other language which does
not impose a bottom-up ordering like C, to be written using a top-down
approach where each function calls other functions defined below it.
I'd also be happy with major algorithmic functions written one place and
small utility functions in a different section, or publicly callable
code first then private internal code. There's lots of organisation of
code that can make sense.
I'd not be impressed with "don't care" as an organisation.
>
>> I don't find redundant declarations of static functions at all useful
>> - and I find them of significant cost in maintaining files. It is far
>> too easy to forget to update them when you change, delete or add new
>> functions. And a list of such declarations that you don't feel you
>> can trust entirely, is worse than useless.
>
> Why doesn't the compiler report a declaration that doen't match the
> definition?
>
If the declarations are a mismatch - you have a function declared and
defined with different parameter or return types - it is an error. But
it is not an error to declare static functions that are never defined as
long as they are never used - so renamed or deleted functions can have
their declarations left behind. ("gcc -Wall" will warn about this, but
you would not want to use a tool that is potentially helpful.) And
defining and using a static function without a forward declaration is
rarely considered something to warn about, so missing declarations in
the list will not be diagnosed. (Maybe clang or clang-tidy have
warnings for that - they support more warnings than gcc.)
>>
>> Such lists might have been helpful to some people decades ago, when
>> editors were more primitive. If I need a list of functions in a file
>> (maybe it's someone else's code, or old code of mine), any
>> programmer's editor or IDE will give me it - updated correctly in
>> real-time, and not out of sync.
>
> Why isn't this a problem for exported/shared functions?
>
> That is, for all sorts of functions and variables declared in headers
> where there is a declaration in header, and a definition in some 'home'
> module.
>
What do you mean here?
I certainly consider it a weakness in C that you don't have clear
requirements and limitations for what can be in a header or a C file, or
how things can be mixed and matched. Keeping code clear and
well-ordered therefore requires discipline and standardised arrangement
of code and declarations. Different kinds of projects will have
different requirements here, but for my own code I find it best to be
strict that for any C file "file.c", there will be a header "file.h"
which contains "extern" declarations of any exported functions or data,
along with any type declarations needed to support these. My tools will
warn on any mismatches, such as non-static functions without a matching
"extern" declaration. They can't catch everything - the way C is built
up, there is no distinction between external declarations that should be
defined in the same module and ones that are imported from elsewhere.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2024-12-01 20:12 +0000 |
| Message-ID | <viifv8$2opi7$1@dont-email.me> |
| In reply to | #389264 |
On 01/12/2024 15:50, David Brown wrote:
> On 01/12/2024 15:23, Bart wrote:
>>> Such lists might have been helpful to some people decades ago, when
>>> editors were more primitive. If I need a list of functions in a file
>>> (maybe it's someone else's code, or old code of mine), any
>>> programmer's editor or IDE will give me it - updated correctly in
>>> real-time, and not out of sync.
>>
>> Why isn't this a problem for exported/shared functions?
>>
>> That is, for all sorts of functions and variables declared in headers
>> where there is a declaration in header, and a definition in some
>> 'home' module.
>>
>
> What do you mean here?
You said you didn't want a list of declarations to maintain for static
functions within a module.
But for non-static functions, which are shared via a header, you /need/
such a list to be maintained:
prog.h: int F(int);
prog.c: #include "prog.h"
static int G(int a);
int F(int a) {return 0;}
static int G(int a) {return 0;}
Here, you object to having to maintain the declaration for G, but you
still need to do so for F, and inside a separate file.
The declaration for F could also get out of sync, but you don't consider
that a problem?
And if it isn't because your tools help with this, then they can help
with G too.
> I certainly consider it a weakness in C that you don't have clear
> requirements and limitations for what can be in a header or a C file, or
> how things can be mixed and matched. Keeping code clear and
> well-ordered therefore requires discipline and standardised arrangement
> of code and declarations. Different kinds of projects will have
> different requirements here, but for my own code I find it best to be
> strict that for any C file "file.c", there will be a header "file.h"
> which contains "extern" declarations of any exported functions or data,
> along with any type declarations needed to support these. My tools will
> warn on any mismatches, such as non-static functions without a matching
> "extern" declaration. They can't catch everything - the way C is built
> up, there is no distinction between external declarations that should be
> defined in the same module and ones that are imported from elsewhere.
Yes, this is why a module scheme (such as the kind I use) is invaluable.
In the example above, you'd define both F and G in one place. There is
no header and there are no separate declarations.
If another module wishes to use F, then it imports the whole module that
defines F.
Some schemes can selectively import individual functions, but to me
that's pointless micro-managing.
In my scheme, it is not even necessary for individual modules to
explicitly import each other: a simple list of modules is provided in
one place, and they will automatically import each others' exported
entities (which include functions, variables, types, enums, structs,
named constants, and macros).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-12-02 11:30 +0100 |
| Message-ID | <vik28b$390eg$1@dont-email.me> |
| In reply to | #389271 |
On 01/12/2024 21:12, Bart wrote:
> On 01/12/2024 15:50, David Brown wrote:
>> On 01/12/2024 15:23, Bart wrote:
>
>>>> Such lists might have been helpful to some people decades ago, when
>>>> editors were more primitive. If I need a list of functions in a
>>>> file (maybe it's someone else's code, or old code of mine), any
>>>> programmer's editor or IDE will give me it - updated correctly in
>>>> real-time, and not out of sync.
>>>
>>> Why isn't this a problem for exported/shared functions?
>>>
>>> That is, for all sorts of functions and variables declared in headers
>>> where there is a declaration in header, and a definition in some
>>> 'home' module.
>>>
>>
>> What do you mean here?
>
> You said you didn't want a list of declarations to maintain for static
> functions within a module.
>
> But for non-static functions, which are shared via a header, you /need/
> such a list to be maintained:
Okay, I understand your point now. And I can see there is a certain
similarity between between maintaining the extern function declarations
in a header, and maintaining a list of static function declarations in
the C file. (I refer to "extern function declarations" to distinguish
them from static declarations - and because I personally like to include
the optional "extern" keyword.)
But there are many important differences.
The biggest difference is that header files form the public interface
for the "module". That will mean documentation (comments), include's
for any modules that are required for the declarations, type
declarations, possibly data, macros, etc., as well as extern function
declarations. The header is where you put the specification for the
module - it's not something that changes often, and the choice of
function declarations is done with care and planing, usually before
writing any implementations. And the header with all its contents is
vital information for both the implementer of the module, and the users.
Static functions, on the other hand, are internal to the implementation
and can be changed often. A list of static function declarations gives
little or no useful information to anyone.
>
> prog.h: int F(int);
>
>
> prog.c: #include "prog.h"
>
> static int G(int a);
>
> int F(int a) {return 0;}
>
> static int G(int a) {return 0;}
>
>
> Here, you object to having to maintain the declaration for G, but you
> still need to do so for F, and inside a separate file.
>
I can't speak for how you or anyone else writes code, but my code would
never look like that in practice. (Obviously I know what you wrote is a
quick example, not real code.) A local static function might have a
small, simple name - it is of very local scope, so like local variables
its purpose can be seen clearly from its definition and use. An
exported function, on the other hand, will have a good name, properly
named parameters, carefully chosen parameter types, comments, and a
position in the header to suit the structure of the code. Thus "F" and
"G" are very different in my code.
Obviously I still need to make sure the declarations and definitions
match up.
> The declaration for F could also get out of sync, but you don't consider
> that a problem?
It would be a problem if it happened, yes.
Fortunately, most such errors get caught during a build. A mismatch
between a function declaration and its definition will be caught
immediately as a C error. Warnings from my compiler catch non-static
function definitions that don't have a matching extern declaration. And
if there is an extern declaration for a function but no definition, then
there will be a link-time error if that function is used by other
modules. (But no error or warning if it is not used.)
>
> And if it isn't because your tools help with this, then they can help
> with G too.
>
As I explained earlier, they /can/ help with some sync errors in lists
of static forward declarations.
And if I wanted to have such lists of static function declarations, then
it would not be difficult to make a quick utility script that either
checked such a list, or generated it directly. That script could then
be included in the makefile for automation.
But since I don't use such lists, and don't see any benefit in them, I
haven't bothered writing such a script. If those who do write such
lists use some kind of automation to ensure they are correct, then that
would be great.
>> I certainly consider it a weakness in C that you don't have clear
>> requirements and limitations for what can be in a header or a C file,
>> or how things can be mixed and matched. Keeping code clear and
>> well-ordered therefore requires discipline and standardised
>> arrangement of code and declarations. Different kinds of projects
>> will have different requirements here, but for my own code I find it
>> best to be strict that for any C file "file.c", there will be a header
>> "file.h" which contains "extern" declarations of any exported
>> functions or data, along with any type declarations needed to support
>> these. My tools will warn on any mismatches, such as non-static
>> functions without a matching "extern" declaration. They can't catch
>> everything - the way C is built up, there is no distinction between
>> external declarations that should be defined in the same module and
>> ones that are imported from elsewhere.
>
> Yes, this is why a module scheme (such as the kind I use) is invaluable.
>
Agreed. C does not have a real module scheme as such. But it supports
getting similar effects - you just have to be disciplined in the way you
write your headers. This has the disadvantage of being less consistent
than, say, Pascal or Modula 2, especially if the programmer is not
disciplined. And it has the advantage in flexibility - I have a scheme
that I like and that works well for the kind of code I work with, but
other people prefer other schemes. It's easy to fall into the trap of
"my way is the right way", especially when you make your own language
and you are the only user, but there is always a balance to be sought
between consistency and flexibility.
> In the example above, you'd define both F and G in one place. There is
> no header and there are no separate declarations.
>
> If another module wishes to use F, then it imports the whole module that
> defines F.
>
> Some schemes can selectively import individual functions, but to me
> that's pointless micro-managing.
>
To me, it is absolutely vital that the importing unit can only see the
identifiers that were explicitly exported. It is also absolutely vital
(and this is a critical missing feature for C - and a good reason to
switch to C++ even if you use no other feature of that language) that
the imported identifiers be in their own namespace so that they do not
conflict with identifiers in the importing unit. If the language
provides a feature for importing the external identifiers directly into
the current unit's namespace, then it has to allow selective import of
identifiers - otherwise all concepts of scalability and modularity go
out the window.
> In my scheme, it is not even necessary for individual modules to
> explicitly import each other: a simple list of modules is provided in
> one place, and they will automatically import each others' exported
> entities (which include functions, variables, types, enums, structs,
> named constants, and macros).
>
That sounds, frankly, utterly terrible for anyone who worked with other
people.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2024-12-02 12:24 +0000 |
| Message-ID | <vik8tc$3ang9$1@dont-email.me> |
| In reply to | #389277 |
On 02/12/2024 10:30, David Brown wrote:
> On 01/12/2024 21:12, Bart wrote:
>> Yes, this is why a module scheme (such as the kind I use) is invaluable.
>>
>
> Agreed. C does not have a real module scheme as such. But it supports
> getting similar effects - you just have to be disciplined in the way you
> write your headers. This has the disadvantage of being less consistent
> than, say, Pascal or Modula 2, especially if the programmer is not
> disciplined. And it has the advantage in flexibility - I have a scheme
> that I like and that works well for the kind of code I work with, but
> other people prefer other schemes. It's easy to fall into the trap of
> "my way is the right way", especially when you make your own language
> and you are the only user, but there is always a balance to be sought
> between consistency and flexibility.
>
>> In the example above, you'd define both F and G in one place. There is
>> no header and there are no separate declarations.
>>
>> If another module wishes to use F, then it imports the whole module
>> that defines F.
>>
>> Some schemes can selectively import individual functions, but to me
>> that's pointless micro-managing.
>>
>
> To me, it is absolutely vital that the importing unit can only see the
> identifiers that were explicitly exported.
Speaking for my scheme, that is exactly what happens.
(First, I should say that my programs - sets of source files that will
comprise one binary - are organised into 'subprograms', each of which is
a chummy collection of modules that effectively import each other. The
following is about one subprogram.)
Only entities marked with 'global' are visble from other modules. But if
module X exports names A, B, C, all will be visible from Y.
Further, exported names D, E, F from X will be visible from X. Imports
can be circular (but subprograms are hierarchical).
What I object to in other schemes are:
* Where each of dozens of modules contains a ragtag list of imports at
the top. These look untidy and need to be endlessly maintained as a
fresh imported function is needed from module not yet listed, or an
import needs to be deleted as references to it are dropped. (This used
to be my scheme too!)
* Where functions are selectively imported from each module. FGS!
Instead of a few dozen imports, now there could be hundreds of lines of
imported function names to maintain. You'd have time for nothing else!
> It is also absolutely vital
> (and this is a critical missing feature for C - and a good reason to
> switch to C++ even if you use no other feature of that language) that
> the imported identifiers be in their own namespace so that they do not
> conflict with identifiers in the importing unit. If the language
> provides a feature for importing the external identifiers directly into
> the current unit's namespace, then it has to allow selective import of
> identifiers - otherwise all concepts of scalability and modularity go
> out the window.
Each of my modules creates a namespace. (Also, each of my subprograms
creates one namespace for all entities exported from the whole library:
that requires 'export' rather than 'global'.
However that namespace is rarely used. If this module imports X which
exports function F, then I can write F() instead of X.F().
I only need to use the namespace if:
* This module imports two modules that both export F so there is an
ambiguity (this is reported)
* This module has its own F so it shadows any imported versions. This is
not reported, but has the issue that, if a local F is freshly created,
it can silently shadow the previously imported F().
>
>> In my scheme, it is not even necessary for individual modules to
>> explicitly import each other: a simple list of modules is provided in
>> one place, and they will automatically import each others' exported
>> entities (which include functions, variables, types, enums, structs,
>> named constants, and macros).
>>
>
> That sounds, frankly, utterly terrible for anyone who worked with other
> people.
You've never used my scheme. One significant advantage is that because
all modules (and subprogram imports) are listed in the lead module
(usually that's all it contains), it is very easy to build a different
configuration using an alternative lead module with a different collection.
Alternatively, different modules can be commented in or out, in one
place. Below is the lead module of my C compiler, what is submitted to
my main compiler. No other modules contain any project info (only pcl.m,
a separate subprogram/library).
The only thing I haven't yet figured out is how the compiler knows the
location of an imported library which may reside elsewhere in the file
system. For now this is hardcoded.
--------------------------------
project =
module cc_cli
# Global Data and Tables
module cc_decls
module cc_tables
# Lexing and Parsing
module cc_lex
module cc_parse
# Generate PCL
module cc_genpcl
module cc_blockpcl
module cc_libpcl
# General
module cc_lib
module cc_support
# Bundled headers
module cc_headers # full set of embedded std headers
# module cc_headersx # dummy module with 0 headers
!Diagnostics
module cc_show
# module cc_showdummy
!IL Backend
$sourcepath "c:/px/"
import pcl # fully loaded backend
# import pclint # interpret only
end
(As is, this builds a 336KB C compiler with multiple options. With all
those alternate modules commented in instead, it builds a 178KB C
interpreter.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-12-02 16:24 +0100 |
| Message-ID | <vikjff$3dgvc$1@dont-email.me> |
| In reply to | #389279 |
On 02/12/2024 13:24, Bart wrote: > On 02/12/2024 10:30, David Brown wrote: >> On 01/12/2024 21:12, Bart wrote: > >>> Yes, this is why a module scheme (such as the kind I use) is invaluable. >>> >> >> Agreed. C does not have a real module scheme as such. But it >> supports getting similar effects - you just have to be disciplined in >> the way you write your headers. This has the disadvantage of being >> less consistent than, say, Pascal or Modula 2, especially if the >> programmer is not disciplined. And it has the advantage in >> flexibility - I have a scheme that I like and that works well for the >> kind of code I work with, but other people prefer other schemes. It's >> easy to fall into the trap of "my way is the right way", especially >> when you make your own language and you are the only user, but there >> is always a balance to be sought between consistency and flexibility. >> >>> In the example above, you'd define both F and G in one place. There >>> is no header and there are no separate declarations. >>> >>> If another module wishes to use F, then it imports the whole module >>> that defines F. >>> >>> Some schemes can selectively import individual functions, but to me >>> that's pointless micro-managing. >>> >> >> To me, it is absolutely vital that the importing unit can only see the >> identifiers that were explicitly exported. > > Speaking for my scheme, that is exactly what happens. Good. (That was not clear to me from your description.) > > (First, I should say that my programs - sets of source files that will > comprise one binary - are organised into 'subprograms', each of which is > a chummy collection of modules that effectively import each other. The > following is about one subprogram.) > > Only entities marked with 'global' are visble from other modules. But if > module X exports names A, B, C, all will be visible from Y. > > Further, exported names D, E, F from X will be visible from X. Imports > can be circular (but subprograms are hierarchical). > That sounds a bit looser than I would like, but I am not sure there is any point in discussing the details here. It is straying way too far from C for this newsgroup. > What I object to in other schemes are: > > * Where each of dozens of modules contains a ragtag list of imports at > the top. These look untidy and need to be endlessly maintained as a > fresh imported function is needed from module not yet listed, or an > import needs to be deleted as references to it are dropped. (This used > to be my scheme too!) I like to keep a /neat/ list of dependencies at the top of files. I usually have a rather good idea of which headers each C and header file requires. In the way I organise my headers, any header file which requires other headers, does so in that header. All my headers have guards to allow safe re-inclusion. So they can be ordered and arranged freely. I also usually have a "common" include file that includes the standard headers that I invariably need (like <stdbool.h>, <stdint.h> and <stddef.h>) along with a selection of definitions, static inline functions, macros, etc., that I use regularly in most projects. I would consider any kind of automatic import system to be a bad idea. > > * Where functions are selectively imported from each module. FGS! > Instead of a few dozen imports, now there could be hundreds of lines of > imported function names to maintain. You'd have time for nothing else! > That sounds like you have a very poor organisation of your files. Either you have far too many small files, or you have a few files that are far too big, or you have far too complex connections between your source files. I rarely have more than perhaps a dozen "include" lines in a C or header file. There are exceptions that require more - typically a "main" file that pulls everything together. > >> It is also absolutely vital (and this is a critical missing feature >> for C - and a good reason to switch to C++ even if you use no other >> feature of that language) that the imported identifiers be in their >> own namespace so that they do not conflict with identifiers in the >> importing unit. If the language provides a feature for importing the >> external identifiers directly into the current unit's namespace, then >> it has to allow selective import of identifiers - otherwise all >> concepts of scalability and modularity go out the window. > > Each of my modules creates a namespace. (Also, each of my subprograms > creates one namespace for all entities exported from the whole library: > that requires 'export' rather than 'global'. > > However that namespace is rarely used. If this module imports X which > exports function F, then I can write F() instead of X.F(). > > I only need to use the namespace if: > > * This module imports two modules that both export F so there is an > ambiguity (this is reported) > > * This module has its own F so it shadows any imported versions. This is > not reported, but has the issue that, if a local F is freshly created, > it can silently shadow the previously imported F(). > I like structured and modular programming. It is strange to me that someone would have the tools for that, and then choose not to use them. But some people seem to prefer piling everything together in one name space. >> >>> In my scheme, it is not even necessary for individual modules to >>> explicitly import each other: a simple list of modules is provided in >>> one place, and they will automatically import each others' exported >>> entities (which include functions, variables, types, enums, structs, >>> named constants, and macros). >>> >> >> That sounds, frankly, utterly terrible for anyone who worked with >> other people. > > You've never used my scheme. Indeed - that's why I say it /sounds/ terrible to me. As I said above, I prefer a clear and modular organisation. If I am writing module "foo" and a colleague is writing module "bar" as part of the same program, the last thing we want is automatic import of each other's modules, symbols, functions, etc. - especially not jumbled into the main namespace for the code! > One significant advantage is that because > all modules (and subprogram imports) are listed in the lead module > (usually that's all it contains), it is very easy to build a different > configuration using an alternative lead module with a different collection. > > Alternatively, different modules can be commented in or out, in one > place. Below is the lead module of my C compiler, what is submitted to > my main compiler. No other modules contain any project info (only pcl.m, > a separate subprogram/library). > > The only thing I haven't yet figured out is how the compiler knows the > location of an imported library which may reside elsewhere in the file > system. For now this is hardcoded.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-12-02 19:23 +0100 |
| Message-ID | <viku00$3gamg$1@dont-email.me> |
| In reply to | #389282 |
On 02.12.2024 16:24, David Brown wrote: > On 02/12/2024 13:24, Bart wrote: >> [...] > > That sounds like you have a very poor organisation of your files. [...] A suspicion that I got as well (also from other posts of him). Janis
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2024-12-02 19:12 +0000 |
| Message-ID | <vil0qc$3fqqa$3@dont-email.me> |
| In reply to | #389287 |
On 02/12/2024 18:23, Janis Papanagnou wrote: > On 02.12.2024 16:24, David Brown wrote: >> On 02/12/2024 13:24, Bart wrote: >>> [...] >> >> That sounds like you have a very poor organisation of your files. [...] > > A suspicion that I got as well (also from other posts of him). Then you'd both be wrong. DB's remark was anyway a misunderstanding. My projects have all relevant modules, usually measured in dozens, in the same folder. If projects share the same library, then the library forms its own project with its own folder. You consider that poor? For distribution, I would use ONE source file. Here, I'll create one such file right now: c:\cx>tm mm -ma cc.m Writing cc.ma TM: 0.08 It took 1/12th of a second to create an amalgamated source file containing everything needed (except a compiler) to build an EXE of my C compiler, including the shared backend sources, and including bundled C header files. I can email it to you if you like; it's 0.6MB, or 30Kloc. So, according to you, this is badly organised? Excuse me for struggling to see how a single file can be poorly organised! BTW cc.m contains that project info I posted earlier.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-12-02 22:16 +0100 |
| Message-ID | <vil82t$3ie9o$2@dont-email.me> |
| In reply to | #389292 |
On 02/12/2024 20:12, Bart wrote: > On 02/12/2024 18:23, Janis Papanagnou wrote: >> On 02.12.2024 16:24, David Brown wrote: >>> On 02/12/2024 13:24, Bart wrote: >>>> [...] >>> >>> That sounds like you have a very poor organisation of your files. [...] >> >> A suspicion that I got as well (also from other posts of him). > > Then you'd both be wrong. DB's remark was anyway a misunderstanding. > > My projects have all relevant modules, usually measured in dozens, in > the same folder. > Oh, dozens of modules! I never realised your programs were that big! In my current project, there are 155 C files, 44 C++ files, 272 header files, and 5 linker files over 71 directories. Most of the C files and a substantial proportion of the headers are libraries and SDKs for the device in use, most of the C++ files were written by me, but some were written by four other developers at the same time. When you work with more serious projects, you need a better organisation than you do for little one-man hobby programs.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2024-12-02 21:53 +0000 |
| Message-ID | <vila9j$3j4dg$1@dont-email.me> |
| In reply to | #389298 |
On 02/12/2024 21:16, David Brown wrote: > On 02/12/2024 20:12, Bart wrote: >> On 02/12/2024 18:23, Janis Papanagnou wrote: >>> On 02.12.2024 16:24, David Brown wrote: >>>> On 02/12/2024 13:24, Bart wrote: >>>>> [...] >>>> >>>> That sounds like you have a very poor organisation of your files. [...] >>> >>> A suspicion that I got as well (also from other posts of him). >> >> Then you'd both be wrong. DB's remark was anyway a misunderstanding. >> >> My projects have all relevant modules, usually measured in dozens, in >> the same folder. >> > > Oh, dozens of modules! I never realised your programs were that big! > In my current project, there are 155 C files, 44 C++ files, 272 header > files, and 5 linker files over 71 directories. Most of the C files and > a substantial proportion of the headers are libraries and SDKs for the > device in use, most of the C++ files were written by me, but some were > written by four other developers at the same time. > > When you work with more serious projects, you need a better organisation > than you do for little one-man hobby programs. So, how would you have organised the 16-module example I posted elsewhere? (Not a C project, these are 16 source files, so no headers etc.) Because two posters here have suggested my organisation is poor, but without knowing how big, small, or complex my projects are. BTW your project doesn't sound that big, especially if you have a penchant for having a larger number of smaller files. A line-count would give a better idea. The largest C project I attempted to build (with my compiler) was the Seed7 language a few years ago. I think there were 130-odd .c files, probably a comparable number of header files. It took my compiler 1-2 seconds to build from scratch, producing I think a 1.6MB executable. (That project is notable for coming with nearly 20 different makefiles, tuned for different compilers and platforms.) The current version includes 176 .c files and 148 .h files (not all used in any one configuration), which are all kept in one ./src folder. About 190Kloc in all. I guess that's poorly organised too? It sounds like everybody else's projects are!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-12-03 15:34 +0100 |
| Message-ID | <vin4su$49a6$1@dont-email.me> |
| In reply to | #389299 |
On 02/12/2024 22:53, Bart wrote: > On 02/12/2024 21:16, David Brown wrote: >> On 02/12/2024 20:12, Bart wrote: >>> On 02/12/2024 18:23, Janis Papanagnou wrote: >>>> On 02.12.2024 16:24, David Brown wrote: >>>>> On 02/12/2024 13:24, Bart wrote: >>>>>> [...] >>>>> >>>>> That sounds like you have a very poor organisation of your files. >>>>> [...] >>>> >>>> A suspicion that I got as well (also from other posts of him). >>> >>> Then you'd both be wrong. DB's remark was anyway a misunderstanding. >>> >>> My projects have all relevant modules, usually measured in dozens, in >>> the same folder. >>> >> >> Oh, dozens of modules! I never realised your programs were that big! > >> In my current project, there are 155 C files, 44 C++ files, 272 header >> files, and 5 linker files over 71 directories. Most of the C files >> and a substantial proportion of the headers are libraries and SDKs for >> the device in use, most of the C++ files were written by me, but some >> were written by four other developers at the same time. >> >> When you work with more serious projects, you need a better >> organisation than you do for little one-man hobby programs. > > So, how would you have organised the 16-module example I posted > elsewhere? (Not a C project, these are 16 source files, so no headers etc.) > > Because two posters here have suggested my organisation is poor, but > without knowing how big, small, or complex my projects are. No one (as far as I have noticed) have said that your organisation /is/ poor - they have said it /sounds/ poor from the way you describe it. The difference is very significant. For file organisation, I'd likely have all the modules in one directory unless there is a particular reason to split them up. I would not have any non-project files in that directory. But the questions raised about your organisation was not a matter of where you store your files, or how they are divided in directories. It is about how you organise the code and split functionality between files (or directories, for bigger projects). What you have described is modules that have far too much in one file, modules with little or no structure as to where things are in the file, little to no structure or control over which modules use facilities from which other modules, and completely random inter-module dependencies which can happily be circular. These opinions are formed from how you describe your code and your language. > > BTW your project doesn't sound that big, especially if you have a > penchant for having a larger number of smaller files. > > A line-count would give a better idea. > For the whole project (relevant to things like the build and the organisation): ----------------------------------------------------------------------- Language files blank comment code ----------------------------------------------------------------------- C 155 13849 34547 80139 C/C++ Header 284 13719 62329 61056 C++ 43 2447 1230 13009 ----------------------------------------------------------------------- SUM: 482 30015 98106 154204 ----------------------------------------------------------------------- For the project-specific code, rather than libraries, SDK, etc.: ----------------------------------------------------------------------- Language files blank comment code ----------------------------------------------------------------------- C++ 39 2217 1020 11820 C/C++ Header 44 1078 798 2696 C 3 259 237 1152 ----------------------------------------------------------------------- SUM: 86 3554 2055 15668 ------------------------------------------------------------------------ > The largest C project I attempted to build (with my compiler) was the > Seed7 language a few years ago. I think there were 130-odd .c files, > probably a comparable number of header files. > > It took my compiler 1-2 seconds to build from scratch, producing I think > a 1.6MB executable. (That project is notable for coming with nearly 20 > different makefiles, tuned for different compilers and platforms.) > > The current version includes 176 .c files and 148 .h files (not all used > in any one configuration), which are all kept in one ./src folder. About > 190Kloc in all. > > I guess that's poorly organised too? It sounds like everybody else's > projects are! > I have no idea how good or bad organisation that project is - I don't know enough about it to tell. But 200+ files in one directory does not sound like a good start. (Note again that I can only judge the /appearance/ of poor organisation of your projects from your own descriptions.) Not that it really matters, but a typical build for my project takes about 1 to 3 seconds. There are 18 binary images produced in the build - three different sets of builds (each with their own tree of object files from compiling with different options for the different but closely related programs) along with a number of variations of link setups and post-processing.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2024-12-03 15:47 +0000 |
| Message-ID | <vin95m$5da6$1@dont-email.me> |
| In reply to | #389308 |
On 03/12/2024 14:34, David Brown wrote:
> On 02/12/2024 22:53, Bart wrote:
>> So, how would you have organised the 16-module example I posted
>> elsewhere? (Not a C project, these are 16 source files, so no headers
>> etc.)
>>
>> Because two posters here have suggested my organisation is poor, but
>> without knowing how big, small, or complex my projects are.
>
> No one (as far as I have noticed) have said that your organisation /is/
> poor - they have said it /sounds/ poor from the way you describe it. The
> difference is very significant.
>
> For file organisation, I'd likely have all the modules in one directory
> unless there is a particular reason to split them up. I would not have
> any non-project files in that directory.
>
> But the questions raised about your organisation was not a matter of
> where you store your files, or how they are divided in directories. It
> is about how you organise the code and split functionality between files
> (or directories, for bigger projects).
>
> What you have described is modules that have far too much in one file,
> modules with little or no structure as to where things are in the file,
Because it doesn't really matter. (My language allows out-of-order
everything. So all module-scope variables could go at the end of the
file, or file-scope variables at the end of the function! However I
don't do that.
But I really don't want to care about whether function F precedes G in
the file, or follows it. Any more than I would care whether a file "F"
is stored before or after file "G" in a directory! The ordering could be
sorted in different ways for display; perhaps an editor could do the
same. (I guess your IDE does that.)
> little to no structure or control over which modules use facilities from
> which other modules, and completely random inter-module dependencies
> which can happily be circular.
They can be circular when it makes sense. They are after all part of the
same program!
In C, if you have 100 modules, but modules 23 and 87 need to share some
variable or function, it can be visible to the other 98 too, or can
clash with the same name thaty 17 and 26 want to share. Or with a name
that module 72 forgot to make static.
Or module 49 exports variable 'abc' as int, but 53 imports it as
'char*', then fun and games follow. C has a lot worse problems!
Being able to split a too-large module into two or more files without
worrying about hierarchy is a good thing; isn't it? If the original
function exported F G H, accessed as X.F, X.G, X.H, do you then have to
change all the calls to X.F, Y.G, Z.G because of how the original file
has been split up?
My scheme just makes this stuff very easy and effortless.
> These opinions are formed from how you describe your code and your
> language.
Below I've given the actual set of modules from my C compiler project,
partly annotated. It comprises three libraries whose sources files are
compiled into one executable.
The 'PCL' one (pc_ files) will probably be split up too at some point;
right now there's no need.
The average module size is 1000 lines, but some are larger. For example,
pc_genmcl, which is a set of 150 handler functions for the 150 opcodes
of my IL.
And pc_run, which is the interpreter for the IL, whose core is an
1100-line function containing a special kind of looping switch which is
implemented as a computed-goto (different from a normal switch since
there are N dispatch points rather than 1).
So a module is larger when it needs to encapsulate functions that do
part of the same job. There are several modules which have to dispatch
on an IL bytecode, or AST tag, or native code instruction.
>
>>
>> BTW your project doesn't sound that big, especially if you have a
>> penchant for having a larger number of smaller files.
>>
>> A line-count would give a better idea.
>>
>
> For the whole project (relevant to things like the build and the
> organisation):
>
> -----------------------------------------------------------------------
> Language files blank comment code
> -----------------------------------------------------------------------
> C 155 13849 34547 80139
> C/C++ Header 284 13719 62329 61056
> C++ 43 2447 1230 13009
> -----------------------------------------------------------------------
> SUM: 482 30015 98106 154204
> -----------------------------------------------------------------------
So about 600 lines per file.
>
> For the project-specific code, rather than libraries, SDK, etc.:
>
> -----------------------------------------------------------------------
> Language files blank comment code
> -----------------------------------------------------------------------
> C++ 39 2217 1020 11820
> C/C++ Header 44 1078 798 2696
> C 3 259 237 1152
> -----------------------------------------------------------------------
> SUM: 86 3554 2055 15668
> ------------------------------------------------------------------------
And here about 250 lines per file. Total line count isn't that different
from my 1990s CAD app, which was about 150Kloc, more than half
consisting of scripted modules.
This doesn't include the add-on scripted modules that OEMs would write
(plus alls sorts of data files, libraries of parts etc) to form the
final product.
Anyway, below are my C compiler modules as promised.
Here, there is a hierarchy. None of the second two libraries can access
anything from the main application. Both the first two can can access
imported entities from the third library.
-----------------------------------
# Main application
project =
module cc_cli
# Global Data and Tables
module cc_decls
module cc_tables
# Lexing and Parsing
module cc_lex
module cc_parse
# Generate PCL
module cc_genpcl
module cc_blockpcl
module cc_libpcl
# General
module cc_lib
module cc_support
# Bundled headers
module cc_headers
# module cc_headersx
# Diagnostics
module cc_show
# module cc_showdummy
# IL Backend
$sourcepath "c:/px/"
import pcl
end
# Backend library
project =
module pc_decls
# API to generate IL from a front-end compiler
module pc_api
# IL Diagnostics
module pc_diags
# module pc_diags_dummy
module pc_reduce # experimental IL optimiser
# PCL (IL) Interpreter
module pc_run
module pc_runaux
# Tables (eg. types and IL opcodes)
module pc_tables
# x64 backend (pcl -> mcl)
module mc_GenMCL # Main loop scanning PCL code
module mc_AuxMCL
module mc_LibMCL # API for building MCL (native code)
representation
module mc_StackMCL # Deal with converting stack-based IL to
reg-based native code
# Generate SS tables (MCL -> SS; SS is binary native code)
module mc_GenSS
module mc_Decls as md # (eg. x64 opcode enums)
module mc_OBJdecls # Describe PE-format data structures
# Write ASM (currently only one at a time is compiled in)
module mc_WriteASM # MCL -> ASM source
# module mc_WriteNASM # MCL -> NASM-format source
# Write EXE/DLL/OBJ (from SS)
module mc_WriteEXE # Create PE image and write EXE or DLL
module mc_WriteOBJ
# SS diagnostic display
# module mc_writess
# module mc_disasm # x64 disassembler for code segments
module mc_writess_dummy
# SS -> MCU -> MCX/MCB (Runnable in-memory code; or MX binary file)
module mx_decls
module mx_run
module mx_lib
module mx_write # Write MX-format binary
end
# Standard library of my language (this is imported by default)
project =
module msys # Language support
module mlib # The std library
module mclib # Import some C std library functions
module mwindows # OS-specific functions
module mwindll # provides LIBFFI-like capabilities
end
-----------------------------------
When I used to support Linux targets, then mwindows was replaced by
'mlinux', or 'mnos' for an OS-neutral version. This module provides a
common set of wrapper functions over some OS-specfic functions
For a C target (of the compiler for this project, then a target of this
project), then mwindll is replaced mwindllc, which provides some limited
functionality using HLL code only (so that it can be transpiled to C)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-12-03 19:02 +0100 |
| Message-ID | <vinh3h$7ppb$1@dont-email.me> |
| In reply to | #389314 |
On 03/12/2024 16:47, Bart wrote: > On 03/12/2024 14:34, David Brown wrote: >> On 02/12/2024 22:53, Bart wrote: > >>> So, how would you have organised the 16-module example I posted >>> elsewhere? (Not a C project, these are 16 source files, so no headers >>> etc.) >>> >>> Because two posters here have suggested my organisation is poor, but >>> without knowing how big, small, or complex my projects are. >> >> No one (as far as I have noticed) have said that your organisation >> /is/ poor - they have said it /sounds/ poor from the way you describe >> it. The difference is very significant. >> >> For file organisation, I'd likely have all the modules in one >> directory unless there is a particular reason to split them up. I >> would not have any non-project files in that directory. >> >> But the questions raised about your organisation was not a matter of >> where you store your files, or how they are divided in directories. >> It is about how you organise the code and split functionality between >> files (or directories, for bigger projects). >> >> What you have described is modules that have far too much in one file, >> modules with little or no structure as to where things are in the file, > > Because it doesn't really matter. It really /does/ matter - regardless of what the language allows or does not allow. If your language does not enforce ordering rules, that gives you more flexibility, but it does not relieve you of your responsibility as a programmer of writing code in a logical and structured manner. > (My language allows out-of-order > everything. So all module-scope variables could go at the end of the > file, or file-scope variables at the end of the function! However I > don't do that. > > But I really don't want to care about whether function F precedes G in > the file, or follows it. Any more than I would care whether a file "F" > is stored before or after file "G" in a directory! The ordering could be > sorted in different ways for display; perhaps an editor could do the > same. (I guess your IDE does that.) > >> little to no structure or control over which modules use facilities >> from which other modules, and completely random inter-module >> dependencies which can happily be circular. > > They can be circular when it makes sense. They are after all part of the > same program! > > In C, if you have 100 modules, but modules 23 and 87 need to share some > variable or function, it can be visible to the other 98 too, or can > clash with the same name thaty 17 and 26 want to share. Or with a name > that module 72 forgot to make static. > C has a risk of name clashes - that's why I am a fan of namespaces (proper ones, not your weird half-arsed solution). But if only modules 23 and 87 need access to the identifiers exported by module 42, then only those modules (and 42 itself) should include header 42. Module 68 will not include it, and can happily re-use the same identifiers as static identifiers or local variables. And if the writer of module 72 forgot to make a function static, ban them from the coffee machine until they have learned to use their tools correctly. You don't get to say that because it is possible to have certain problems in large C programs, anarchy should reign - especially not when you are making your own language and can get it right! > Or module 49 exports variable 'abc' as int, but 53 imports it as > 'char*', then fun and games follow. C has a lot worse problems! That will be caught at link time, if not before - unless you have crappy tools or an ignorant programmer who doesn't know how to use them.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2024-12-03 18:42 +0000 |
| Message-ID | <vinjf8$8jur$1@dont-email.me> |
| In reply to | #389320 |
On 03/12/2024 18:02, David Brown wrote:
> On 03/12/2024 16:47, Bart wrote:
>> On 03/12/2024 14:34, David Brown wrote:
>>> On 02/12/2024 22:53, Bart wrote:
>>
>>>> So, how would you have organised the 16-module example I posted
>>>> elsewhere? (Not a C project, these are 16 source files, so no
>>>> headers etc.)
>>>>
>>>> Because two posters here have suggested my organisation is poor, but
>>>> without knowing how big, small, or complex my projects are.
>>>
>>> No one (as far as I have noticed) have said that your organisation
>>> /is/ poor - they have said it /sounds/ poor from the way you describe
>>> it. The difference is very significant.
>>>
>>> For file organisation, I'd likely have all the modules in one
>>> directory unless there is a particular reason to split them up. I
>>> would not have any non-project files in that directory.
>>>
>>> But the questions raised about your organisation was not a matter of
>>> where you store your files, or how they are divided in directories.
>>> It is about how you organise the code and split functionality between
>>> files (or directories, for bigger projects).
>>>
>>> What you have described is modules that have far too much in one
>>> file, modules with little or no structure as to where things are in
>>> the file,
>>
>> Because it doesn't really matter.
>
> It really /does/ matter - regardless of what the language allows or does
> not allow.
Why?
What possible difference can it make if functions are in the order F G H
in the file or H G F?
(Of course, it might matter for the C language for those who can't be
bothered to provide the forward references the language makes possible.
But I assume you have something else in mind. Note that lots of
languages now allow out-of-order functions - allow a call to F before F
is defined - so what you are complaining about here applies to those too.)
> If your language does not enforce ordering rules,
There ARE no ordering rules! That's what 'out-of-order' means.
(The only place where ordering might matter, is in the list of modules
that describe the project. And that's only because of a feature where a
special initialisation function in each module can be invoked
automatically. The app may need those called in a certain order.)
> that gives
> you more flexibility, but it does not relieve you of your responsibility
> as a programmer of writing code in a logical and structured manner.
With forward declarations provided, then C provides exactly the same
flexibility in function ordering.
>> In C, if you have 100 modules, but modules 23 and 87 need to share
>> some variable or function, it can be visible to the other 98 too, or
>> can clash with the same name thaty 17 and 26 want to share. Or with a
>> name that module 72 forgot to make static.
>
> C has a risk of name clashes - that's why I am a fan of namespaces
> (proper ones, not your weird half-arsed solution).
What's wrong with my solution? You seem to be making assumptions about it.
All it does is allow you to write F() instead of A.F(). You can do the
same thing in C++ (there it saves you writing A::), by doing this (AIUI):
using A;
I could spend 30 minutes in providing an option so that it needs to be
explicit like this, but I don't have a pressing need to do so.
BTW what happens in C++ when you do this:
using A;
using B;
F();
and both A and B export (or make public) F? What happens if there is
also a locally defined F?
>> Or module 49 exports variable 'abc' as int, but 53 imports it as
>> 'char*', then fun and games follow. C has a lot worse problems!
>
> That will be caught at link time, if not before
Is it?
c:\cx>type a.c
extern void F(void);
int abc;
int main(void) {
abc=12345;
F();
}
c:\cx>type b.c
#include <stdio.h>
extern char* abc;
void F() {
puts(abc);
}
c:\cx>gcc a.c b.c
c:\cx>a
....
This crashes. This program is impossible to write in my language when
both modules are part of the program.
Only when the two functions are in different binaries so that one
program needs to work with a potentially incorrect declaration. Even
then, generating a DLL can also export an interface file with the
correct declarations.
Then it can only go wrong if one binary is updated and recompiled, but
not the other. But this applies to any language.
So it's a lot more fool-proof.
[toc] | [prev] | [next] | [standalone]
Page 4 of 21 — ← Prev page 1 2 3 [4] 5 6 … 21 Next page →
Back to top | Article view | comp.lang.c
csiph-web