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 3 of 21 — ← Prev page 1 2 [3] 4 5 … 21 Next page →
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2024-11-28 08:19 -0300 |
| Message-ID | <vi9jk4$gse4$1@dont-email.me> |
| In reply to | #389164 |
On 28/11/2024 06:25, Keith Thompson wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
>> On 27/11/2024 07:29, Waldek Hebisch wrote:
> [...]
>>> 1) campilers for embedded targets care very much about const. const
>>> qualified arrays go into read-only data section which is typically
>>> located in flash. Other arrays go to RAM. Embedded targets
>>> frequently have very small RAM and larger flash, so after
>>> dropping const program may no longer fit in available RAM.
>>
>> I think your comment applies for const in declarations like
>>
>> const int i = 1;
>>
>> I used to find const confusing, as it sometimes meant 'read-only' and
>> other times 'immutable.'
>
> I'm not sure what you mean. My understanding is that const means
> read-only, and nothing else.
I think my previous comment is not precise; it could be better phrased.
It also have some mistakes about init-declarator.
I will give samples what I was trying to say.
When we have this declaration we are declaring some storage (for the i
variable)
const int i = 0;
But here
void f(const struct X * p);
We are not declaring the storage for the pointed object.
So, for the first case, we can think const as declaring a immutable
storage, while for the second sample const acts as "read-only" - we
don't know if the storage is const or not.
>> Now, it seems less confusing to me. When const is used with variables
>> that can be initialized (init-declarator), it acts as 'immutable',
>> meaning the storage is constant.
>
> What exactly do you mean by "the storage is constant"? Are you talking
> about memory that is marked as read-only by the OS?
Here comes another point (that I realized after I wrote that) and that
makes const more confusing.
When const is used in a external declaration like
const int i = 1;
int main(){}
We can think about read-only marked memory.
But for local variables it does not make sense to have "read-only marked
memory" because it lives on stack.
int main(){
const int i = 1;
}
> Given something like:
>
> const int r = rand();
>
> at block scope, the object will almost certainly be stored in ordinary
> read/write memory. The compiler will flag code that attempts to modify
> it (unless you play tricks with pointer casts, which can introduce
> undefined behavior). But if I do something like `*(int*)&r = 42;`,
> it's likely to "work".
>
> Defining an object as const can *enable* a compiler to store it in
> read-only memory (enforced by the OS, or maybe even physical RAM on some
> systems), but that's an implementation choice, not part of the semantics
> of const.
>
> [...]
>
Yes, you have pointed out, what I realized after writing this.Thanks for
paying attention into these details
const is very context dependent, maybe trying to reuse the same keyword,
and I think C23 had a change to clarify it, but instead make it more
confusing with constexpr, that was the point of my previous topic.
For compile that computation what matters is the guarantee that the
compiler knows the values (it knows because it always the same value of
initialization) when using the object. (It does not depend on flow analysis)
I think const, like in here
const int i = 1;
gives the same guarantee. (The compiler knows the value of i)
What I think could be explored more is the usage of register keyword as
meaning "no-storage".
The idea of const no-storage is good because it eliminates any problem
with object lifetime and it makes the perfect constants in my view.
Unfortunately, constexpr does not mean that because we can take the
address of constexpr object.
Sample why no-storage is useful
void F()
{
register const int i = 1;
//lets way we have lanbdas in C
f( []()
{
//safe to use i even in another thread, or even after exiting F
int k = i;
}
);
}
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2024-11-28 11:38 +0000 |
| Message-ID | <vi9kng$gn4c$1@dont-email.me> |
| In reply to | #389167 |
On 28/11/2024 11:19, Thiago Adams wrote:
> On 28/11/2024 06:25, Keith Thompson wrote:
>> What exactly do you mean by "the storage is constant"? Are you talking
>> about memory that is marked as read-only by the OS?
>
>
> Here comes another point (that I realized after I wrote that) and that
> makes const more confusing.
>
I think 'const' is confusing for similar reasons that VLAs can be both
confusing and awkward to implement.
That's because both really apply to /types/, not directly to variables.
So both const and a VLA can specified deep inside a type-spec, where
there may be no storage allocated, inside a cast for example, but here's
a simpler one:
int n;
const int (*A)[n];
This declares a pointer to a VLA, so no storage is allocated for the
VLA. (I'm not even sure how you'd allocate it in the program, given that
VLAs normally go on the stack.)
And the 'const' applies to the array elements, which here don't exist.
To make the pointer itself const, then 'const' needs to be at the
top-level, which bizarrely needs to go not only in the middle, but
/after/ the pointer which is to be const:
const int (*const A)[n];
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-11-28 11:58 -0800 |
| Message-ID | <87frnbt9jn.fsf@nosuchdomain.example.com> |
| In reply to | #389168 |
Bart <bc@freeuk.com> writes:
[...]
> I think 'const' is confusing for similar reasons that VLAs can be both
> confusing and awkward to implement.
>
> That's because both really apply to /types/, not directly to variables.
Sure. For example, given
const int n = 42;
n is of type `const int`, and &n is of type `consts int*`. Of course
that implies that n itself is const. I'm not sure what's so confusing
about that. If const applied *directly* to variables, it's hard to see
how something like &n could be treated consistently.
"const" has to apply to types anyway. Are you suggesting that it should
have an additional meaning when applied to variables? What would be the
advantage of that?
> So both const and a VLA can specified deep inside a type-spec, where
> there may be no storage allocated, inside a cast for example, but
> here's a simpler one:
>
> int n;
> const int (*A)[n];
>
> This declares a pointer to a VLA, so no storage is allocated for the
> VLA. (I'm not even sure how you'd allocate it in the program, given
> that VLAs normally go on the stack.)
It declares *and defines* (allocates storage for) a pointer to a VLA.
You could allocate the array any way you like. For example:
int n = 42;
const int (*A)[n];
const int vla[n];
A = &vla;
(Though it's hard to see how you'd initialize the elements of `vla`.)
> And the 'const' applies to the array elements, which here don't
> exist.
Right, just as in
const int *ptr;
the const applies to an int object which doesn't yet exist.
> To make the pointer itself const, then 'const' needs to be at
> the top-level, which bizarrely needs to go not only in the middle, but
> /after/ the pointer which is to be const:
>
> const int (*const A)[n];
Yes, C's declaration syntax can be confusing. I almost certainly
wouldn't have done it that way if I were designing the language
from scratch. But it's unambiguous, it's not going to change,
and complaining about it does no good. (Have you ever considered
trying to help people understand it?)
The issue you mention isn't directly related to "const"; it applies
equally to all type qualifiers (const, restrict, volatile, _Atomic).
cdecl is a good tool for unravelling complex declarations. It doesn't
handle VLAs, but there are workarounds for that :
$ cdecl
Type `help' or `?' for help
cdecl> explain const int (*A)[n]
syntax error
cdecl> explain const int (*A)[42]
declare A as pointer to array 42 of const int
So A is a pointer to array n of const int.
--
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-11-28 22:23 +0000 |
| Message-ID | <viaqh0$nm7q$1@dont-email.me> |
| In reply to | #389179 |
On 28/11/2024 19:58, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> I think 'const' is confusing for similar reasons that VLAs can be both
>> confusing and awkward to implement.
>>
>> That's because both really apply to /types/, not directly to variables.
>
> Sure. For example, given
>
> const int n = 42;
>
> n is of type `const int`, and &n is of type `consts int*`. Of course
> that implies that n itself is const.
But that is a separate thing. Suppose T was an alias for 'const int'. Then:
T x; // defines a readonly variable (which probably needs
// initialising)
T* y; // defines a variable pointer
'const' is out of the picture. Other languages tend to have special
keywords that apply to the variable declaration, not the type, for example:
let x:int # non-mutable
var y:int* # mutable (using whatever pointer syntax)
'const' C looks like it works like that, but it doesn't. There also
examples like this:
int const * const p;
Here storage for p is allocated, but it it the second 'const' that makes
it readonly. The first 'const' is not involved in allocation at all.
This is easy to get mixed up.
> I'm not sure what's so confusing
> about that. If const applied *directly* to variables, it's hard to see
> how something like &n could be treated consistently.
>
> "const" has to apply to types anyway. Are you suggesting that it should
> have an additional meaning when applied to variables? What would be the
> advantage of that?
>
>> So both const and a VLA can specified deep inside a type-spec, where
>> there may be no storage allocated, inside a cast for example, but
>> here's a simpler one:
>>
>> int n;
>> const int (*A)[n];
>>
>> This declares a pointer to a VLA, so no storage is allocated for the
>> VLA. (I'm not even sure how you'd allocate it in the program, given
>> that VLAs normally go on the stack.)
>
> It declares *and defines* (allocates storage for) a pointer to a VLA.
> You could allocate the array any way you like. For example:
VLAs are mostly linked to stack allocation. But that only applies when
the array is at the top level of the type spec, in the same why that
it's the top-level 'const' that would determine whether storage is
read-only - if declaring a variable.
As I said, other languages tend to only have that top-level aspect. I
consider that less confusing. I don't think you'd see multiple 'let' or
'mut' keywords within one variable declaration.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-11-28 14:38 -0800 |
| Message-ID | <877c8nt255.fsf@nosuchdomain.example.com> |
| In reply to | #389182 |
Bart <bc@freeuk.com> writes:
> On 28/11/2024 19:58, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> I think 'const' is confusing for similar reasons that VLAs can be both
>>> confusing and awkward to implement.
>>>
>>> That's because both really apply to /types/, not directly to variables.
>> Sure. For example, given
>> const int n = 42;
>> n is of type `const int`, and &n is of type `consts int*`. Of course
>> that implies that n itself is const.
>
> But that is a separate thing. Suppose T was an alias for 'const int'. Then:
>
> T x; // defines a readonly variable (which probably needs
> // initialising)
> T* y; // defines a variable pointer
>
> 'const' is out of the picture.
You say T is an alias (what, a macro?) for 'const int', you show code
using T, and then you say "'const' is out of the picture". If you have
a point, it escapes me.
> Other languages tend to have special
> keywords that apply to the variable declaration, not the type, for
> example:
>
> let x:int # non-mutable
> var y:int* # mutable (using whatever pointer syntax)
Yes, other languages are different. Few, if any, languages that
are not based on C have adopted C's odd declaration syntax.
> 'const' C looks like it works like that, but it doesn't.
It doesn't look like it works like that if you understand how it
actually does work.
> There also
> examples like this:
>
> int const * const p;
>
> Here storage for p is allocated, but it it the second 'const' that
> makes it readonly. The first 'const' is not involved in allocation at
> all. This is easy to get mixed up.
Yes, and you seem determines to make it easier to get mixed up.
[...]
> VLAs are mostly linked to stack allocation. But that only applies when
> the array is at the top level of the type spec, in the same why that
> it's the top-level 'const' that would determine whether storage is
> read-only - if declaring a variable.
>
> As I said, other languages tend to only have that top-level aspect. I
> consider that less confusing. I don't think you'd see multiple 'let'
> or 'mut' keywords within one variable declaration.
Other languages confuse you less than C does. We know.
--
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-11-28 23:05 +0000 |
| Message-ID | <viasv4$nm7q$2@dont-email.me> |
| In reply to | #389183 |
On 28/11/2024 22:38, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 28/11/2024 19:58, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>> I think 'const' is confusing for similar reasons that VLAs can be both
>>>> confusing and awkward to implement.
>>>>
>>>> That's because both really apply to /types/, not directly to variables.
>>> Sure. For example, given
>>> const int n = 42;
>>> n is of type `const int`, and &n is of type `consts int*`. Of course
>>> that implies that n itself is const.
>>
>> But that is a separate thing. Suppose T was an alias for 'const int'. Then:
>>
>> T x; // defines a readonly variable (which probably needs
>> // initialising)
>> T* y; // defines a variable pointer
>>
>> 'const' is out of the picture.
>
> You say T is an alias (what, a macro?) for 'const int', you show code
> using T, and then you say "'const' is out of the picture". If you have
> a point, it escapes me.
Well, can you see 'const' in my example? You can't tell x is readonly by
only looking at this.
> Yes, and you seem determines to make it easier to get mixed up.
C doesn't require any help from me for confusing features. The OP said
it was confusing and I tried to point out why it might be.
Obviously you as C expert will never be confused. But there are lots of
less expert users of the language.
I've just several minutes trying to figure why all these assignments are
invalid:
typedef int* T;
int const x;
T const y;
int* const z;
x=0;
y=0;
z=0;
because I thought would behave differently, with 'const' being the
opposite side of '*' to the base-type.
I forgot that here it would be the right-most 'const' that controls
storage attributes of 'z'.
You will of course say that I'm the only person in the world who could
make that mistake.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-11-28 15:20 -0800 |
| Message-ID | <8734jbt07i.fsf@nosuchdomain.example.com> |
| In reply to | #389184 |
Bart <bc@freeuk.com> writes:
> On 28/11/2024 22:38, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 28/11/2024 19:58, Keith Thompson wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>> [...]
>>>>> I think 'const' is confusing for similar reasons that VLAs can be both
>>>>> confusing and awkward to implement.
>>>>>
>>>>> That's because both really apply to /types/, not directly to variables.
>>>> Sure. For example, given
>>>> const int n = 42;
>>>> n is of type `const int`, and &n is of type `consts int*`. Of course
>>>> that implies that n itself is const.
>>>
>>> But that is a separate thing. Suppose T was an alias for 'const int'. Then:
>>>
>>> T x; // defines a readonly variable (which probably needs
>>> // initialising)
>>> T* y; // defines a variable pointer
>>>
>>> 'const' is out of the picture.
>> You say T is an alias (what, a macro?) for 'const int', you show code
>> using T, and then you say "'const' is out of the picture". If you
>> have a point, it escapes me.
>
> Well, can you see 'const' in my example? You can't tell x is readonly
> by only looking at this.
Yes, you said that T is an alias for 'const int'. Not sure why you
wrote "alias". Is it a macro, or a typedef, or something else?
I suggest that hiding "const" behind a macro or typedef is usually a bad
idea. Why did you do it here? Is your example based on real code, or
did you contrive it to be as confusing as possible?
>> Yes, and you seem determines to make it easier to get mixed up.
>
> C doesn't require any help from me for confusing features.
No, but people using C sometimes require help in resolving their
confusion rather than reinforcing it.
> The OP said
> it was confusing and I tried to point out why it might be.
>
> Obviously you as C expert will never be confused. But there are lots
> of less expert users of the language.
Not true. I am occasionally confused. I just don't brag about it, and
I'd rather help others avoid confusion than add to 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-11-29 00:32 +0000 |
| Message-ID | <vib23k$p0pn$1@dont-email.me> |
| In reply to | #389185 |
On 28/11/2024 23:20, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: >> On 28/11/2024 22:38, Keith Thompson wrote: >>>> T x; // defines a readonly variable (which probably needs >>>> // initialising) >>>> T* y; // defines a variable pointer >>>> >>>> 'const' is out of the picture. >>> You say T is an alias (what, a macro?) for 'const int', you show code >>> using T, and then you say "'const' is out of the picture". If you >>> have a point, it escapes me. >> >> Well, can you see 'const' in my example? You can't tell x is readonly >> by only looking at this. > > Yes, you said that T is an alias for 'const int'. Not sure why you > wrote "alias". Is it a macro, or a typedef, or something else? > > I suggest that hiding "const" behind a macro or typedef is usually a bad > idea. Why did you do it here? Is your example based on real code, or > did you contrive it to be as confusing as possible? It's to illustrate that the constness of a variable may depend on something which is remote from its declaration. Which is unlike how it usually works elsewhere. (And if it matters, the alias used a typedef.) For extra confusion, consider this version: T x, *y; The storage for x is read-only; for y it isn't. Or is it the other way around?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-11-28 18:15 -0800 |
| Message-ID | <87v7w6ss38.fsf@nosuchdomain.example.com> |
| In reply to | #389186 |
Bart <bc@freeuk.com> writes:
> On 28/11/2024 23:20, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 28/11/2024 22:38, Keith Thompson wrote:
>
>>>>> T x; // defines a readonly variable (which probably needs
>>>>> // initialising)
>>>>> T* y; // defines a variable pointer
>>>>>
>>>>> 'const' is out of the picture.
>>>> You say T is an alias (what, a macro?) for 'const int', you show code
>>>> using T, and then you say "'const' is out of the picture". If you
>>>> have a point, it escapes me.
>>>
>>> Well, can you see 'const' in my example? You can't tell x is readonly
>>> by only looking at this.
>> Yes, you said that T is an alias for 'const int'. Not sure why you
>> wrote "alias". Is it a macro, or a typedef, or something else?
>> I suggest that hiding "const" behind a macro or typedef is usually a
>> bad idea. Why did you do it here? Is your example based on real
>> code, or did you contrive it to be as confusing as possible?
>
> It's to illustrate that the constness of a variable may depend on
> something which is remote from its declaration.
>
> Which is unlike how it usually works elsewhere.
>
> (And if it matters, the alias used a typedef.)
>
> For extra confusion, consider this version:
>
> T x, *y;
>
> The storage for x is read-only; for y it isn't. Or is it the other way
> around?
Yes, deliberately confusing code is confusing. Yes, different languages
are different. Any problems with your code snippets can be solved by
writing them more straightforwardly.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-11-29 08:38 +0100 |
| Message-ID | <vibr1l$vvjf$1@dont-email.me> |
| In reply to | #389184 |
On 29/11/2024 00:05, Bart wrote: > On 28/11/2024 22:38, Keith Thompson wrote: >> Bart <bc@freeuk.com> writes: >>> On 28/11/2024 19:58, Keith Thompson wrote: >>>> Bart <bc@freeuk.com> writes: >>>> [...] >>>>> I think 'const' is confusing for similar reasons that VLAs can be both >>>>> confusing and awkward to implement. >>>>> >>>>> That's because both really apply to /types/, not directly to >>>>> variables. >>>> Sure. For example, given >>>> const int n = 42; >>>> n is of type `const int`, and &n is of type `consts int*`. Of course >>>> that implies that n itself is const. >>> >>> But that is a separate thing. Suppose T was an alias for 'const int'. >>> Then: >>> >>> T x; // defines a readonly variable (which probably needs >>> // initialising) >>> T* y; // defines a variable pointer >>> >>> 'const' is out of the picture. >> >> You say T is an alias (what, a macro?) for 'const int', you show code >> using T, and then you say "'const' is out of the picture". If you have >> a point, it escapes me. > > Well, can you see 'const' in my example? You can't tell x is readonly by > only looking at this. > > >> Yes, and you seem determines to make it easier to get mixed up. > > > C doesn't require any help from me for confusing features. The OP said > it was confusing and I tried to point out why it might be. > > Obviously you as C expert will never be confused. But there are lots of > less expert users of the language. > > I've just several minutes trying to figure why all these assignments are > invalid: > > typedef int* T; > > int const x; That one is really simple - clearly "x" is declared "const", and so you can't assign to it later. > T const y; That one is equally simple - clearly "y" is declared "const", and so you can't assign to it later. That shows exactly why it can be a good idea to use "typedef", even for relatively simple things such as adding a pointer or qualifiers to the type. I would not normally make a typedef just for a pointer, or just to add a "const" qualifier, but if the final type is complicated, it can make things clearer. Really, it's just like breaking a complicated expression into parts with extra local variables to name them. > int* const z; > This one requires a little more thought, but it should be well within the capacity of any C programmer to see that "z" is declared "const". > x=0; > y=0; > z=0; > > because I thought would behave differently, with 'const' being the > opposite side of '*' to the base-type. > The "const" in each case clearly applies to the type of the declared variable. > I forgot that here it would be the right-most 'const' that controls > storage attributes of 'z'. > > You will of course say that I'm the only person in the world who could > make that mistake. > I certainly don't say you are the only person in the world who /could/ make that mistake. But if we narrow it down to the C programmers who /would/ make such mistakes, you are in a much smaller group. There are two types of C programmers - those who like to declare variables "const" on a regular basis, and those who rarely if ever do (reserving "const" for things like "const int *" pointers). Those that declare const variables, initialise them at the time, and would not be trying to assign them later. Those who don't have much use of const variables, would not be writing such code in the first place. Basically, I'd only expect to see examples like that in the questions section of a beginner's book on C. And I'd expect anyone who had read the preceding chapter to be able to answer it. C's syntax for types certainly can be confusing and awkward, especially in complex situations. Mix pointers, qualifiers, function types, and array syntax together and you can easily make a mess that will take a lot of effort to unpick. So the answer is /very/ simple - don't do that. Make an effort to write your own types clearly, in a way that makes them obvious to the reader. "typedef" is your friend. If you have a very complex type (which are rare in practice, but do occur), build it in parts with typedefs, and give it a typedef itself. Then it is vastly easier to use multiple times. You might occasionally have to understand someone else's messy type, but you can at least make life easier for yourself. I certainly do that.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2024-11-29 11:04 +0000 |
| Message-ID | <vic73f$1205f$1@dont-email.me> |
| In reply to | #389189 |
On 29/11/2024 07:38, David Brown wrote:
> On 29/11/2024 00:05, Bart wrote:
>> On 28/11/2024 22:38, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> On 28/11/2024 19:58, Keith Thompson wrote:
>>>>> Bart <bc@freeuk.com> writes:
>>>>> [...]
>>>>>> I think 'const' is confusing for similar reasons that VLAs can be
>>>>>> both
>>>>>> confusing and awkward to implement.
>>>>>>
>>>>>> That's because both really apply to /types/, not directly to
>>>>>> variables.
>>>>> Sure. For example, given
>>>>> const int n = 42;
>>>>> n is of type `const int`, and &n is of type `consts int*`. Of course
>>>>> that implies that n itself is const.
>>>>
>>>> But that is a separate thing. Suppose T was an alias for 'const
>>>> int'. Then:
>>>>
>>>> T x; // defines a readonly variable (which probably needs
>>>> // initialising)
>>>> T* y; // defines a variable pointer
>>>>
>>>> 'const' is out of the picture.
>>>
>>> You say T is an alias (what, a macro?) for 'const int', you show code
>>> using T, and then you say "'const' is out of the picture". If you have
>>> a point, it escapes me.
>>
>> Well, can you see 'const' in my example? You can't tell x is readonly
>> by only looking at this.
>>
>>
>>> Yes, and you seem determines to make it easier to get mixed up.
>>
>>
>> C doesn't require any help from me for confusing features. The OP said
>> it was confusing and I tried to point out why it might be.
>>
>> Obviously you as C expert will never be confused. But there are lots
>> of less expert users of the language.
>>
>> I've just several minutes trying to figure why all these assignments
>> are invalid:
>>
>> typedef int* T;
>>
>> int const x;
>
> That one is really simple - clearly "x" is declared "const", and so you
> can't assign to it later.
>
>> T const y;
>
> That one is equally simple - clearly "y" is declared "const", and so you
> can't assign to it later.
>
> That shows exactly why it can be a good idea to use "typedef", even for
> relatively simple things such as adding a pointer or qualifiers to the
> type. I would not normally make a typedef just for a pointer, or just
> to add a "const" qualifier, but if the final type is complicated, it can
> make things clearer. Really, it's just like breaking a complicated
> expression into parts with extra local variables to name them.
>
>> int* const z;
>>
>
> This one requires a little more thought, but it should be well within
> the capacity of any C programmer to see that "z" is declared "const".
These are similar examples:
int * const z1;
int const * z2;
z1=0; // invalid
z2=0; // valid
>> x=0;
>> y=0;
>> z=0;
>>
>> because I thought would behave differently, with 'const' being the
>> opposite side of '*' to the base-type.
>>
>
> The "const" in each case clearly applies to the type of the declared
> variable.
>
>> I forgot that here it would be the right-most 'const' that controls
>> storage attributes of 'z'.
Both 'const' in my new examples are the the right-most one! Yet one
makes the immediate storage const and one doesn't. I guess then that
it's the right-most possible 'const' if it were to be used. In my
example, that would follow the '*'.
>> You will of course say that I'm the only person in the world who could
>> make that mistake.
>>
>
> I certainly don't say you are the only person in the world who /could/
> make that mistake. But if we narrow it down to the C programmers who
> /would/ make such mistakes, you are in a much smaller group.
>
> There are two types of C programmers - those who like to declare
> variables "const" on a regular basis, and those who rarely if ever do
> (reserving "const" for things like "const int *" pointers). Those that
> declare const variables, initialise them at the time, and would not be
> trying to assign them later. Those who don't have much use of const
> variables, would not be writing such code in the first place.
>
> Basically, I'd only expect to see examples like that in the questions
> section of a beginner's book on C. And I'd expect anyone who had read
> the preceding chapter to be able to answer it.
My original point was trying to address why 'const' as used in C might
be confusing. I was trying to compare how non-mutable variables are
designated in other languages. There it's a keyword that is part of the
declaration syntax, not the type syntax.
I suggested that C is confusing because 'const' looks as though it's
like the former, but it's part of the latter. Which also means you can
have multiple 'const' in a declaration (putting asided repeated 'consts').
So objectively, it IS more complicated than elsewhere with more scope
for getting it wrong.
But of course, this group being what it is, people have to turn it round
to make it about me: I'm deliberately trying to show confusing examples.
Or I'm to thick to understand how const works.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@sdf.org> |
|---|---|
| Date | 2024-11-29 12:06 +0000 |
| Message-ID | <slrnvkjbhl.78r.ike@iceland.freeshell.org> |
| In reply to | #389191 |
On 2024-11-29, Bart <bc@freeuk.com> wrote:
> These are similar examples:
>
> int * const z1;
> int const * z2;
>
> z1=0; // invalid
> z2=0; // valid
>
> [snip]
>
> Both 'const' in my new examples are the the right-most one! Yet one
> makes the immediate storage const and one doesn't. I guess then that
> it's the right-most possible 'const' if it were to be used. In my
> example, that would follow the '*'.
The order in which '*' and 'const' appear matters.
With
int * const z1;
the const applies to z1 because it appears immediately before 'z1'.
z1 is a const pointer to int.
(hint: read the declaration out loud from right to left).
*z1 = 0; /* valid */
z1 = 0; /* invalid, z1 is readonly */
With
int const * z2;
the const applies to *z2 because it appears immediately before '* z2'.
*z2 is a const int, z2 is a pointer to const int.
(again, read the declaration out loud from right to left).
*z2 = 0; /* invalid, *z2 is readonly */
z2 = 0; /* valid */
With
int const * const z3;
the leftmost const applies to *z3 and the rightmost const applies to z3.
z3 is a const pointer to const int.
*z3 = 0; /* invalid, *z3 is readonly */
z3 = 0; /* invalid, z3 is readonly */
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-11-29 14:28 +0200 |
| Message-ID | <20241129142810.00007920@yahoo.com> |
| In reply to | #389191 |
On Fri, 29 Nov 2024 11:04:16 +0000 Bart <bc@freeuk.com> wrote: > > My original point was trying to address why 'const' as used in C > might be confusing. I was trying to compare how non-mutable variables > are designated in other languages. There it's a keyword that is part > of the declaration syntax, not the type syntax. > I don't see your point. How 'mut' in Rust is different from 'const' in C except for having opposit polarity? How 'readonly' in C# is different from 'const' in C? > I suggested that C is confusing because 'const' looks as though it's > like the former, but it's part of the latter. Which also means you > can have multiple 'const' in a declaration (putting asided repeated > 'consts'). > IMHO, any way to mix more than one 'modifier' (not in C standard meaning of the word, but in more general meaning) is potentially confusing. It does not matter whether modifier is 'const' or '*' or [] or (). However not having this ability forces programmer to use too many typedefs. Multiple typedef are not too bad by themselves, the problem with them is that programmer has to invent many type names and then reader has to remember them. So in practice such enforcement ends up less readable rather than more readable. > So objectively, it IS more complicated than elsewhere with more scope > for getting it wrong. >
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2024-11-29 13:33 +0000 |
| Message-ID | <vicfra$13nl4$1@dont-email.me> |
| In reply to | #389193 |
On 29/11/2024 12:28, Michael S wrote: > On Fri, 29 Nov 2024 11:04:16 +0000 > Bart <bc@freeuk.com> wrote: > >> >> My original point was trying to address why 'const' as used in C >> might be confusing. I was trying to compare how non-mutable variables >> are designated in other languages. There it's a keyword that is part >> of the declaration syntax, not the type syntax. >> > > I don't see your point. > How 'mut' in Rust is different from 'const' in C except for having > opposit polarity? > How 'readonly' in C# is different from 'const' in C? I'm not familiar enough with those languages. Can mut or readonly be used multiple times within a single type specification? Can they be used in a context where no identifier is involved? If so then they work like C's const does. (My own attempts at 'readonly' used keywords that applied to definitions only, not to types: const [T] a = x # x must be compile-time expr let T b := y # runtime y but b can't be reassigned [var] T c [:= z] # normal fully mutable variable static T d = w # compile/load-time expr I've dropped support for explicit 'let'; it tends to be used internally for implicit assign-once variables like loop indices; or fully readonly data like tables.) > >> I suggested that C is confusing because 'const' looks as though it's >> like the former, but it's part of the latter. Which also means you >> can have multiple 'const' in a declaration (putting asided repeated >> 'consts'). >> > IMHO, any way to mix more than one 'modifier' (not in C standard > meaning of the word, but in more general meaning) is potentially > confusing. It does not matter whether modifier is 'const' or '*' or [] > or (). Constructing an abitrary type specification by chaining together 'modifiers' is not confusing by itself: Pointer to array 10 of const pointer to int x x: Pointer to array 10 of const pointer to int It IS confusing the way C does it, because: * It breaks it up into a base-type ... * ... plus modifiers that go before any identifier ... * ... plus modifiers that go after the identifier * It allows a list of variable names in the same declaration to each have their own modifiers, so each can be a totally different type * This means the type of a variable in a list can be split up into three disjoint parts * It has 'const' that can go before OR after a basic type, or after a modifier that goes before an identifier, but not before or after a modifier that goes after an identifier (so no const array/function) * The 'root' of the type, what would go on the left if expressed in LTR form, is somewhere in the middle of each typespec, starting near the identifier ... * ... except that often there is no identifier, then you have to apply an algorithm to figure out what it means * There are precedence rules which means often having to use parentheses to get the typespec that you want: T*A[] is different from T(*A)[]. Apart from these minor points, typespecs in C are simple! But if C types were LTR, and not split up, then figuring out whether the variable you're declaring was readonly is easy: there would be 'const' on the extreme left. (I would also impose a rule that a 'const' on the left could not appear within a typedef, only at the point the type is used.)
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-11-29 16:15 +0200 |
| Message-ID | <20241129161517.000010b8@yahoo.com> |
| In reply to | #389195 |
On Fri, 29 Nov 2024 13:33:30 +0000 Bart <bc@freeuk.com> wrote: > On 29/11/2024 12:28, Michael S wrote: > > On Fri, 29 Nov 2024 11:04:16 +0000 > > Bart <bc@freeuk.com> wrote: > > > >> > >> My original point was trying to address why 'const' as used in C > >> might be confusing. I was trying to compare how non-mutable > >> variables are designated in other languages. There it's a keyword > >> that is part of the declaration syntax, not the type syntax. > >> > > > > I don't see your point. > > How 'mut' in Rust is different from 'const' in C except for having > > opposit polarity? > > How 'readonly' in C# is different from 'const' in C? > > I'm not familiar enough with those languages. Can mut or readonly be > used multiple times within a single type specification? Can they be > used in a context where no identifier is involved? > > If so then they work like C's const does. > > (My own attempts at 'readonly' used keywords that applied to > definitions only, not to types: > > const [T] a = x # x must be compile-time expr > let T b := y # runtime y but b can't be reassigned > [var] T c [:= z] # normal fully mutable variable > static T d = w # compile/load-time expr > > I've dropped support for explicit 'let'; it tends to be used > internally for implicit assign-once variables like loop indices; or > fully readonly data like tables.) > > > >> I suggested that C is confusing because 'const' looks as though > >> it's like the former, but it's part of the latter. Which also > >> means you can have multiple 'const' in a declaration (putting > >> asided repeated 'consts'). > >> > > > IMHO, any way to mix more than one 'modifier' (not in C standard > > meaning of the word, but in more general meaning) is potentially > > confusing. It does not matter whether modifier is 'const' or '*' or > > [] or (). > > Constructing an abitrary type specification by chaining together > 'modifiers' is not confusing by itself: > > Pointer to array 10 of const pointer to int x > x: Pointer to array 10 of const pointer to int > > It IS confusing the way C does it, because: > > * It breaks it up into a base-type ... > > * ... plus modifiers that go before any identifier ... > > * ... plus modifiers that go after the identifier > Yes, presence of both pre and post 'modifiers' makes things much worse. > * It allows a list of variable names in the same declaration to each > have their own modifiers, so each can be a totally different type > Not in every context. It is not allowed in function prototypes. Even when it is allowed, it's never necessary and avoided by majority of experienced programmers. I'd guess, TimR will disagree with the last part. > * This means the type of a variable in a list can be split up into > three disjoint parts > > * It has 'const' that can go before OR after a basic type, or after > a modifier that goes before an identifier, but not before or after > a modifier that goes after an identifier (so no const array/function) > > * The 'root' of the type, what would go on the left if expressed in > LTR form, is somewhere in the middle of each typespec, starting > near the identifier ... > > * ... except that often there is no identifier, then you have to apply > an algorithm to figure out what it means > > * There are precedence rules which means often having to use > parentheses to get the typespec that you want: T*A[] is different > from T(*A)[]. > > Apart from these minor points, typespecs in C are simple! > > But if C types were LTR, and not split up, then figuring out whether > the variable you're declaring was readonly is easy: there would be > 'const' on the extreme left. > > (I would also impose a rule that a 'const' on the left could not > appear within a typedef, only at the point the type is used.) > >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-11-29 17:42 +0100 |
| Message-ID | <vicque$15ium$2@dont-email.me> |
| In reply to | #389196 |
On 29/11/2024 15:15, Michael S wrote: > On Fri, 29 Nov 2024 13:33:30 +0000 > Bart <bc@freeuk.com> wrote: > >> * It allows a list of variable names in the same declaration to each >> have their own modifiers, so each can be a totally different type >> They can't have "totally different" types - they can have added indirection or array indicators, following C's philosophy of describing the type by how the variable is used: int x, *y, z[10]; Thus "x", "*y" and "z[i]" are all of type "int". C allows this, but I personally would be happier if it did not. As Michael says below, most serious programmers don't write such code. > > Not in every context. It is not allowed in function prototypes. Even > when it is allowed, it's never necessary and avoided by majority of > experienced programmers. > I'd guess, TimR will disagree with the last part. >
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2024-11-29 18:26 +0000 |
| Message-ID | <vid110$16hte$1@dont-email.me> |
| In reply to | #389198 |
On 29/11/2024 16:42, David Brown wrote: > On 29/11/2024 15:15, Michael S wrote: >> On Fri, 29 Nov 2024 13:33:30 +0000 >> Bart <bc@freeuk.com> wrote: >> > >>> * It allows a list of variable names in the same declaration to each >>> have their own modifiers, so each can be a totally different type >>> > > They can't have "totally different" types - they can have added > indirection or array indicators, following C's philosophy of describing > the type by how the variable is used: > > int x, *y, z[10]; > > Thus "x", "*y" and "z[i]" are all of type "int". C's syntax allows a 14-parameter function F to be declared in the same statement as a simple int 'i'. I'd say that F and i are different types! (Actually I wouldn't even consider F to be type, but a function.) That F(1, 2, 3.0, "5", "six", seven, ...) might yield the same type as 'i' is irrelevant here. Usually, given these declarations: int A[100] int *B; int (*C)(); people would consider the types of A, B and C to be array, pointer and function pointer respectively. Otherwise, which of the 4 or 5 possible types would you say that D has here: int D[3][4][5]; It depends on how it is used in an expression, which can be any of &D, D, D[i], D[i][j], D[i][j][k], none of which include 'Array' type! Here's another puzzler: const int F(); why is 'const' allowed here? There is no storage involved. It's not as though you could write 'F = 0' is there was no 'const'. > C allows this, but I personally would be happier if it did not. As > Michael says below, most serious programmers don't write such code. It doesn't matter. If you're implementing the language, you need to allow it. If trying to figure out why some people have trouble understanding, it's something to consider. It's also something to keep in mind if trying to understand somebody else's code: are they making use of that feature or not? So this is a wider view that just dismissing design misfeatures just because you personally won't use them. With the kind of C I would write, you could discard everything after C99, and even half of C99, because the subset I personally use is very conservative.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-11-29 12:35 -0800 |
| Message-ID | <87mshhsrr0.fsf@nosuchdomain.example.com> |
| In reply to | #389199 |
Bart <bc@freeuk.com> writes:
[...]
> C's syntax allows a 14-parameter function F to be declared in the same
> statement as a simple int 'i'.
Yes (except that it's a declaration, not a statement) :
int i = 42, F(int, int, int, int, int, int, int,
int, int, int, int, int, int, int);
Are you under the impression that anyone here was not already aware of
that? Would you prefer it if the number of parameters were arbitrarily
restricted to 13?
Do you think that anyone would actually write code like the above?
C generally doesn't impose arbitrary restrictions. Because of that,
it's possible to write absurd code like the declaration above. 99% of
programmers simply don't do that, so it's not a problem in practice.
> I'd say that F and i are different types! (Actually I wouldn't even
> consider F to be type, but a function.)
Neither F nor i is a type. i is an object (of type int), and F is a
function (of type int(int, int, int, int, int, int, int, int, int, int,
int, int, int, int)).
> That F(1, 2, 3.0, "5", "six", seven, ...) might yield the same type as
> 'i' is irrelevant here.
It's relevant to the syntax. i and F can be declared in the same
declaration only because the type of i and the return type of F happen
to be the same. If F returned void, i and F would have to be declared
separately.
Which, of course, is a good idea anyway.
You're posting repeatedly trying to convince everyone that C allows
ridiculous code. We already know that. You are wasting everyone's time
telling us something that we already know. Most of us just don't obsess
about it as much as you do. Most of us recognize that, however
convoluted C's declaration syntax might be, it cannot be fixed in a
language calling itself "C".
Most of us here are more interested in talking about C as it's
specified, and actually trying to understand it, than in complaining
about it.
> Usually, given these declarations:
>
> int A[100]
> int *B;
> int (*C)();
>
> people would consider the types of A, B and C to be array, pointer and
> function pointer respectively. Otherwise, which of the 4 or 5 possible
> types would you say that D has here:
>
> int D[3][4][5];
>
> It depends on how it is used in an expression, which can be any of &D,
> D, D[i], D[i][j], D[i][j][k], none of which include 'Array' type!
No, the object D unambiguously has type int[3][4][5], or as cdecl
explains it "array 3 of array 4 of array 5 of int". The *expression* D
may have type int[3][4][5] or int(*)[3][4] ("pointer to array 3 of array
4 of int"), depending on the context.
In particular, in &D, the subexpression D is of array type.
You just need to know about implicit array-to-pointer conversions.
Of course you know all about that, but you don't mention it so it
seems more confusing. You know this better than you pretend to.
> Here's another puzzler:
>
> const int F();
>
> why is 'const' allowed here? There is no storage involved. It's not as
> though you could write 'F = 0' is there was no 'const'.
You're right that "const" isn't meaningful in that particular context.
I suspect that it's allowed because adding a rule to forbid it would
have made the standard slightly more complicated with no particular
benefit.
Would you write "const int F();"? Or would you omit the "const"? How
does the fact that "const" is allowed inconvenience you?
[...]
Once again, everyone here already knows that C's declaration syntax can
be confusing, and perhaps other languages do it better. Most of us
would rather try to understand it than whine 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-11-29 21:52 +0000 |
| Message-ID | <vidd2a$18k9j$1@dont-email.me> |
| In reply to | #389200 |
On 29/11/2024 20:35, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> C's syntax allows a 14-parameter function F to be declared in the same
>> statement as a simple int 'i'.
>
> Yes (except that it's a declaration, not a statement) :
>
> int i = 42, F(int, int, int, int, int, int, int,
> int, int, int, int, int, int, int);
>
> Are you under the impression that anyone here was not already aware of
> that? Would you prefer it if the number of parameters were arbitrarily
> restricted to 13?
>
> Do you think that anyone would actually write code like the above?
>
> C generally doesn't impose arbitrary restrictions. Because of that,
> it's possible to write absurd code like the declaration above. 99% of
> programmers simply don't do that, so it's not a problem in practice.
>
>> I'd say that F and i are different types! (Actually I wouldn't even
>> consider F to be type, but a function.)
>
> Neither F nor i is a type. i is an object (of type int), and F is a
> function (of type int(int, int, int, int, int, int, int, int, int, int,
> int, int, int, int)).
>
>> That F(1, 2, 3.0, "5", "six", seven, ...) might yield the same type as
>> 'i' is irrelevant here.
>
> It's relevant to the syntax. i and F can be declared in the same
> declaration only because the type of i and the return type of F happen
> to be the same. If F returned void, i and F would have to be declared
> separately.
>
> Which, of course, is a good idea anyway.
>
> You're posting repeatedly trying to convince everyone that C allows
> ridiculous code. We already know that. You are wasting everyone's time
> telling us something that we already know. Most of us just don't obsess
> about it as much as you do. Most of us recognize that, however
> convoluted C's declaration syntax might be, it cannot be fixed in a
> language calling itself "C".
>
> Most of us here are more interested in talking about C as it's
> specified, and actually trying to understand it, than in complaining
> about it.
>
>> Usually, given these declarations:
>>
>> int A[100]
>> int *B;
>> int (*C)();
>>
>> people would consider the types of A, B and C to be array, pointer and
>> function pointer respectively. Otherwise, which of the 4 or 5 possible
>> types would you say that D has here:
>>
>> int D[3][4][5];
>>
>> It depends on how it is used in an expression, which can be any of &D,
>> D, D[i], D[i][j], D[i][j][k], none of which include 'Array' type!
>
> No, the object D unambiguously has type int[3][4][5]
(So it would have a different type from E declared on in the same
declaration:
int D[3][4][5], E;
? In that case tell that to David Brown!)
You seem have missed the point of my post, which was a reply to David's
remark that 'they can't have totally different types' which was in
response to my saying that each variable in the same declaration can 'be
[of] a totally different type'.
DB is assuming the type of the variable after it's been used in an
expression that is fully evaluated to yield its base type. So my A[100]
is used as A[i], and D[3][4][5] is used as D[i][j][k].
But of course they may be evaluated only partially, yielding a range of
types.
> Would you write "const int F();"? Or would you omit the "const"? How
> does the fact that "const" is allowed inconvenience you?
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 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.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-11-29 15:44 -0800 |
| Message-ID | <8734j9sj0f.fsf@nosuchdomain.example.com> |
| In reply to | #389202 |
Bart <bc@freeuk.com> writes:
> On 29/11/2024 20:35, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> C's syntax allows a 14-parameter function F to be declared in the same
>>> statement as a simple int 'i'.
>> Yes (except that it's a declaration, not a statement) :
>> int i = 42, F(int, int, int, int, int, int, int,
>> int, int, int, int, int, int, int);
>> Are you under the impression that anyone here was not already aware
>> of
>> that? Would you prefer it if the number of parameters were arbitrarily
>> restricted to 13?
>> Do you think that anyone would actually write code like the above?
>> C generally doesn't impose arbitrary restrictions. Because of that,
>> it's possible to write absurd code like the declaration above. 99% of
>> programmers simply don't do that, so it's not a problem in practice.
>>
>>> I'd say that F and i are different types! (Actually I wouldn't even
>>> consider F to be type, but a function.)
>> Neither F nor i is a type. i is an object (of type int), and F is a
>> function (of type int(int, int, int, int, int, int, int, int, int, int,
>> int, int, int, int)).
>>
>>> That F(1, 2, 3.0, "5", "six", seven, ...) might yield the same type as
>>> 'i' is irrelevant here.
>> It's relevant to the syntax. i and F can be declared in the same
>> declaration only because the type of i and the return type of F happen
>> to be the same. If F returned void, i and F would have to be declared
>> separately.
>> Which, of course, is a good idea anyway.
>> You're posting repeatedly trying to convince everyone that C allows
>> ridiculous code. We already know that. You are wasting everyone's time
>> telling us something that we already know. Most of us just don't obsess
>> about it as much as you do. Most of us recognize that, however
>> convoluted C's declaration syntax might be, it cannot be fixed in a
>> language calling itself "C".
>> Most of us here are more interested in talking about C as it's
>> specified, and actually trying to understand it, than in complaining
>> about it.
>>
>>> Usually, given these declarations:
>>>
>>> int A[100]
>>> int *B;
>>> int (*C)();
>>>
>>> people would consider the types of A, B and C to be array, pointer and
>>> function pointer respectively. Otherwise, which of the 4 or 5 possible
>>> types would you say that D has here:
>>>
>>> int D[3][4][5];
>>>
>>> It depends on how it is used in an expression, which can be any of &D,
>>> D, D[i], D[i][j], D[i][j][k], none of which include 'Array' type!
>> No, the object D unambiguously has type int[3][4][5]
>
> (So it would have a different type from E declared on in the same
> declaration:
>
> int D[3][4][5], E;
>
> ? In that case tell that to David Brown!)
Yes, of course D and E have different types. I'm certain he's
aware of that.
I wrote that the object D is unambiguously of type int[3][4][5], and the
expression D can be of the array type int[3][4][5] or of the pointer
type int(*)[3][4], depending on the context. Do you agree? Or do you
still claim that D can have any of "4 or 5 possible types"?
(Note that I'm not talking about the type of the expression D[i] or of
any other expression that includes D as a subexpression.)
> You seem have missed the point of my post, which was a reply to
> David's remark that 'they can't have totally different types' which
> was in response to my saying that each variable in the same
> declaration can 'be [of] a totally different type'.
David apparently has a different definition of "totally different types"
than you do. Since the standard doesn't define that phrase, I suggest
not wasting time arguing about it.
Given:
int D[3][4][5], E;
the object D is of type int[3][4][5], and E is of type int. Do you
understand that?
If you wanted to change the type of D from int[3][4][5] to
double[3][4][5], you'd have to use two separate declarations.
Do you understand that? (Of course you do, but will you admit that
you understand it?)
I think that distinction is what David had in mind. double[3][4][5] and
int are "totally different types", but int[3][4][5] and int are not.
Entities of "totally different types" cannot be declared in a single
declaration. You don't have to accept that meaning of the phrase (which
I find a bit vague), but it's clearly what David meant.
The point is that there are restrictions on what can be combined into a
single declaration. But these days it's usually considered good style
to declare only one identifier in each declaration, so while this :
int i, *p;
is perfectly valid, and every C compiler must accept it, this :
int i;
int *p;
is preferred by most C programmers.
Do you understand that?
> DB is assuming the type of the variable after it's been used in an
> expression that is fully evaluated to yield its base type. So my
> A[100] is used as A[i], and D[3][4][5] is used as D[i][j][k].
>
> But of course they may be evaluated only partially, yielding a range
> of types.
What "range of types" do you think D can have?
>> Would you write "const int F();"? Or would you omit the "const"? How
>> does the fact that "const" is allowed inconvenience you?
>
> 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.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
Page 3 of 21 — ← Prev page 1 2 [3] 4 5 … 21 Next page →
Back to top | Article view | comp.lang.c
csiph-web