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 15 of 21 — ← Prev page 1 … 13 14 [15] 16 17 … 21 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-12-03 16:24 +0100 |
| Message-ID | <vin7r2$49d1$2@dont-email.me> |
| In reply to | #389305 |
On 03/12/2024 13:34, Bart wrote: > On 03/12/2024 11:15, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: >> ... >>> If I write this >>> >>> Â Â int *A, B[10], C(int); >>> >>> My compiler tells me that: >>> >>> Â Â A is a local variable with type 'ref i32' (expressed in other syntax) >>> Â Â B is a local variable with type '[10]i32' >>> Â Â C is a function with return type of 'i32', taking one unnamed >>> Â Â Â Â parameter of type 'i32'. >>> >>> (Interestingly, it places C into module scope, so the same >>> declaration can >>> also create names in different scopes!) >> >> A small correction: that declaration gives all three names the same >> scope[1]. > > This is what I observed my compiler doing, because it displays the > symbol table. It puts C into module-scope, so I can access it also from > another function without another declaration (so non-conforming, but I'm > long past caring). > > I can't see gcc's symbol table, but I can't access C from another > function without it having its own declaration, or there being a > module-scope one. Declarations are scoped in C. Of course you can't make a declaration like this inside one block and then access it from inside another block (that is not a subblock). You don't need to see gcc's symbol table to understand this - you just need to know the basics of structured programming. > > With gcc, such a declaration inside a function suffices to be able > access a function 'C' defined later in the file. "int C(int);" declares that there exists an external linkage function "C" with prototype "int C(int)". If that identifier is used, then there must be a single function of that name and type defined somewhere in the program (in the same file or a different file). The block-scope declaration is only visible within that one block, of course. > >> Â You are confusing scope with linkage. > > It's possible. So a function declaration inside a function gives the > name external linkage (?). The declaration "int C(int)" is an external linkage declaration, because that is always the case for function declarations that are not explicitly declared "static". (And you can't have a static function declaration at block scope.) > Which in this context means the function will > be outside this one, but elsewhere in the module, rather than being > imported from elsewhere module. Not at all. It could be elsewhere in the unit, or in a different unit. There is no distinction. > > If I say I find these quirks of C confusing, people will have another go > at me. So let's say it makes perfect sense for 'extern' to mean two > different things! > Of course people will have another go at you for making wild and untrue assertions about things that should be pretty obvious to anyone who has thought about and read about scopes, identifiers and declarations - and which pretty much no one would ever write in real code. You are under no obligation to make your compiler conforming, but you don't get to claim you have made a compiler with different rules from C and that means C is confusing or ambiguous! It simply means that /you/ were wrong, /you/ got confused, /you/ didn't make any effort to look at the standards and the definition of the language. Of course lots of C programmers have never read the standards. But they generally know that they don't know these details, and don't try to pretend that the language details that they don't know are confusing. They simply get on with the job of writing clear C code as best they can.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-12-03 17:12 +0100 |
| Message-ID | <vinalt$5qoh$1@dont-email.me> |
| In reply to | #389312 |
On 03.12.2024 16:24, David Brown wrote: > On 03/12/2024 13:34, Bart wrote: >> [...] > > Of course lots of C programmers have never read the standards. But they > generally know that they don't know these details, and don't try to > pretend that the language details that they don't know are confusing. > They simply get on with the job of writing clear C code as best they can. I feel an urge to point out that the C standard is not necessary to understand concepts that can be read about in textbooks or inferred (or just tried out, if the available sources are unclear about some detail). Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-12-04 13:08 +0100 |
| Message-ID | <vipgns$rjqn$1@dont-email.me> |
| In reply to | #389316 |
On 03/12/2024 17:12, Janis Papanagnou wrote: > On 03.12.2024 16:24, David Brown wrote: >> On 03/12/2024 13:34, Bart wrote: >>> [...] >> >> Of course lots of C programmers have never read the standards. But they >> generally know that they don't know these details, and don't try to >> pretend that the language details that they don't know are confusing. >> They simply get on with the job of writing clear C code as best they can. > > I feel an urge to point out that the C standard is not necessary to > understand concepts that can be read about in textbooks or inferred > (or just tried out, if the available sources are unclear about some > detail). > Sure. And it is certainly /possible/ to know all the small details of C without ever reading the standards. But it's quite unlikely. This was a small detail of how declaring a function from inside a block interacts with a definition of the same function in the same unit. That is not something that will occur often in real code - it only came up because Bart is an expert at thinking up things in C that confuse him. In the real world, programmers simply don't do that kind of thing - and the kind of C programmer who is interested in these details will almost certainly also be interested in reading the standards. Most C programmers never look at the standards - textbooks, decent reference sites (like www.cppreference.com), common sense, and trial and error with quality compilers is sufficient for most programmers. There's nothing at all wrong with not knowing the whole language, or not having read the standards. There's nothing wrong with saying "I find this thing in C confusing" when you don't know how it works. But there /is/ something wrong with saying "C /is/ confusing" when you haven't learned how it works or consulted the standards and good references. The first is accepting personal responsibility, so that you can either learn about the feature or accept that it is a feature you want to avoid in your programming. The second is trying to pass the buck - blame your tools, blame other people, blame anyone but yourself. (If you find a feature in the language that you understand and have read about in the standards, and which a large proportion of programmers have trouble with - /then/ you have justification for saying that this particular feature of C is confusing.)
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-12-04 20:47 +0100 |
| Message-ID | <viqbl8$12mum$1@dont-email.me> |
| In reply to | #389346 |
On 04.12.2024 13:08, David Brown wrote:
> On 03/12/2024 17:12, Janis Papanagnou wrote:
>> On 03.12.2024 16:24, David Brown wrote:
>>> On 03/12/2024 13:34, Bart wrote:
>>>> [...]
>>>
>>> Of course lots of C programmers have never read the standards. But they
>>> generally know that they don't know these details, and don't try to
>>> pretend that the language details that they don't know are confusing.
>>> They simply get on with the job of writing clear C code as best they
>>> can.
>>
>> I feel an urge to point out that the C standard is not necessary to
>> understand concepts that can be read about in textbooks or inferred
>> (or just tried out, if the available sources are unclear about some
>> detail).
>
> Sure. And it is certainly /possible/ to know all the small details of C
> without ever reading the standards. But it's quite unlikely.
The question is (IMO) not so much to know "all" and even "all small"
details. Even in a language like "C" (that I'd consider to be fairly
incoherent if compared to other languages' design) you can get all
"important" language properties (including details) from textbooks.
If cases where that is different, the standards documents - which
have their very own special way of being written - would be even
less comprehensibly as they (inherently) already are. - That said
from a programmer's POV (not from the language implementors').
I look into language standards only if I want to confirm/falsify
an implementation; in this case I'm taking the role of a language
implementor (not a programmer). Personally I do that anyway only
rarely, for specific languages only, and just out of academical
interest.
> [...]
> Bart is an expert at thinking up things in C that confuse him.
Well, that's an own topic. - Where I was really astonished was the
statement of being confused about the braces/semicolons, which is
so fundamental (and primitive) but technically just a detail that
I'd thought it should be clear - i.e. without reading a language
standard. - But I don't want to blame him (or anyone) on that.
Ignorance is the human standard case, knowledge the exception.
That's why we exchange or knowledges, assumptions, and opinions.
> In the
> real world, programmers simply don't do that kind of thing - and the
> kind of C programmer who is interested in these details will almost
> certainly also be interested in reading the standards.
Again I feel an urge to point out that there are people interested
in such things and details (academically) and don't need standards.
>
> Most C programmers never look at the standards - textbooks, decent
> reference sites (like www.cppreference.com), common sense, and trial and
> error with quality compilers is sufficient for most programmers.
Experiences from other languages help as well to understand things.
>
> There's nothing at all wrong with not knowing [...]
Yes. Ignorance is the human standard case, knowledge the exception.
("ipse se nihil scire id unum sciat", sort of.)
> The second is trying to pass the buck - blame your
> tools, blame other people, blame anyone but yourself. [...]
...or build your own tools - LOL. :-)
Yes, that's a bit annoying. And a waste of time.
Janis
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2024-12-04 21:01 +0000 |
| Message-ID | <viqfuh$131h8$2@dont-email.me> |
| In reply to | #389364 |
On 04/12/2024 19:47, Janis Papanagnou wrote:
> On 04.12.2024 13:08, David Brown wrote:
>> Sure. And it is certainly /possible/ to know all the small details of C
>> without ever reading the standards. But it's quite unlikely.
>
> The question is (IMO) not so much to know "all" and even "all small"
> details. Even in a language like "C" (that I'd consider to be fairly
> incoherent if compared to other languages' design) you can get all
> "important" language properties (including details) from textbooks.
>
> If cases where that is different, the standards documents - which
> have their very own special way of being written - would be even
> less comprehensibly as they (inherently) already are. - That said
> from a programmer's POV (not from the language implementors').
>
> I look into language standards only if I want to confirm/falsify
> an implementation; in this case I'm taking the role of a language
> implementor (not a programmer). Personally I do that anyway only
> rarely, for specific languages only, and just out of academical
> interest.
>
>> [...]
>> Bart is an expert at thinking up things in C that confuse him.
>
> Well, that's an own topic. - Where I was really astonished was the
> statement of being confused about the braces/semicolons, which is
> so fundamental (and primitive) but technically just a detail that
> I'd thought it should be clear
OK, if it's so simple, explain it to me.
Apparently the first line here needs a semicolon after }, the second
doesn't:
int X[1] = {0};
void Y() {}
Similarly here:
if (x) y;
if (x) {}
Why?
"Because that's what the grammar says" isn't a valid answer.
The C language is one of the most quirky ones around full of apparently
ridiculous things. Why shouldn't you be able to write this for example:
{
....
L:
}
This stupid rule means that EVERY label in my generated code needs to be
written as L:; instead of just L:
Please don't say the label is only defined to be a prefix to another
statement. I asking why it was done like that.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-12-05 00:41 +0200 |
| Message-ID | <20241205004112.000040e2@yahoo.com> |
| In reply to | #389369 |
On Wed, 4 Dec 2024 21:01:07 +0000
Bart <bc@freeuk.com> wrote:
>
> The C language is one of the most quirky ones around full of
> apparently ridiculous things. Why shouldn't you be able to write this
> for example:
>
> {
> ....
> L:
> }
>
> This stupid rule means that EVERY label in my generated code needs to
> be written as L:; instead of just L:
>
> Please don't say the label is only defined to be a prefix to another
> statement. I asking why it was done like that.
>
>
No good reasons. It was a mistake of Committee 35 years ago.
I don't know why it was not fixed in 3 subsequent iteration.
Finally fixed in the latest edition.
Still, this mistake less bad than ; as a separator in Pascal.
And even the latter is minor.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-12-05 07:13 -0800 |
| Message-ID | <865xnykvrz.fsf@linuxsc.com> |
| In reply to | #389372 |
Michael S <already5chosen@yahoo.com> writes:
> On Wed, 4 Dec 2024 21:01:07 +0000
> Bart <bc@freeuk.com> wrote:
>
>> The C language is one of the most quirky ones around full of
>> apparently ridiculous things. Why shouldn't you be able to write
>> this for example:
>>
>> {
>> ....
>> L:
>> }
>>
>> This stupid rule means that EVERY label in my generated code
>> needs to be written as L:; instead of just L:
>>
>> Please don't say the label is only defined to be a prefix to
>> another statement. I asking why it was done like that.
>
> No good reasons. It was a mistake of Committee 35 years ago.
I don't agree that it was a mistake in the original C standard. The
charter of the original standardization effort was to define the
language as it was at the time, not to try to fix it. If "minor
improvements" were allowed the group would have spent all their
time arguing about what the language should be and not fulfill the
primary task. The PL/C group at Cornell made the same observation
about PL/C relative to PL/I: they decided to implement (a subset
of) PL/I as is, and not consider any changes, so as not to get lost
in the swamp of changing the language.
There are two obvious counterexamples to the above principle, those
being the void type and function prototypes. My understanding is
that both of those language features were available in some widely
used compilers at the time, and they offered significant benefits
that were not available otherwise. By contrast the value of not
needing a statement after a label is so far down the list you'd
need a telescope to see it.
> I don't know why it was not fixed in 3 subsequent iteration.
Probably because the committee thought they had better things to
do. I'd much rather have the changes that were introduced in
C99 and C11 than any time spent on unimportant cosmetic issues
like needing a semicolon after an end-of-block label.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-12-05 14:57 -0800 |
| Message-ID | <87y10tzqiw.fsf@nosuchdomain.example.com> |
| In reply to | #389410 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Michael S <already5chosen@yahoo.com> writes:
>> On Wed, 4 Dec 2024 21:01:07 +0000
>> Bart <bc@freeuk.com> wrote:
>>> The C language is one of the most quirky ones around full of
>>> apparently ridiculous things. Why shouldn't you be able to write
>>> this for example:
>>>
>>> {
>>> ....
>>> L:
>>> }
>>>
>>> This stupid rule means that EVERY label in my generated code
>>> needs to be written as L:; instead of just L:
[...]
>> I don't know why it was not fixed in 3 subsequent iteration.
>
> Probably because the committee thought they had better things to
> do. I'd much rather have the changes that were introduced in
> C99 and C11 than any time spent on unimportant cosmetic issues
> like needing a semicolon after an end-of-block label.
And likely because nobody had submitted a proposal to change it.
Some changes to the C standard originate from committee members,
and some come from proposals submitted by others.
In particular, here are the proposals that resulted in C23 loosening
the requirements for label placements:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2496.pdf
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2508.pdf
Both were submitted by Martin Uecker in 2020. (He happens to be a
committee member.) Quite possibly the change would have been made
sooner if anyone had suggested it.
Writing and submitting such a proposal is a non-trivial effort, and
the burden of writing "L:;" rather than "L:" in a few cases is light
enough that I'm not surprised it took as long as it did to change it.
I'll note that the C23 syntax introduces some mild complications.
It defines a "statement" as either a "labeled-statement" or an
"unlabeled-statement", but it also defines a "block-item" as a
"declaration", an "unlabeled-statement", or a "label". Which means
that a labeled statement is a single statement, but is treated as
two items within a compound statement.
Martin Uecker's proposal includes:
Optional Additional Change
6.11.X Labeled Statements
Labels outside of compound statements are an obsolescent feature.
This part was not adopted in C23. All labels are within some
compound statement, but I believe this refers to things like:
if (condition)
label: statement;
(I'd add braces anyway.)
I'm not suggesting that there's any real ambiguity, just that it
could be a little confusing. Even for such a simple change, there
can be a cost.
--
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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-12-04 14:58 -0800 |
| Message-ID | <87ttbj12ec.fsf@nosuchdomain.example.com> |
| In reply to | #389369 |
Bart <bc@freeuk.com> writes:
> On 04/12/2024 19:47, Janis Papanagnou wrote:
>> On 04.12.2024 13:08, David Brown wrote:
>>> Sure. And it is certainly /possible/ to know all the small details of C
>>> without ever reading the standards. But it's quite unlikely.
>> The question is (IMO) not so much to know "all" and even "all small"
>> details. Even in a language like "C" (that I'd consider to be fairly
>> incoherent if compared to other languages' design) you can get all
>> "important" language properties (including details) from textbooks.
>> If cases where that is different, the standards documents - which
>> have their very own special way of being written - would be even
>> less comprehensibly as they (inherently) already are. - That said
>> from a programmer's POV (not from the language implementors').
>> I look into language standards only if I want to confirm/falsify
>> an implementation; in this case I'm taking the role of a language
>> implementor (not a programmer). Personally I do that anyway only
>> rarely, for specific languages only, and just out of academical
>> interest.
>>
>>> [...]
>>> Bart is an expert at thinking up things in C that confuse him.
>> Well, that's an own topic. - Where I was really astonished was the
>> statement of being confused about the braces/semicolons, which is
>> so fundamental (and primitive) but technically just a detail that
>> I'd thought it should be clear
>
> OK, if it's so simple, explain it to me.
I'll pretend that was a sincere question.
You seem to be under the impression that a closing brace should
either always or never be followed by a semicolon. I don't know
where you got that idea.
Braces ("{", "}") are used in different contexts with different
meanings. They're generally used for some kind of grouping (of
statements, declarations, initializers), but the distinct uses are
distinct, and there's no particular reason for them to follow the
same rules.
> Apparently the first line here needs a semicolon after }, the second
> doesn't:
>
> int X[1] = {0};
> void Y() {}
Yes. The first is a declaration, and a declaration requires a
semicolon. I suppose the language could have a special-case rule
that if a declaration happens to end with a "}", the semicolon is
not required, but that would be silly.
The second is a function definition (and can only appear at file
scope). Function definitions do not require or allow a semicolon
after the closing "}". Why should they?
> Similarly here:
>
> if (x) y;
> if (x) {}
>
> Why?
>
> "Because that's what the grammar says" isn't a valid answer.
Because that's what the grammar says.
Not all statements require a closing semicolon. In particular,
compound statements do not, likely because the closing
"}" unambiguously marks the end of the statement. Sure, the
language could have been specified to require a semicolon, but why?
(I'll note that languages that use "begin"/"end" rather than "{"/"}"
often require a semicolon after the "end".)
And you can add a semicolon after a compound statement if you like
(it's a null statement), as long as the compound statement isn't
a function body.
Of course you know all this.
> The C language is one of the most quirky ones around full of
> apparently ridiculous things. Why shouldn't you be able to write this
> for example:
>
> {
> ....
> L:
> }
>
> This stupid rule means that EVERY label in my generated code needs to
> be written as L:; instead of just L:
>
> Please don't say the label is only defined to be a prefix to another
> statement. I asking why it was done like that.
The label is only defined to be a prefix to another statement.
It was simple to define it that way, and not particularly
inconvenient to add a semicolon if you happen to want a label at
the end of a block. I'd be surprised if this rule has ever actually
caused you any inconvenience.
But you'll be delighted to know that C23 changed the grammar for a
compound statement, so a label can appear before any of a statement,
a declaration, or the closing "}". So now you have exactly what you
want. (Just kidding; you'll still find a way to be angry about it.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2024-12-04 23:57 +0000 |
| Message-ID | <viqq95$164ug$1@dont-email.me> |
| In reply to | #389374 |
On 04/12/2024 22:58, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> OK, if it's so simple, explain it to me.
>
> I'll pretend that was a sincere question.
Let's put it this way: if somebody asked me what the rule was, I
wouldn't be able to tell them.
> You seem to be under the impression that a closing brace should
> either always or never be followed by a semicolon. I don't know
> where you got that idea.
>
> Braces ("{", "}") are used in different contexts with different
> meanings. They're generally used for some kind of grouping (of
> statements, declarations, initializers), but the distinct uses are
> distinct, and there's no particular reason for them to follow the
> same rules.
>
>> Apparently the first line here needs a semicolon after }, the second
>> doesn't:
>>
>> int X[1] = {0};
>> void Y() {}
>
> Yes. The first is a declaration, and a declaration requires a
> semicolon. I suppose the language could have a special-case rule
> that if a declaration happens to end with a "}", the semicolon is
> not required, but that would be silly.
>
> The second is a function definition (and can only appear at file
> scope). Function definitions do not require or allow a semicolon
> after the closing "}". Why should they?
Consistency? I posted a bit of Algol68 the other day; each function
definition needed a semicolon, to separate it from the next.
>> Similarly here:
>>
>> if (x) y;
>> if (x) {}
>>
>> Why?
>>
>> "Because that's what the grammar says" isn't a valid answer.
>
> Because that's what the grammar says.
>
> Not all statements require a closing semicolon. In particular,
> compound statements do not, likely because the closing
> "}" unambiguously marks the end of the statement. Sure, the
> language could have been specified to require a semicolon, but why?
Consistency again? But then you'd get this: if () {}; else {};. It would
be incompatible with how it works now.
So overall it's just messy. It works for BEGIN/END when semicolon is a
separator, rather than a terminator. So you write END ELSE not END; ELSE.
But because C uses ";" as a terminator, it's made a rod for its own back.
> (I'll note that languages that use "begin"/"end" rather than "{"/"}"
> often require a semicolon after the "end".)
That's my A68 example.
> And you can add a semicolon after a compound statement if you like
> (it's a null statement),
But not here I guess: if () {}; else ...
> Of course you know all this.
I'm aware of how messy and conistent it is. I've said that languages
that use ";" as a separator probably fair better, but are still not
ideal because the last statement of a block is now an annoying special case.
So it's an interesting language design problem.
My own made a compromise here: use ";" as separator, but introduce some
rules so that explicit ";" is rarely need. I think that wins.
Meanwhile, if I compile this:
void F(){}; void G(){};
My compilers report a syntax error. But gcc passes it by default. So I
take what the grammar says more seriously than gcc!
IS ";" between function definitions legal or not? If not, then fail the
program.
>> Please don't say the label is only defined to be a prefix to another
>> statement. I asking why it was done like that.
>
> The label is only defined to be a prefix to another statement.
> It was simple to define it that way, and not particularly
> inconvenient to add a semicolon if you happen to want a label at
> the end of a block. I'd be surprised if this rule has ever actually
> caused you any inconvenience.
I said that my generated code has to use ":;" after each label; it looks
weird.
> But you'll be delighted to know that C23 changed the grammar for a
> compound statement, so a label can appear before any of a statement,
> a declaration, or the closing "}". So now you have exactly what you
> want. (Just kidding; you'll still find a way to be angry about it.)
No, that's amazing. Presumably, some people must complained about it
(maybe it actually caused some inconvenience!), and it eventually got fixed.
Of course, if it was just me, then it would be pointless ranting. 'How
hard is to add the semicolon?'
Well, 'How hard is it to delete the semicolon' from my above example?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-12-04 16:19 -0800 |
| Message-ID | <87a5db0ymo.fsf@nosuchdomain.example.com> |
| In reply to | #389381 |
Bart <bc@freeuk.com> writes:
> On 04/12/2024 22:58, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> OK, if it's so simple, explain it to me.
>> I'll pretend that was a sincere question.
>
> Let's put it this way: if somebody asked me what the rule was, I
> wouldn't be able to tell them.
Probably because there's no single rule. As I wrote, "{" and "}"
are used in different contexts with different meanings. (So are
"(", ")", ";", and "static".) I have no particular expectation
that there should be a single rule covering all the cases, just
because they happen to use the same symbol.
A reasonable person would have ackowledged that I've at least tried
to answer your question.
>> You seem to be under the impression that a closing brace should
>> either always or never be followed by a semicolon. I don't know
>> where you got that idea.
>> Braces ("{", "}") are used in different contexts with different
>> meanings. They're generally used for some kind of grouping (of
>> statements, declarations, initializers), but the distinct uses are
>> distinct, and there's no particular reason for them to follow the
>> same rules.
>>
>>> Apparently the first line here needs a semicolon after }, the second
>>> doesn't:
>>>
>>> int X[1] = {0};
>>> void Y() {}
>> Yes. The first is a declaration, and a declaration requires a
>> semicolon. I suppose the language could have a special-case rule
>> that if a declaration happens to end with a "}", the semicolon is
>> not required, but that would be silly.
>> The second is a function definition (and can only appear at file
>> scope). Function definitions do not require or allow a semicolon
>> after the closing "}". Why should they?
>
> Consistency? I posted a bit of Algol68 the other day; each function
> definition needed a semicolon, to separate it from the next.
C is not Algol68. In C, the syntax of a function definition is such
that they can be appended without ambiguity. Requiring a semicolon
after each definition would not help anything. And it would break
most existing C code.
>>> Similarly here:
>>>
>>> if (x) y;
>>> if (x) {}
>>>
>>> Why?
>>>
>>> "Because that's what the grammar says" isn't a valid answer.
>> Because that's what the grammar says.
>> Not all statements require a closing semicolon. In particular,
>> compound statements do not, likely because the closing
>> "}" unambiguously marks the end of the statement. Sure, the
>> language could have been specified to require a semicolon, but why?
>
> Consistency again? But then you'd get this: if () {}; else {};. It
> would be incompatible with how it works now.
So there's a good reason for the current definition.
> So overall it's just messy. It works for BEGIN/END when semicolon is a
> separator, rather than a terminator. So you write END ELSE not END;
> ELSE.
>
> But because C uses ";" as a terminator, it's made a rod for its own back.
The solution (for programmers) is simple. Don't add a ";" after the
closing "}" of a compound statement. You *can* add the ";" in some
cases, but there's no point in doing so.
>> (I'll note that languages that use "begin"/"end" rather than "{"/"}"
>> often require a semicolon after the "end".)
>
> That's my A68 example.
>
>> And you can add a semicolon after a compound statement if you like
>> (it's a null statement),
>
> But not here I guess: if () {}; else ...
You're right, I missed that case.
>> Of course you know all this.
>
> I'm aware of how messy and conistent it is. I've said that languages
> that use ";" as a separator probably fair better, but are still not
> ideal because the last statement of a block is now an annoying special
> case.
No, I'm saying that you already know what the rules are. You have
access to multiple C (draft) standards and books. You've written a C
compiler yourself. I honestly don't believe you're as confused as you
pretend to be.
[...]
> Meanwhile, if I compile this:
>
> void F(){}; void G(){};
>
> My compilers report a syntax error. But gcc passes it by default. So I
> take what the grammar says more seriously than gcc!
>
> IS ";" between function definitions legal or not? If not, then fail
> the program.
Bart, you already know that gcc by default is relatively lax, and is in
fact not a conforming C compiler, since it fails to produce many
required diagnostics. You've been told again and again how to invoke
gcc so that it will at least attempt to be a conforming C compiler, for
any of several editions of the C standard. But you still pretend that
gcc's default behavior says something about the C language.
>>> Please don't say the label is only defined to be a prefix to another
>>> statement. I asking why it was done like that.
>> The label is only defined to be a prefix to another statement.
>> It was simple to define it that way, and not particularly
>> inconvenient to add a semicolon if you happen to want a label at
>> the end of a block. I'd be surprised if this rule has ever actually
>> caused you any inconvenience.
>
> I said that my generated code has to use ":;" after each label; it
> looks weird.
I stand corrected. The rule has caused you some trivial inconvenience.
(Apparently you care about generated code looking weird; I'd expect
weirdness to be inevitable.)
>> But you'll be delighted to know that C23 changed the grammar for a
>> compound statement, so a label can appear before any of a statement,
>> a declaration, or the closing "}". So now you have exactly what you
>> want. (Just kidding; you'll still find a way to be angry about it.)
>
> No, that's amazing. Presumably, some people must complained about it
> (maybe it actually caused some inconvenience!), and it eventually got
> fixed.
>
> Of course, if it was just me, then it would be pointless ranting. 'How
> hard is to add the semicolon?'
>
> Well, 'How hard is it to delete the semicolon' from my above example?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-12-05 12:15 +0100 |
| Message-ID | <vis20r$1io92$1@dont-email.me> |
| In reply to | #389383 |
On 05.12.2024 01:19, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>>
>> Let's put it this way: if somebody asked me what the rule was, I
>> wouldn't be able to tell them.
>
> Probably because there's no single rule. As I wrote, "{" and "}"
> are used in different contexts with different meanings. [...]
The context in the post was not about the many places where the
braces are used in "C" but was concerning only a very specific
case; mainly an empty statement (terminated by a semicolon) and
an empty block (an empty compound statement). - If that already
confuses him you can imagine what you do when pointing out that
there's yet more uses of braces. :-)
> [...]
>>
>> Consistency? I posted a bit of Algol68 the other day; each function
>> definition needed a semicolon, to separate it from the next.
(In Algol 68 not specifically only function definitions. "Things"
just need separation "to tell them apart". That's quite typical
for [programming] languages.)
>
> C is not Algol68. In C, the syntax of a function definition is such
> that they can be appended without ambiguity. Requiring a semicolon
> after each definition would not help anything. [...]
Any why would one want to introduce an inconsistency here? The
"C" syntax may be disliked but at least it makes sense [here].
Janis
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-12-05 06:33 -0800 |
| Message-ID | <86a5dakxmk.fsf@linuxsc.com> |
| In reply to | #389383 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Bart <bc@freeuk.com> writes:
>
>> On 04/12/2024 22:58, Keith Thompson wrote:
>>
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> OK, if it's so simple, explain it to me.
>>>
>>> I'll pretend that was a sincere question.
>>
>> Let's put it this way: if somebody asked me what the rule was, I
>> wouldn't be able to tell them.
>
> Probably because there's no single rule. As I wrote, "{" and "}"
> are used in different contexts with different meanings. (So are
> "(", ")", ";", and "static".) I have no particular expectation
> that there should be a single rule covering all the cases, just
> because they happen to use the same symbol.
>
> A reasonable person would have ackowledged that I've at least
> tried to answer your question.
For the record I appreciate your efforts to answer Bart's C
questions.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-12-05 11:59 +0100 |
| Message-ID | <vis132$1ig7f$1@dont-email.me> |
| In reply to | #389381 |
On 05.12.2024 00:57, Bart wrote: > On 04/12/2024 22:58, Keith Thompson wrote: >> Bart <bc@freeuk.com> writes: > >>> OK, if it's so simple, explain it to me. >> >> I'll pretend that was a sincere question. > > Let's put it this way: if somebody asked me what the rule was, I > wouldn't be able to tell them. If that is true I suggest to read one or two textbooks. But as you are actually a language designer I would suppose that it should suffice if you look at the constructs and think about them; about the syntactic options and requirements of separate statements, their separation/termination, embraced blocks, and empty statements. From anyone who implements a language (like you did) I'd certainly expect to get that just by own thinking. >> [...] > > Consistency? I posted a bit of Algol68 the other day; each function > definition needed a semicolon, to separate it from the next. Why do you explicitly name functions here? - Semicolons are a general (sequentializing) separator in Algol 68, and not really different from other programming languages. >> [...] > > I'm aware of how messy and conistent it is. I've said that languages > that use ";" as a separator probably fair better, [...] (Oh, I thought you said you preferred terminators in languages.) > [...] > > My own made a compromise here: use ";" as separator, (I know that from Awk, where I regularly use that feature.) > but introduce some > rules so that explicit ";" is rarely need. I think that wins. Would that then be (like in Awk) that you then assume the line-end as separator? (For a scripting language I think it's okay. YMMV. But generally I would certainly consider that to be a Bad Idea.) > > I said that my generated code has to use ":;" after each label; it looks > weird. It's funny that you put such an emphasis on labels. - Jumps to labels have academically been long deprecated but, more importantly, in my practical work I never had a need to use them (or even think or considering to use them). (I suppose it's how one got socialized to design and write programs.) >> [...] > [...] > > Of course, if it was just me, then it would be pointless ranting. 'How > hard is to add the semicolon?' > > Well, 'How hard is it to delete the semicolon' from my above example? You obviously have problems on a level that other folks don't have. Janis
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2024-12-05 11:54 +0000 |
| Message-ID | <vis49u$1ja8l$1@dont-email.me> |
| In reply to | #389396 |
On 05/12/2024 10:59, Janis Papanagnou wrote:
> On 05.12.2024 00:57, Bart wrote:
>> On 04/12/2024 22:58, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>
>>>> OK, if it's so simple, explain it to me.
>>>
>>> I'll pretend that was a sincere question.
>>
>> Let's put it this way: if somebody asked me what the rule was, I
>> wouldn't be able to tell them.
>
> If that is true I suggest to read one or two textbooks.
That answer suggests we're talking at cross-purposes.
So if the rules really aren't that simple, 100M users of the language
aren't going to find it any easier but wasting time looking this up in
textbooks.
That's not going to happen, and it they are casual users of their
compilers, they WILL write semicolons in the wrong place with no errors
reported. Until it bites.
Fixing the language is always the best solution. Failing that, make
compilers report extraneous semicolons.
>> Consistency? I posted a bit of Algol68 the other day; each function
>> definition needed a semicolon, to separate it from the next.
>
> Why do you explicitly name functions here? - Semicolons are a
> general (sequentializing) separator in Algol 68, and not really
> different from other programming languages.
This is my point. Algol68 requires semicolons between function
definitions because its following a simple, consistent rule. C doesn't
require them.
I mean, I'd rather not have to write }; everything, but I'm sure many
will be confused by the inconsistency.
>>> [...]
>>
>> I'm aware of how messy and conistent it is. I've said that languages
>> that use ";" as a separator probably fair better, [...]
>
> (Oh, I thought you said you preferred terminators in languages.)
Both pure separators and pure terminators have issues.
My compromise is not pure.
>> [...]
>>
>> My own made a compromise here: use ";" as separator,
>
> (I know that from Awk, where I regularly use that feature.)
>
>> but introduce some
>> rules so that explicit ";" is rarely need. I think that wins.
>
> Would that then be (like in Awk) that you then assume the line-end
> as separator? (For a scripting language I think it's okay.
What's the difference between a scripting language and any other?
I've always wondered why people think a clean, clear, easy-to-understand
syntax is OK for a scripting language, but is no good at all for a
'REAL' programming language.
Maybe they consider a scripting language is one that needs to be useable
by 'plebs' and others who might not be able to get their head around a
'hard' syntax?
I think those useful properties of a syntax that make it as simple as
pseudo-code, will work across all levels of languages.
(My two languages, systems and scripting, have pretty much the same
syntax. The former needs more type annotations, but such annotations can
appear in some contexts of the scripting language too.
This complete program:
proc main =
for i to 20 do
println i, sqrt i
od
end
since it has no types, works unchanged in both my languages.)
>> I said that my generated code has to use ":;" after each label; it looks
>> weird.
>
> It's funny that you put such an emphasis on labels. - Jumps to
> labels have academically been long deprecated but, more importantly,
> in my practical work I never had a need to use them (or even think
> or considering to use them). (I suppose it's how one got socialized
> to design and write programs.)
So you're one of those who never uses 'goto'. OK.
I'm not. I use 'goto' perhaps once or twice per 1000 lines, because it
is the simplest solution. And use labels a LOT in both generated HLL
code, and in linear IL and ASM targets.
In the Linux kernel code (as of 10 years ago), there were about 140,000
gotos, I think about once in 150 lines on average.
> You obviously have problems on a level that other folks don't have.
I see things on a different level from others because I implement this
stuff, both devising languages and implementing them.
Is that not obvious?
> Janis
>
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-12-05 15:45 +0100 |
| Message-ID | <visea1$1lp5q$1@dont-email.me> |
| In reply to | #389400 |
On 05.12.2024 12:54, Bart wrote: > On 05/12/2024 10:59, Janis Papanagnou wrote: >> On 05.12.2024 00:57, Bart wrote: >>> On 04/12/2024 22:58, Keith Thompson wrote: >>>> Bart <bc@freeuk.com> writes: >>> >>>>> OK, if it's so simple, explain it to me. >>>> >>>> I'll pretend that was a sincere question. >>> >>> Let's put it this way: if somebody asked me what the rule was, I >>> wouldn't be able to tell them. >> >> If that is true I suggest to read one or two textbooks. > > That answer suggests we're talking at cross-purposes. (Always possible.) > > So if the rules really aren't that simple, 100M users of the language > aren't going to find it any easier but wasting time looking this up in > textbooks. I probably have a different view on that than you might have. What I expect is that programmers, before starting programming, learn the language they intend to program in. This is no waste but a necessity. (Although in more recent times I observe also different habits, with the then expected "quality" of output.) Looking things (details?) up if in doubt is also no "waste" of time. If, OTOH, all you wanted to express is that a cleanly defined, coherent language that makes look-ups rare, is better than a quirky language with incoherences, many special cases, and a lousy syntax, then of course I agree with that (as most folks would certainly do). > > That's not going to happen, and it they are casual users of their > compilers, they WILL write semicolons in the wrong place with no errors > reported. Until it bites. Semicolons, really, are not the problem - AFAIR, in *none* of the languages I was engaged with. > > Fixing the language is always the best solution. Failing that, make > compilers report extraneous semicolons. No, the best solution is a language that has been *designed* [in advance] (in the first place). > [...] > > Both pure separators and pure terminators have issues. (Okay, I won't continue on that; I accept that you see or have issues with semicolons.) >>> [...] >>> >>> [ Awk syntax as example ] > > What's the difference between a scripting language and any other? For the purpose here the difference for me was the way how and where I typically use "scripting" languages and languages that are typically compiled respectively. My general point is that I think a syntax should not depend on layout (e.g. use of whitespace, column-specific symbols and semantics, semantics of Tab-indented code, and, the choice of line terminations as a lexical token). Syntax should (IMO) be expressed in terms of visible tokens. (So that a reformatting of source code will not, and IMO should not, change semantics, or even produce errors.) Scripting language seem often defined in a IMO suboptimal, more lax way concerning semicolons. - But I admit, it's certainly not a necessity that scripting languages must be more allowing than non-scripting languages that are used in other contexts. > > I've always wondered why people think a clean, clear, easy-to-understand > syntax is OK for a scripting language, but is no good at all for a > 'REAL' programming language. (I don't know where you get that from.) The attributes you list are important for all types of programming languages. (Would anyone disagree?) (But consider Unix shell; its syntax is neither clean, nor clear, or easy to understand, let alone its semantics. - I'm programming on a daily basis with a Unix shell. I'm used to the syntax but it is a pain and especially nothing comforting for newbies. - Also in scripting languages, you cannot expect good syntax. I would be mollified if newer languages, scripting or else, would at least consider the experiences from inappropriate earlier attempts, but no.) > [...] > >>> I said that my generated code has to use ":;" after each label; it looks >>> weird. >> >> It's funny that you put such an emphasis on labels. - Jumps to >> labels have academically been long deprecated but, more importantly, >> in my practical work I never had a need to use them (or even think >> or considering to use them). (I suppose it's how one got socialized >> to design and write programs.) > > So you're one of those who never uses 'goto'. OK. In fact, yes. But it's not a dogma, if you insinuated that. (I might have used it once or twice, maybe in a some specific case, but I wouldn't bet on that.) It's just that it turned out to be unnecessary to write sophisticated code with 'goto'. It's different in my Unix shell programs; here I'm sure that I used 'break' (occasionally), 'continue' (rarely), 'break <N>' (maybe once or twice). In most cases 'goto' (and 'break' in shell) muddy the clearness of control flow and (IMO) should be avoided. I happen to avoid it just because it never appeared as necessity to even think about using it Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2024-12-06 12:28 +0000 |
| Message-ID | <viuqkf$2a0aq$2@dont-email.me> |
| In reply to | #389408 |
On 05/12/2024 14:45, Janis Papanagnou wrote:
> On 05.12.2024 12:54, Bart wrote:
>> That's not going to happen, and it they are casual users of their
>> compilers, they WILL write semicolons in the wrong place with no errors
>> reported. Until it bites.
>
> Semicolons, really, are not the problem - AFAIR, in *none* of
> the languages I was engaged with.
Not for me either, but for different reasons.
The first few languages I wrote substantial code in (before I started
doing my stuff) didn't use semicolons. (That is, Fortran, assembly and
a machine-oriented language. Assembly did use semicolons for comments;
that was no problem!)
My languages require notional semicolon separators but generally you
don't need to write them in source code.
In a 37Kloc codebase in my syntax, I counted 67 semicolons. Mainly in
the odd place I wrote multiple statements on one line.
In a 39Kloc C codebase, there were 21,500 semicolons.
This is generated C, so some of those may be following labels! 2000,
actually, which still leaves 19,500; a lot of semicolons.
On a preprocessed sql.c test (to remove comments) there were 53,000
semicolons in 85,000 lines.
So in C, they are a very big deal, occuring on every other line. The
lines that don't have one, tend to end in {, or contain only }.
Another interesting statistic: 98.5% of semicolons in generated code,
and 94.5% of those in the sql test, coincident with end-of-line.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-12-07 12:44 +0100 |
| Message-ID | <vj1cem$32akc$1@dont-email.me> |
| In reply to | #389442 |
On 06.12.2024 13:28, Bart wrote: > [...] > > The first few languages I wrote substantial code in (before I started > doing my stuff) didn't use semicolons. (That is, Fortran, assembly and a > machine-oriented language. Assembly did use semicolons for comments; > that was no problem!) Re "Fortran" etc., see one of my recent posts about necessity of syntax, and depreciation and deprecation of other historic formating conventions that carried semantics. Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-12-07 06:51 -0800 |
| Message-ID | <8634izk0lr.fsf@linuxsc.com> |
| In reply to | #389442 |
Bart <bc@freeuk.com> writes: > In a 39Kloc C codebase, there were 21,500 semicolons. > > This is generated C, so some of those may be following labels! > 2000, actually, which still leaves 19,500; a lot of semicolons. > > On a preprocessed sql.c test (to remove comments) there were > 53,000 semicolons in 85,000 lines. > > So in C, they are a very big deal, occuring on every other line. Many years ago I read a book called "How to Lie with Statistics". It should be updated to add this reporting as an example.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2024-12-07 16:15 +0000 |
| Message-ID | <vj1sbr$368fu$1@dont-email.me> |
| In reply to | #389479 |
On 07/12/2024 14:51, Tim Rentsch wrote: > Bart <bc@freeuk.com> writes: > >> In a 39Kloc C codebase, there were 21,500 semicolons. >> >> This is generated C, so some of those may be following labels! >> 2000, actually, which still leaves 19,500; a lot of semicolons. >> >> On a preprocessed sql.c test (to remove comments) there were >> 53,000 semicolons in 85,000 lines. >> >> So in C, they are a very big deal, occuring on every other line. > > Many years ago I read a book called "How to Lie with Statistics". > It should be updated to add this reporting as an example. You're welcome to post your own figures. I know your own code will be out of the ordinary as you prefer using commas (or ?:) to semicolons, and to write things horizontally rather than vertically. Here's one of my few programs that I manually wrote in C: c:\cx>mcc pid Compiling pid.c to pid.exe NLINES= 2219 NSEMIS= 1078 NSEMISATEOL= 1026 It is pretty much exactly what I said. One more (not mine): c:\cx>mcc deltablue Compiling deltablue.c to deltablue.exe NLINES= 1558 NSEMIS= 707 NSEMISATEOL= 652 This one is a bit different: c:\cx>mcc piet Compiling piet.c to piet.exe NLINES= 3267 NSEMIS= 753 NSEMISATEOL= 680 Semicolons occur only every 4 lines or so. Hmm, let's try preprocessing, then compile the processed source: c:\cx>mcc -e piet Preprocessing piet.c to piet.i c:\cx>mcc piet.i Compiling piet.i to piet.exe NLINES= 1331 NSEMIS= 774 NSEMISATEOL= 719 Back to normal! I guess there were a lot of #defines, or something. It's difficult to isolate large, external headers from line counts. But that's not code that /you/ have to write; yours will be the executable code that needs the semicolons!
[toc] | [prev] | [next] | [standalone]
Page 15 of 21 — ← Prev page 1 … 13 14 [15] 16 17 … 21 Next page →
Back to top | Article view | comp.lang.c
csiph-web