Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #384794 > unrolled thread
| Started by | David Brown <david.brown@hesbynett.no> |
|---|---|
| First post | 2024-05-22 18:55 +0200 |
| Last post | 2024-05-25 16:05 -0500 |
| Articles | 20 on this page of 542 — 23 participants |
Back to article view | Back to comp.lang.c
C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-22 18:55 +0200
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-05-22 14:42 -0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-22 22:11 +0200
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-05-22 17:26 -0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-23 14:17 +0200
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-05-23 09:38 -0300
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-05-23 17:08 +0000
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-05-23 16:06 -0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-23 15:11 +0200
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-05-23 13:21 -0300
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-23 14:49 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-24 11:03 +0200
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-05-24 14:17 -0300
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-24 12:45 -0700
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-05-24 17:06 -0300
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-24 13:19 -0700
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-05-24 21:27 -0300
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-24 17:46 -0700
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-05-25 08:33 -0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-25 16:51 +0200
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-25 16:34 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-25 13:05 +0200
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-05-25 08:19 -0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-25 17:14 +0200
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-26 02:09 +0100
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-06-06 15:01 -0300
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-22 15:53 -0700
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-05-22 22:21 -0300
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-23 13:11 +0100
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-23 09:43 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-24 16:19 +0200
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-23 15:25 +0200
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-23 13:06 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-24 15:45 +0200
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-24 18:29 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-25 13:11 +0200
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-25 15:58 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-26 13:09 +0200
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-26 12:51 +0100
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-26 16:18 +0300
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-26 16:25 +0100
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-26 19:35 +0300
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-26 19:01 +0100
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-26 23:26 +0300
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-26 22:27 +0100
Re: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-26 19:19 +0100
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-26 23:06 +0300
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-27 00:49 +0000
Re: C23 thoughts and opinions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-26 19:54 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-27 11:10 +0200
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-26 23:59 +0300
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-26 22:52 +0100
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-26 16:20 -0700
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-27 00:48 +0000
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-27 11:05 +0300
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-05-26 10:12 -0300
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-26 16:17 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-27 13:42 +0200
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-27 17:33 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-28 13:52 +0200
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-28 13:21 -0700
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-28 23:37 +0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-29 10:02 +0200
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-14 14:30 -0700
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-14 23:39 +0100
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-15 19:17 +0200
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-15 20:27 +0100
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-15 22:39 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-16 00:20 +0100
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-16 01:16 +0000
Re: C23 thoughts and opinions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-16 12:31 -0700
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-17 00:03 +0000
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-16 16:54 +0200
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-16 20:00 +0100
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-17 10:49 +0200
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-17 13:18 +0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-15 17:58 +0200
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-15 22:37 +0000
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-16 16:55 +0200
Hex string literals (was Re: C23 thoughts and opinions) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-16 16:48 -0700
Re: Hex string literals (was Re: C23 thoughts and opinions) David Brown <david.brown@hesbynett.no> - 2024-06-17 11:42 +0200
Re: Hex string literals (was Re: C23 thoughts and opinions) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-17 17:19 -0700
Re: Hex string literals (was Re: C23 thoughts and opinions) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-18 04:19 +0000
Re: Hex string literals (was Re: C23 thoughts and opinions) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-17 22:39 -0700
Re: Hex string literals (was Re: C23 thoughts and opinions) David Brown <david.brown@hesbynett.no> - 2024-06-18 15:54 +0200
Re: Hex string literals (was Re: C23 thoughts and opinions) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-18 15:00 -0700
Re: Hex string literals (was Re: C23 thoughts and opinions) David Brown <david.brown@hesbynett.no> - 2024-06-19 09:37 +0200
Re: Hex string literals (was Re: C23 thoughts and opinions) Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-19 10:17 +0000
Re: Hex string literals (was Re: C23 thoughts and opinions) Michael S <already5chosen@yahoo.com> - 2024-06-19 13:44 +0300
Re: Hex string literals (was Re: C23 thoughts and opinions) bart <bc@freeuk.com> - 2024-06-19 11:57 +0100
Re: Hex string literals (was Re: C23 thoughts and opinions) scott@slp53.sl.home (Scott Lurndal) - 2024-06-19 13:46 +0000
Re: Hex string literals (was Re: C23 thoughts and opinions) Michael S <already5chosen@yahoo.com> - 2024-06-19 18:02 +0300
Re: Hex string literals (was Re: C23 thoughts and opinions) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-19 07:25 +0000
Re: Hex string literals (was Re: C23 thoughts and opinions) David Brown <david.brown@hesbynett.no> - 2024-06-19 10:49 +0200
Re: Hex string literals (was Re: C23 thoughts and opinions) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-21 07:13 +0000
Re: Hex string literals (was Re: C23 thoughts and opinions) David Brown <david.brown@hesbynett.no> - 2024-06-21 13:06 +0200
Re: Hex string literals (was Re: C23 thoughts and opinions) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-21 22:48 +0000
Re: Hex string literals (was Re: C23 thoughts and opinions) David Brown <david.brown@hesbynett.no> - 2024-06-22 13:40 +0200
Re: Hex string literals (was Re: C23 thoughts and opinions) James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-21 10:15 -0400
Re: Hex string literals (was Re: C23 thoughts and opinions) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-19 02:32 -0700
Re: Hex string literals (was Re: C23 thoughts and opinions) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-18 04:19 +0000
Re: Hex string literals (was Re: C23 thoughts and opinions) Richard Kettlewell <invalid@invalid.invalid> - 2024-06-17 11:41 +0100
Re: Hex string literals (was Re: C23 thoughts and opinions) Richard Kettlewell <invalid@invalid.invalid> - 2024-06-17 14:57 +0100
Re: Hex string literals (was Re: C23 thoughts and opinions) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-17 18:57 -0700
Re: Hex string literals (was Re: C23 thoughts and opinions) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-18 08:12 +0000
Re: Hex string literals (was Re: C23 thoughts and opinions) Richard Kettlewell <invalid@invalid.invalid> - 2024-06-18 16:14 +0100
Re: Hex string literals (was Re: C23 thoughts and opinions) bart <bc@freeuk.com> - 2024-06-17 14:21 +0100
Re: Hex string literals (was Re: C23 thoughts and opinions) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-17 19:20 -0700
Re: Hex string literals (was Re: C23 thoughts and opinions) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-17 22:39 -0700
Re: Hex string literals (was Re: C23 thoughts and opinions) Michael S <already5chosen@yahoo.com> - 2024-06-18 12:39 +0300
Re: Hex string literals (was Re: C23 thoughts and opinions) bart <bc@freeuk.com> - 2024-06-18 11:28 +0100
Re: Hex string literals (was Re: C23 thoughts and opinions) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-18 11:12 -0700
Re: Hex string literals (was Re: C23 thoughts and opinions) David Brown <david.brown@hesbynett.no> - 2024-06-18 17:20 +0200
Re: Hex string literals (was Re: C23 thoughts and opinions) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-18 11:04 -0700
Re: Hex string literals (was Re: C23 thoughts and opinions) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-20 06:51 +0000
Re: Hex string literals (was Re: C23 thoughts and opinions) Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-18 09:50 +0000
Re: Hex string literals (was Re: C23 thoughts and opinions) scott@slp53.sl.home (Scott Lurndal) - 2024-06-18 13:56 +0000
Re: Hex string literals (was Re: C23 thoughts and opinions) David Brown <david.brown@hesbynett.no> - 2024-06-18 17:21 +0200
Re: Hex string literals (was Re: C23 thoughts and opinions) Richard Harnden <richard.nospam@gmail.invalid> - 2024-06-18 19:25 +0100
Re: Hex string literals (was Re: C23 thoughts and opinions) Richard Harnden <richard.nospam@gmail.invalid> - 2024-06-18 19:38 +0100
Re: Hex string literals (was Re: C23 thoughts and opinions) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-21 22:49 +0000
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-05-28 00:20 +0000
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-27 17:59 -0700
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-05-28 15:42 +0000
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-28 13:44 -0700
Re: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-28 05:36 +0100
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-05-28 15:53 +0000
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-27 00:44 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-27 01:55 +0100
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-27 02:48 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-27 14:03 +0100
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-28 02:45 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-28 11:30 +0100
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-29 04:17 +0000
Re: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-29 06:00 +0100
Re: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-29 13:58 +0200
Re: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-29 17:20 +0100
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-30 02:32 +0000
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-30 11:09 +0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-30 13:43 +0200
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-01 01:45 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-30 14:34 +0100
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-30 17:08 +0300
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-30 15:48 +0100
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-30 18:03 +0300
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-31 13:55 +0100
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-31 16:19 +0300
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-31 16:28 +0300
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-31 16:48 +0300
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-31 15:04 +0100
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-31 17:34 +0300
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-31 19:03 +0100
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-05-31 18:36 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-31 22:15 +0100
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-01 01:25 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-01 11:24 +0100
Re: C23 thoughts and opinions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-01 05:17 -0700
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-01 15:08 +0000
Re: C23 thoughts and opinions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-01 17:22 -0700
objcopy -I binary etc... Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-06 14:56 +0300
Re: objcopy -I binary etc... Was: C23 thoughts and opinions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-06 07:44 -0700
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-01 22:51 +0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-01 15:24 +0200
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-01 19:59 +0100
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-04 04:00 +0000
Re: Correct objcopy Usage (was Re: C23 thoughts and opinions) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-04 04:33 +0000
Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-06-01 03:37 +0200
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-01 11:09 +0100
Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-06-01 13:59 +0200
Re: C23 thoughts and opinions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-01 17:26 -0700
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-02 01:11 +0300
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-02 00:39 +0100
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-02 03:06 +0300
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-06 14:43 +0300
Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-05-31 21:42 +0200
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-05-31 21:11 +0000
Re: C23 thoughts and opinions BGB-Alt <bohannonindustriesllc@gmail.com> - 2024-06-06 15:38 -0500
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-06 21:38 +0000
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-07 00:51 -0500
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-07 09:04 +0000
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-07 10:20 -0500
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-07 10:22 -0500
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-07 00:53 +0000
Re: C23 thoughts and opinions BGB-Alt <bohannonindustriesllc@gmail.com> - 2024-06-07 16:58 -0500
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-08 03:08 +0000
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-08 00:04 -0500
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-08 08:27 +0000
Re: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-13 14:14 +0200
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-13 14:07 -0500
Re: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-14 08:53 +0200
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-14 03:13 -0500
Re: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-14 10:26 +0200
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-14 03:38 -0500
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-15 22:42 +0000
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-15 20:42 -0500
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-16 03:15 +0000
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-08 13:09 +0000
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-09 00:46 +0000
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-09 11:19 +0300
Re: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-08 19:28 +0100
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-08 14:52 -0500
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-09 12:40 +0300
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-09 11:20 +0100
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-09 14:12 +0300
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-09 14:44 +0300
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-09 17:32 +0100
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-09 20:00 +0300
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-09 21:06 +0100
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-09 23:40 +0300
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-09 22:49 +0100
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-10 01:06 +0300
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-10 01:26 +0100
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-11 08:33 +0000
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-09 21:12 -0500
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-09 00:45 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-31 22:17 +0100
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-01 21:11 +0300
Re: C23 thoughts and opinions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-01 17:47 -0700
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-31 15:03 +0100
Re: C23 thoughts and opinions Kaz Kylheku <643-408-1753@kylheku.com> - 2024-05-31 15:34 +0000
Re: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-31 20:31 +0100
Re: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-01 01:53 +0100
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-01 11:53 +0100
Re: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-01 16:51 +0100
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-31 09:24 +0200
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-31 13:39 +0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-31 13:31 +0200
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-30 17:51 +0300
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-01 01:39 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-01 11:37 +0100
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-02 03:27 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-02 10:37 +0100
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-03 01:16 +0000
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-03 11:16 +0300
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-04 02:10 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-04 12:28 +0100
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-05 01:51 +0000
Re: C23 thoughts and opinions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-04 19:45 -0700
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-03 11:13 +0100
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-04 02:12 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-04 12:35 +0100
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-05 01:50 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-05 09:10 +0100
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-06-05 09:23 -0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-05 15:09 +0200
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-06 02:12 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-06 19:38 +0100
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-07 00:55 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-07 22:23 +0100
Re: C23 thoughts and opinions Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-08 00:39 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-08 02:14 +0100
Re: C23 thoughts and opinions Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-08 03:55 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-08 11:14 +0100
Re: C23 thoughts and opinions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-07 22:36 -0700
xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-28 14:41 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-28 15:06 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-28 17:42 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-28 18:56 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-28 18:14 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-28 19:20 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-28 19:57 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-28 23:23 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-29 00:45 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-29 01:29 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-29 09:21 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-29 12:44 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-28 23:08 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-29 01:24 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-30 02:35 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions Paul <nospam@needed.invalid> - 2024-05-30 00:40 -0400
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-30 10:40 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions Paul <nospam@needed.invalid> - 2024-05-30 14:04 -0400
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-30 22:31 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions Paul <nospam@needed.invalid> - 2024-05-31 15:20 -0400
Re: xxd -i vs DIY Was: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-05-30 19:47 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-03 03:15 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-03 08:57 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-03 07:59 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-03 11:02 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions Paul <nospam@needed.invalid> - 2024-06-03 14:41 -0400
Re: xxd -i vs DIY Was: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-04 02:07 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-30 14:41 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-29 00:54 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-29 10:32 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-29 13:08 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-29 14:10 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-29 15:27 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-29 15:19 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-29 14:38 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-29 15:43 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-29 14:57 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-03 07:54 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-29 17:27 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-29 19:27 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-05-29 14:07 -0400
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-29 22:59 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-29 22:46 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-30 01:18 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-30 02:31 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-30 12:23 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-30 14:40 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-30 14:21 -0700
Re: xxd -i vs DIY Was: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-30 16:41 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-03 08:31 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions Paul <nospam@needed.invalid> - 2024-05-30 00:06 -0400
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-30 13:31 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-30 15:15 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-30 16:09 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-03 08:29 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-30 16:50 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-05-30 16:00 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-30 18:28 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-03 03:10 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-30 10:01 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-30 11:33 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-30 12:13 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-30 14:14 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-03 07:51 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-03 03:12 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-03 10:57 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-29 12:38 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-29 12:23 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-29 15:23 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-29 15:16 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-29 18:32 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-29 18:41 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-29 21:31 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-03 07:49 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-03 13:01 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-29 10:18 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-28 17:34 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-29 22:08 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-30 15:05 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Paul <nospam@needed.invalid> - 2024-05-30 14:20 -0400
Re: xxd -i vs DIY Was: C23 thoughts and opinions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-30 12:27 -0700
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-31 09:55 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-31 13:45 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-31 13:33 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-02 04:19 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-02 13:40 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-02 04:16 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-03 18:39 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-04 02:07 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-04 04:46 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-04 03:58 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-04 09:52 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-04 11:01 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-04 10:34 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Paul <nospam@needed.invalid> - 2024-06-03 22:46 -0400
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-28 13:54 -0700
Re: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-29 01:03 +0100
Re: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-12 20:32 +0200
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-05-22 22:23 -0300
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-23 02:59 +0000
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-22 21:08 -0700
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-23 04:20 +0000
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-23 04:47 +0000
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-22 21:30 -0700
Re: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-23 07:29 +0100
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-23 14:32 +0200
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-23 13:37 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-23 15:31 +0200
Re: C23 thoughts and opinions Kaz Kylheku <643-408-1753@kylheku.com> - 2024-05-23 20:23 +0000
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-24 16:25 +0200
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-23 20:31 +0300
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-23 14:28 -0700
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-05-23 17:10 +0000
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-23 15:43 +0300
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-23 02:49 +0000
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-05-23 16:40 +0000
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-23 15:36 +0300
Re: C23 thoughts and opinions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-22 14:24 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-23 15:35 +0200
Re: C23 thoughts and opinions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-23 16:05 -0700
Re: C23 thoughts and opinions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-23 16:17 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-24 16:50 +0200
Re: C23 thoughts and opinions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-24 11:08 -0700
Re: C23 thoughts and opinions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-24 11:21 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-25 13:22 +0200
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-24 23:51 +0000
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-23 03:13 +0000
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-23 15:42 +0200
Re: C23 thoughts and opinions - why so conservative? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-05-23 14:35 -0400
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-23 09:40 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-24 17:10 +0200
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-24 12:29 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-25 13:29 +0200
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-25 16:21 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-26 16:15 +0200
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-23 15:02 +0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-23 15:56 +0200
Re: C23 thoughts and opinions BGB-Alt <bohannonindustriesllc@gmail.com> - 2024-05-23 17:15 -0500
Re: C23 thoughts and opinions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-23 17:37 -0700
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-24 12:05 +0300
Re: C23 thoughts and opinions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-24 06:54 -0700
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-24 18:46 +0300
Re: C23 thoughts and opinions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-25 03:01 -0700
Re: C23 thoughts and opinions - why so conservative? Michael S <already5chosen@yahoo.com> - 2024-05-23 17:19 +0300
Re: C23 thoughts and opinions - why so conservative? David Brown <david.brown@hesbynett.no> - 2024-05-23 22:10 +0200
Re: C23 thoughts and opinions - why so conservative? Michael S <already5chosen@yahoo.com> - 2024-05-24 00:34 +0300
Re: C23 thoughts and opinions - why so conservative? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-24 01:06 +0000
Re: C23 thoughts and opinions - why so conservative? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-24 07:47 +0100
Re: C23 thoughts and opinions - why so conservative? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-25 00:31 +0000
Re: C23 thoughts and opinions - why so conservative? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-24 06:38 +0100
Re: C23 thoughts and opinions - why so conservative? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-24 05:42 +0000
Re: C23 thoughts and opinions - why so conservative? Michael S <already5chosen@yahoo.com> - 2024-05-24 11:42 +0300
Re: C23 thoughts and opinions - why so conservative? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-23 18:35 -0700
Re: C23 thoughts and opinions - why so conservative? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-23 19:42 -0700
Re: C23 thoughts and opinions - why so conservative? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-23 20:28 -0700
Re: C23 thoughts and opinions - why so conservative? David Brown <david.brown@hesbynett.no> - 2024-05-24 17:57 +0200
Re: C23 thoughts and opinions - why so conservative? scott@slp53.sl.home (Scott Lurndal) - 2024-05-24 16:16 +0000
Re: C23 thoughts and opinions - why so conservative? David Brown <david.brown@hesbynett.no> - 2024-05-25 16:41 +0200
Re: C23 thoughts and opinions - why so conservative? Michael S <already5chosen@yahoo.com> - 2024-05-24 19:22 +0300
Re: C23 thoughts and opinions - why so conservative? bart <bc@freeuk.com> - 2024-05-24 19:38 +0100
Re: C23 thoughts and opinions - why so conservative? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-24 13:06 -0700
Re: C23 thoughts and opinions - why so conservative? bart <bc@freeuk.com> - 2024-05-24 21:20 +0100
Re: C23 thoughts and opinions - why so conservative? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-25 00:32 +0000
Re: C23 thoughts and opinions - why so conservative? David Brown <david.brown@hesbynett.no> - 2024-05-25 17:28 +0200
Re: errno (was Re: C23 thoughts and opinions - why so conservative?) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-25 00:40 +0000
Re: errno (was Re: C23 thoughts and opinions - why so conservative?) David Brown <david.brown@hesbynett.no> - 2024-05-25 17:47 +0200
Re: errno (was Re: C23 thoughts and opinions - why so conservative?) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-25 16:45 -0700
Re: errno (was Re: C23 thoughts and opinions - why so conservative?) David Brown <david.brown@hesbynett.no> - 2024-05-26 16:18 +0200
Re: errno (was Re: C23 thoughts and opinions - why so conservative?) BGB <cr88192@gmail.com> - 2024-05-26 09:48 -0500
Re: errno (was Re: C23 thoughts and opinions - why so conservative?) David Brown <david.brown@hesbynett.no> - 2024-05-26 18:12 +0200
Re: errno (was Re: C23 thoughts and opinions - why so conservative?) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-28 02:48 +0000
Re: errno (was Re: C23 thoughts and opinions - why so conservative?) BGB <cr88192@gmail.com> - 2024-05-28 01:31 -0500
Re: errno (was Re: C23 thoughts and opinions - why so conservative?) James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-05-29 11:27 -0400
Re: errno (was Re: C23 thoughts and opinions - why so conservative?) BGB-Alt <bohannonindustriesllc@gmail.com> - 2024-05-30 14:18 -0500
Re: errno (was Re: C23 thoughts and opinions - why so conservative?) David Brown <david.brown@hesbynett.no> - 2024-05-28 13:56 +0200
Re: errno (was Re: C23 thoughts and opinions - why so conservative?) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-27 20:26 -0700
Re: errno (was Re: C23 thoughts and opinions - why so conservative?) James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-05-26 18:59 -0400
Re: errno (was Re: C23 thoughts and opinions - why so conservative?) BGB <cr88192@gmail.com> - 2024-05-25 15:23 -0500
Re: C23 thoughts and opinions - why so conservative? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-23 14:38 -0700
Re: C23 thoughts and opinions - why so conservative? Michael S <already5chosen@yahoo.com> - 2024-05-24 00:48 +0300
Re: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-23 21:25 +0200
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-05-23 16:49 -0300
Re: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-24 07:36 +0200
Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-05-24 09:32 +0200
Re: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-24 18:34 +0200
Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-05-26 09:13 +0200
Re: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-26 13:23 +0200
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-27 00:55 +0000
Re: C23 thoughts and opinions Lynn McGuire <lynnmcguire5@gmail.com> - 2024-05-31 18:34 -0500
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-01 01:27 +0000
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-02 11:02 +0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-02 14:03 +0200
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-02 16:29 +0300
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-02 19:23 +0000
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-02 21:44 +0200
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-03 12:00 +0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-03 18:34 +0200
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-03 16:50 +0000
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-03 21:05 +0200
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-03 19:38 +0000
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-03 22:58 +0300
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-03 21:22 +0000
Re: C23 thoughts and opinions Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-04 05:17 +0000
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-04 11:23 +0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-04 10:25 +0200
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-04 13:30 +0000
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-04 12:48 -0500
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-04 19:17 +0000
Re: C23 thoughts and opinions BGB-Alt <bohannonindustriesllc@gmail.com> - 2024-06-04 17:32 -0500
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-05 07:22 +0000
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-05 07:14 +0000
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-05 04:01 -0500
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-07 00:57 +0000
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-07 02:52 -0500
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-14 03:20 +0000
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-05 07:15 +0000
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-05 13:32 +0000
Re: C23 thoughts and opinions cross@spitfire.i.gajendra.net (Dan Cross) - 2024-06-05 13:59 +0000
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-07 00:59 +0000
Re: C23 thoughts and opinions Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-04 05:12 +0000
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-04 06:55 +0000
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-02 19:15 +0000
Re: C23 thoughts and opinions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-02 12:46 -0700
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-03 03:21 +0000
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-03 14:16 +0000
Re: C23 thoughts and opinions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-03 13:23 -0700
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-04 13:46 -0500
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-04 19:21 +0000
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-04 20:44 -0500
Re: C23 thoughts and opinions Paul <nospam@needed.invalid> - 2024-06-04 23:59 -0400
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-05 00:44 -0500
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-05 13:29 +0000
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-05 13:49 -0500
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-03 21:14 +0200
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-01 15:28 +0200
Re: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-01 16:33 +0100
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-02 03:28 +0000
Re: C23 thoughts and opinions Kaz Kylheku <643-408-1753@kylheku.com> - 2024-05-25 21:24 +0000
Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-05-26 08:32 +0200
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-26 02:48 -0700
Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-05-26 13:44 +0200
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-26 15:39 +0300
Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-05-26 15:46 +0200
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-26 17:20 +0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-26 16:29 +0200
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-26 18:05 +0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-26 18:26 +0200
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-26 19:50 +0300
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-28 05:41 +0000
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-28 10:46 +0300
Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-05-26 17:10 +0200
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-26 18:23 +0300
Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-05-26 19:23 +0200
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-26 18:36 +0200
Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-05-26 19:11 +0200
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-26 16:30 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-27 10:45 +0200
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-28 05:45 +0000
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-26 13:53 -0700
Re: C23 thoughts and opinions Kaz Kylheku <643-408-1753@kylheku.com> - 2024-05-26 21:16 +0000
Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-05-27 07:14 +0200
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-27 00:53 +0000
Re: C23 thoughts and opinions Kaz Kylheku <643-408-1753@kylheku.com> - 2024-05-26 21:03 +0000
Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-05-26 08:44 +0200
Don't let the door hit you... (Was: C23 thoughts and opinions) gazelle@shell.xmission.com (Kenny McCormack) - 2024-05-23 19:58 +0000
Re: Don't let the door hit you... (Was: C23 thoughts and opinions) Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-24 18:35 +0200
Re: C23 thoughts and opinions Lynn McGuire <lynnmcguire5@gmail.com> - 2024-05-31 17:55 -0500
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-01 15:30 +0200
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-02 03:29 +0000
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-01 23:31 -0700
Re: C23 thoughts and opinions gazelle@shell.xmission.com (Kenny McCormack) - 2024-06-02 13:24 +0000
Re: C23 thoughts and opinions Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-06-02 16:51 +0000
Re: C23 thoughts and opinions Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-02 19:52 +0000
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-03 12:01 +0300
Re: C23 thoughts and opinions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-03 13:31 -0700
Re: C23 thoughts and opinions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-03 14:02 -0700
Re: C23 thoughts and opinions gazelle@shell.xmission.com (Kenny McCormack) - 2024-06-03 21:48 +0000
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-04 10:36 +0200
Re: C23 thoughts and opinions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-04 14:47 -0700
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-03 23:43 +0100
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-03 16:23 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-04 10:47 +0200
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-04 02:20 +0000
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-04 10:47 +0200
Re: C23 thoughts and opinions Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-04 05:25 +0000
Re: C23 thoughts and opinions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-03 13:29 -0700
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-05-24 21:35 -0300
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-05-25 16:05 -0500
Page 1 of 28 [1] 2 3 … 28 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-05-22 18:55 +0200 |
| Subject | C23 thoughts and opinions |
| Message-ID | <v2l828$18v7f$1@dont-email.me> |
In an attempt to bring some topicality to the group, has anyone started using, or considering, C23 ? There's quite a lot of change in it, especially compared to the minor changes in C17. <https://open-std.org/JTC1/SC22/WG14/www/docs/n3220.pdf> <https://en.wikipedia.org/wiki/C23_(C_standard_revision)> <https://en.cppreference.com/w/c/23> I like that it tidies up a lot of old stuff - it is neater to have things like "bool", "static_assert", etc., as part of the language rather than needing a half-dozen includes for such basic stuff. I like that it standardises a several useful extensions that have been in gcc and clang (and possibly other compilers) for many years. I'm not sure it will make a big difference to my own programming - when I want "typeof" or "chk_add()", I already use them in gcc. But for people restricted to standard C, there's more new to enjoy. And I prefer to use standard syntax when possible. "constexpr" is something I think I will find helpful, in at least some circumstances.
[toc] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2024-05-22 14:42 -0300 |
| Message-ID | <00297443-2fee-48d4-81a0-9ff6ae6481e4@gmail.com> |
| In reply to | #384794 |
On 22/05/2024 13:55, David Brown wrote: > In an attempt to bring some topicality to the group, has anyone started > using, or considering, C23 ? There's quite a lot of change in it, > especially compared to the minor changes in C17. > > <https://open-std.org/JTC1/SC22/WG14/www/docs/n3220.pdf> > <https://en.wikipedia.org/wiki/C23_(C_standard_revision)> > <https://en.cppreference.com/w/c/23> > > I like that it tidies up a lot of old stuff - it is neater to have > things like "bool", "static_assert", etc., as part of the language > rather than needing a half-dozen includes for such basic stuff. > > I like that it standardises a several useful extensions that have been > in gcc and clang (and possibly other compilers) for many years. > > I'm not sure it will make a big difference to my own programming - when > I want "typeof" or "chk_add()", I already use them in gcc. But for > people restricted to standard C, there's more new to enjoy. And I > prefer to use standard syntax when possible. > > "constexpr" is something I think I will find helpful, in at least some > circumstances. I am waiting MSVC support. There are a lot of simple features MSVC could implement and deliver in small increments. But it is very slow. I am would use today if I had. - #warning - [[nodiscard]] - typeof - digit separators - bool true, false I am not planning to use: - enum with specific types. - #elifdef - nullptr - auto - constexpr Not sure - empty initializer
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-05-22 22:11 +0200 |
| Message-ID | <v2lji1$1bbcp$1@dont-email.me> |
| In reply to | #384797 |
On 22/05/2024 19:42, Thiago Adams wrote: > On 22/05/2024 13:55, David Brown wrote: >> In an attempt to bring some topicality to the group, has anyone >> started using, or considering, C23 ? There's quite a lot of change in >> it, especially compared to the minor changes in C17. >> >> <https://open-std.org/JTC1/SC22/WG14/www/docs/n3220.pdf> >> <https://en.wikipedia.org/wiki/C23_(C_standard_revision)> >> <https://en.cppreference.com/w/c/23> >> >> I like that it tidies up a lot of old stuff - it is neater to have >> things like "bool", "static_assert", etc., as part of the language >> rather than needing a half-dozen includes for such basic stuff. >> >> I like that it standardises a several useful extensions that have been >> in gcc and clang (and possibly other compilers) for many years. >> >> I'm not sure it will make a big difference to my own programming - >> when I want "typeof" or "chk_add()", I already use them in gcc. But >> for people restricted to standard C, there's more new to enjoy. And I >> prefer to use standard syntax when possible. >> >> "constexpr" is something I think I will find helpful, in at least some >> circumstances. > > I am waiting MSVC support. There are a lot of simple features MSVC could > implement and deliver in small increments. But it is very slow. MSVC is primarily a C++ compiler - the C support is more of a leftover from the previous century, with a few post-C90 features as an afterthought. Surely for C development on Windows, rather than C++, you'd look for something better? > > I am would use today if I had. > > - #warning > - [[nodiscard]] > - typeof > - digit separators > - bool true, false > I use these today in C, except the digit separators (I use them in C++). But as I say, it's nice to see them as standard rather than just common extensions. > I am not planning to use: > > - enum with specific types. I haven't found a use for these in C++, and I'm not sure I'll need them in C either. I sometimes have ordinary enum types in bitfields for specific sizes. > - #elifdef The will slightly neaten some of my pre-processor handling. My strong preference for preprocessor symbols for conditional compilation and the like is to have symbols that are always defined, but to different values, and use "#if" checks rather than "#ifdef" - when combined with gcc warnings, it makes it far easier to catch spelling mistakes, and it makes it easy to jump in the code to where the symbol is defined. But #ifdef checks do turn up, and this will give marginally neater code. > - nullptr I am fond of nullptr in C++, and will use it in C. Like most of the C23 changes, it's not a big issue - after all, you get a lot of the same effect with "#define nullptr (void*)(0)" or similar. But it means your code has a visual distinction between the integer 0 and a null pointer, and also lets the compiler or other static checking system check better than using NULL would. (And I don't like NULL - I dislike all-caps identifiers in general.) > - auto I use that occasionally in gcc, as __auto_type. It can be helpful in macros. I might use it more when it is standardised. (I use auto in C++ a bit more often.) > - constexpr I will definitely use that. Sometimes I want a constant expression for things like array sizes or static initialisers, and want to calculate it. constexpr gives you that without having to resort to macros. (I'd perhaps be even happier if I could just use const, as I can in C++.) > > Not sure > - empty initializer > I don't see that one being a big hit, at least for me. But I see little benefit in /not/ allowing it in the language, so it seems a sensible addition.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2024-05-22 17:26 -0300 |
| Message-ID | <9be0c55c-38f8-496c-b335-84ad281e1753@gmail.com> |
| In reply to | #384830 |
On 22/05/2024 17:11, David Brown wrote:
> On 22/05/2024 19:42, Thiago Adams wrote:
>> On 22/05/2024 13:55, David Brown wrote:
>>> In an attempt to bring some topicality to the group, has anyone
>>> started using, or considering, C23 ? There's quite a lot of change
>>> in it, especially compared to the minor changes in C17.
>>>
>>> <https://open-std.org/JTC1/SC22/WG14/www/docs/n3220.pdf>
>>> <https://en.wikipedia.org/wiki/C23_(C_standard_revision)>
>>> <https://en.cppreference.com/w/c/23>
>>>
>>> I like that it tidies up a lot of old stuff - it is neater to have
>>> things like "bool", "static_assert", etc., as part of the language
>>> rather than needing a half-dozen includes for such basic stuff.
>>>
>>> I like that it standardises a several useful extensions that have
>>> been in gcc and clang (and possibly other compilers) for many years.
>>>
>>> I'm not sure it will make a big difference to my own programming -
>>> when I want "typeof" or "chk_add()", I already use them in gcc. But
>>> for people restricted to standard C, there's more new to enjoy. And
>>> I prefer to use standard syntax when possible.
>>>
>>> "constexpr" is something I think I will find helpful, in at least
>>> some circumstances.
>>
>> I am waiting MSVC support. There are a lot of simple features MSVC
>> could implement and deliver in small increments. But it is very slow.
>
> MSVC is primarily a C++ compiler - the C support is more of a leftover
> from the previous century, with a few post-C90 features as an
> afterthought. Surely for C development on Windows, rather than C++,
> you'd look for something better?
MSVC has support for C11 features like _Generic etc.. even threads.
I am used to MSVC. For some type of programs that needs resources or a
lot of windows api I think MSVC is a good choice.
>>
>> I am would use today if I had.
>>
>> - #warning
>> - [[nodiscard]]
>> - typeof
>> - digit separators
>> - bool true, false
>>
>
> I use these today in C, except the digit separators (I use them in C++).
> But as I say, it's nice to see them as standard rather than just
> common extensions.
>
>> I am not planning to use:
>>
>> - enum with specific types.
>
> I haven't found a use for these in C++, and I'm not sure I'll need them
> in C either. I sometimes have ordinary enum types in bitfields for
> specific sizes.
>
>> - #elifdef
>
> The will slightly neaten some of my pre-processor handling. My strong
> preference for preprocessor symbols for conditional compilation and the
> like is to have symbols that are always defined, but to different
> values, and use "#if" checks rather than "#ifdef" - when combined with
> gcc warnings, it makes it far easier to catch spelling mistakes, and it
> makes it easy to jump in the code to where the symbol is defined. But
> #ifdef checks do turn up, and this will give marginally neater code.
>
>> - nullptr
>
> I am fond of nullptr in C++, and will use it in C. Like most of the C23
> changes, it's not a big issue - after all, you get a lot of the same
> effect with "#define nullptr (void*)(0)" or similar. But it means your
> code has a visual distinction between the integer 0 and a null pointer,
> and also lets the compiler or other static checking system check better
> than using NULL would. (And I don't like NULL - I dislike all-caps
> identifiers in general.)
>
>> - auto
>
> I use that occasionally in gcc, as __auto_type. It can be helpful in
> macros. I might use it more when it is standardised. (I use auto in
> C++ a bit more often.)
>
>> - constexpr
>
> I will definitely use that. Sometimes I want a constant expression for
> things like array sizes or static initialisers, and want to calculate
> it. constexpr gives you that without having to resort to macros. (I'd
> perhaps be even happier if I could just use const, as I can in C++.)
I am curious for that. Do you have a sample?
>>
>> Not sure
>> - empty initializer
>>
>
> I don't see that one being a big hit, at least for me. But I see little
> benefit in /not/ allowing it in the language, so it seems a sensible
> addition.
This is what I use
struct X x = {0};
But I can do a find-replace and change everything to {}
When I create samples, I use new feature like nullptr and {}.
The problem I see is to use these features in real code, and create a
mess of styles.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-05-23 14:17 +0200 |
| Message-ID | <v2nc5h$1oban$1@dont-email.me> |
| In reply to | #384832 |
On 22/05/2024 22:26, Thiago Adams wrote:
> On 22/05/2024 17:11, David Brown wrote:
>> On 22/05/2024 19:42, Thiago Adams wrote:
>>> On 22/05/2024 13:55, David Brown wrote:
>>>> In an attempt to bring some topicality to the group, has anyone
>>>> started using, or considering, C23 ? There's quite a lot of change
>>>> in it, especially compared to the minor changes in C17.
>>>>
>>>> <https://open-std.org/JTC1/SC22/WG14/www/docs/n3220.pdf>
>>>> <https://en.wikipedia.org/wiki/C23_(C_standard_revision)>
>>>> <https://en.cppreference.com/w/c/23>
>>>>
>>
>>> - constexpr
>>
>> I will definitely use that. Sometimes I want a constant expression
>> for things like array sizes or static initialisers, and want to
>> calculate it. constexpr gives you that without having to resort to
>> macros. (I'd perhaps be even happier if I could just use const, as I
>> can in C++.)
>
> I am curious for that. Do you have a sample?
>
If I try to be precise about the terms "constant expression", "integer
constant expression", etc., I suspect I will get the details wrong
unless I spend a lot of time checking carefully. So I hope it is good
enough for me to be a bit lazy and quote the error messages from gcc
(with "-std=c23 -Wpedantic").
With this code, compilation fails "initialiser element is not a
constant" for y.
int x = 100;
int y = x / 20;
int zs[y];
With this code, compilation fails because the zs is actually a VLA, and
"variably modified 'zs' at file scope" is not allowed.
const int x = 100;
const int y = x / 20;
int zs[y];
This code, however, is fine:
constexpr int x = 100;
constexpr int y = x / 20;
int zs[y];
This also works, even for older standards:
enum { x = 100 };
enum { y = x / 20 };
int zs[y];
But constexpr works for other types, not just "int" which is the type of
all enumeration constants. (And "enum" constants are a somewhat weird
way to get this effect - "constexpr" looks neater.)
And in general, I like to be able to say, to the compiler and to people
reading the code, "this thing is really fixed and constant, and stop
compiling if you think I am wrong" rather than just "I promise I won't
change this thing - or if I do, I don't mind the nasal daemons".
>
>
>>>
>>> Not sure
>>> - empty initializer
>>>
>>
>> I don't see that one being a big hit, at least for me. But I see
>> little benefit in /not/ allowing it in the language, so it seems a
>> sensible addition.
>
> This is what I use
> struct X x = {0};
> But I can do a find-replace and change everything to {}
>
You could, but I don't really see the point of such a change. But in
new code it would be fine to write "= {}" rather than "= { 0 }".
> When I create samples, I use new feature like nullptr and {}.
> The problem I see is to use these features in real code, and create a
> mess of styles.
>
I think you need significant motivation to justify changing style in
existing code, and I don't see anything here that would make me want to
change existing C17 code to C23 code. But when writing new code, I'd
use the new features.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2024-05-23 09:38 -0300 |
| Message-ID | <c5866b5a-0314-4e70-af56-a86b63986b0c@gmail.com> |
| In reply to | #384861 |
On 23/05/2024 09:17, David Brown wrote:
> If I try to be precise about the terms "constant expression", "integer
> constant expression", etc., I suspect I will get the details wrong
> unless I spend a lot of time checking carefully. So I hope it is good
> enough for me to be a bit lazy and quote the error messages from gcc
> (with "-std=c23 -Wpedantic").
>
>
> With this code, compilation fails "initialiser element is not a
> constant" for y.
>
> int x = 100;
> int y = x / 20;
> int zs[y];
>
>
> With this code, compilation fails because the zs is actually a VLA, and
> "variably modified 'zs' at file scope" is not allowed.
>
> const int x = 100;
> const int y = x / 20;
> int zs[y];
>
>
> This code, however, is fine:
>
> constexpr int x = 100;
> constexpr int y = x / 20;
> int zs[y];
>
>
> This also works, even for older standards:
>
> enum { x = 100 };
> enum { y = x / 20 };
> int zs[y];
>
>
> But constexpr works for other types, not just "int" which is the type of
> all enumeration constants. (And "enum" constants are a somewhat weird
> way to get this effect - "constexpr" looks neater.)
>
> And in general, I like to be able to say, to the compiler and to people
> reading the code, "this thing is really fixed and constant, and stop
> compiling if you think I am wrong" rather than just "I promise I won't
> change this thing - or if I do, I don't mind the nasal daemons".
We can write:
#define X 100
#define Y ((X) / 20)
int zs[Y];
I cannot see a good justification for constexpr.
I already see bad usages of constexpr in C++ code. It was used in cases
where we know for sure that is NOT compile time. This just make review
harder "why did someone put this here?" conclusion was it was totally
unnecessary and ignored by the compiler. The programmer was trying to
add something extra, like "magic" hoping for something that would never
happen.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-05-23 17:08 +0000 |
| Message-ID | <TJK3O.68591$5dk1.3779@fx10.iad> |
| In reply to | #384877 |
Thiago Adams <thiago.adams@gmail.com> writes:
>On 23/05/2024 09:17, David Brown wrote:
>> If I try to be precise about the terms "constant expression", "integer
>> constant expression", etc., I suspect I will get the details wrong
>> unless I spend a lot of time checking carefully. So I hope it is good
>> enough for me to be a bit lazy and quote the error messages from gcc
>> (with "-std=c23 -Wpedantic").
>>
>>
>> With this code, compilation fails "initialiser element is not a
>> constant" for y.
>>
>> int x = 100;
>> int y = x / 20;
>> int zs[y];
>>
>>
>> With this code, compilation fails because the zs is actually a VLA, and
>> "variably modified 'zs' at file scope" is not allowed.
>>
>> const int x = 100;
>> const int y = x / 20;
>> int zs[y];
>>
>>
>> This code, however, is fine:
>>
>> constexpr int x = 100;
>> constexpr int y = x / 20;
>> int zs[y];
>>
>>
>> This also works, even for older standards:
>>
>> enum { x = 100 };
>> enum { y = x / 20 };
>> int zs[y];
>>
>>
>> But constexpr works for other types, not just "int" which is the type of
>> all enumeration constants. (And "enum" constants are a somewhat weird
>> way to get this effect - "constexpr" looks neater.)
>>
>> And in general, I like to be able to say, to the compiler and to people
>> reading the code, "this thing is really fixed and constant, and stop
>> compiling if you think I am wrong" rather than just "I promise I won't
>> change this thing - or if I do, I don't mind the nasal daemons".
>
>We can write:
>
>#define X 100
>#define Y ((X) / 20)
Neither of which convey type information.
>int zs[Y];
>
>I cannot see a good justification for constexpr.
Which does convey type information, and thus would
be superior to untyped macro definitions.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2024-05-23 16:06 -0300 |
| Message-ID | <7a312c82-3e91-4245-a132-9187385840c1@gmail.com> |
| In reply to | #384881 |
On 23/05/2024 14:08, Scott Lurndal wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
>> On 23/05/2024 09:17, David Brown wrote:
>>> If I try to be precise about the terms "constant expression", "integer
>>> constant expression", etc., I suspect I will get the details wrong
>>> unless I spend a lot of time checking carefully. So I hope it is good
>>> enough for me to be a bit lazy and quote the error messages from gcc
>>> (with "-std=c23 -Wpedantic").
>>>
>>>
>>> With this code, compilation fails "initialiser element is not a
>>> constant" for y.
>>>
>>> int x = 100;
>>> int y = x / 20;
>>> int zs[y];
>>>
>>>
>>> With this code, compilation fails because the zs is actually a VLA, and
>>> "variably modified 'zs' at file scope" is not allowed.
>>>
>>> const int x = 100;
>>> const int y = x / 20;
>>> int zs[y];
>>>
>>>
>>> This code, however, is fine:
>>>
>>> constexpr int x = 100;
>>> constexpr int y = x / 20;
>>> int zs[y];
>>>
>>>
>>> This also works, even for older standards:
>>>
>>> enum { x = 100 };
>>> enum { y = x / 20 };
>>> int zs[y];
>>>
>>>
>>> But constexpr works for other types, not just "int" which is the type of
>>> all enumeration constants. (And "enum" constants are a somewhat weird
>>> way to get this effect - "constexpr" looks neater.)
>>>
>>> And in general, I like to be able to say, to the compiler and to people
>>> reading the code, "this thing is really fixed and constant, and stop
>>> compiling if you think I am wrong" rather than just "I promise I won't
>>> change this thing - or if I do, I don't mind the nasal daemons".
>>
>> We can write:
>>
>> #define X 100
>> #define Y ((X) / 20)
>
> Neither of which convey type information.
>
>> int zs[Y];
>>
>> I cannot see a good justification for constexpr.
>
> Which does convey type information, and thus would
> be superior to untyped macro definitions.
>
If you want a type just but a cast or suffix if applicable.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-05-23 15:11 +0200 |
| Message-ID | <v2nfai$1ougd$1@dont-email.me> |
| In reply to | #384877 |
On 23/05/2024 14:38, Thiago Adams wrote:
> On 23/05/2024 09:17, David Brown wrote:
>> If I try to be precise about the terms "constant expression", "integer
>> constant expression", etc., I suspect I will get the details wrong
>> unless I spend a lot of time checking carefully. So I hope it is good
>> enough for me to be a bit lazy and quote the error messages from gcc
>> (with "-std=c23 -Wpedantic").
>>
>>
>> With this code, compilation fails "initialiser element is not a
>> constant" for y.
>>
>> int x = 100;
>> int y = x / 20;
>> int zs[y];
>>
>>
>> With this code, compilation fails because the zs is actually a VLA,
>> and "variably modified 'zs' at file scope" is not allowed.
>>
>> const int x = 100;
>> const int y = x / 20;
>> int zs[y];
>>
>>
>> This code, however, is fine:
>>
>> constexpr int x = 100;
>> constexpr int y = x / 20;
>> int zs[y];
>>
>>
>> This also works, even for older standards:
>>
>> enum { x = 100 };
>> enum { y = x / 20 };
>> int zs[y];
>>
>>
>> But constexpr works for other types, not just "int" which is the type
>> of all enumeration constants. (And "enum" constants are a somewhat
>> weird way to get this effect - "constexpr" looks neater.)
>>
>> And in general, I like to be able to say, to the compiler and to
>> people reading the code, "this thing is really fixed and constant, and
>> stop compiling if you think I am wrong" rather than just "I promise I
>> won't change this thing - or if I do, I don't mind the nasal daemons".
>
> We can write:
>
> #define X 100
> #define Y ((X) / 20)
> int zs[Y];
>
> I cannot see a good justification for constexpr.
Clearer code, better checking along the way, better typing. I don't
think constexpr lets you do things you couldn't do before, but it lets
you do those things in a neater way. (IMHO.)
> I already see bad usages of constexpr in C++ code. It was used in cases
> where we know for sure that is NOT compile time. This just make review
> harder "why did someone put this here?" conclusion was it was totally
> unnecessary and ignored by the compiler. The programmer was trying to
> add something extra, like "magic" hoping for something that would never
> happen.
>
IME poor or confusing uses of "constexpr" are for functions, not
objects, and C23 does not support "constexpr" for functions.
I think it is better to think of constexpr functions in C++ as "pure"
functions - confusingly called __attribute__((const)) functions in gcc
and [[unsequenced] functions in C23. That is, functions that don't
affect anything around them, are not affected by anything external, have
no side effects, always give the same results for the same parameters,
and can be called more or fewer times without affecting the program's
observable behaviour. (It's not exactly like that in C++ - a
"constexpr" function is implicitly inline and needs a local definition.
But I think that is how it could have been handled.)
The whole thing - in C and C++ - suffers somewhat from being addons over
time rather than part of the original design of the language. But
that's inevitable as an old language evolves.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2024-05-23 13:21 -0300 |
| Message-ID | <cf267279-e9cf-415f-898c-f5830a997529@gmail.com> |
| In reply to | #384888 |
On 23/05/2024 10:11, David Brown wrote:
> On 23/05/2024 14:38, Thiago Adams wrote:
>> On 23/05/2024 09:17, David Brown wrote:
>>> If I try to be precise about the terms "constant expression",
>>> "integer constant expression", etc., I suspect I will get the details
>>> wrong unless I spend a lot of time checking carefully. So I hope it
>>> is good enough for me to be a bit lazy and quote the error messages
>>> from gcc (with "-std=c23 -Wpedantic").
>>>
>>>
>>> With this code, compilation fails "initialiser element is not a
>>> constant" for y.
>>>
>>> int x = 100;
>>> int y = x / 20;
>>> int zs[y];
>>>
>>>
>>> With this code, compilation fails because the zs is actually a VLA,
>>> and "variably modified 'zs' at file scope" is not allowed.
>>>
>>> const int x = 100;
>>> const int y = x / 20;
>>> int zs[y];
>>>
>>>
>>> This code, however, is fine:
>>>
>>> constexpr int x = 100;
>>> constexpr int y = x / 20;
>>> int zs[y];
>>>
>>>
>>> This also works, even for older standards:
>>>
>>> enum { x = 100 };
>>> enum { y = x / 20 };
>>> int zs[y];
>>>
>>>
>>> But constexpr works for other types, not just "int" which is the type
>>> of all enumeration constants. (And "enum" constants are a somewhat
>>> weird way to get this effect - "constexpr" looks neater.)
>>>
>>> And in general, I like to be able to say, to the compiler and to
>>> people reading the code, "this thing is really fixed and constant,
>>> and stop compiling if you think I am wrong" rather than just "I
>>> promise I won't change this thing - or if I do, I don't mind the
>>> nasal daemons".
>>
>> We can write:
>>
>> #define X 100
>> #define Y ((X) / 20)
>> int zs[Y];
>>
>> I cannot see a good justification for constexpr.
>
> Clearer code, better checking along the way, better typing. I don't
> think constexpr lets you do things you couldn't do before, but it lets
> you do those things in a neater way. (IMHO.)
>
>> I already see bad usages of constexpr in C++ code. It was used in
>> cases where we know for sure that is NOT compile time. This just make
>> review harder "why did someone put this here?" conclusion was it was
>> totally unnecessary and ignored by the compiler. The programmer was
>> trying to add something extra, like "magic" hoping for something that
>> would never happen.
>>
>
> IME poor or confusing uses of "constexpr" are for functions, not
> objects, and C23 does not support "constexpr" for functions.
The sample C++ was something like
constexpr char * s[] = {"a", "b"};
for (int i = 0; i < sizeof(s); i++)
{
//using s[i]
}
I checked in C, it is an error.
error: 'constexpr' pointer initializer is not null
5 | constexpr char * s[] = {"a", "b"};
Then we were asking why constexpr was used in that case.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-05-23 14:49 -0700 |
| Message-ID | <87ed9s42sb.fsf@nosuchdomain.example.com> |
| In reply to | #384896 |
Thiago Adams <thiago.adams@gmail.com> writes:
> On 23/05/2024 10:11, David Brown wrote:
>> On 23/05/2024 14:38, Thiago Adams wrote:
[...]
>>> I already see bad usages of constexpr in C++ code. It was used in
>>> cases where we know for sure that is NOT compile time. This just
>>> make review harder "why did someone put this here?" conclusion was
>>> it was totally unnecessary and ignored by the compiler. The
>>> programmer was trying to add something extra, like "magic" hoping
>>> for something that would never happen.
>>>
>> IME poor or confusing uses of "constexpr" are for functions, not
>> objects, and C23 does not support "constexpr" for functions.
>
> The sample C++ was something like
>
> constexpr char * s[] = {"a", "b"};
> for (int i = 0; i < sizeof(s); i++)
> {
> //using s[i]
> }
>
> I checked in C, it is an error.
Apparently C23 has stricter rules for constexpr than C++ does. I can
imagine those rules being relaxed in future editions of the C standard.
> error: 'constexpr' pointer initializer is not null
> 5 | constexpr char * s[] = {"a", "b"};
>
>
> Then we were asking why constexpr was used in that case.
Why not?
When I compile that with g++ 14.1.0, with -std=c++23, I get:
warning: ISO C++ forbids converting a string constant to ‘char*’ [-Wwrite-strings]
When I replace "char*" by "const char*", that warning goes away.
The initializer *can* be evaluated at compile time. Using constexpr
catches any changes to the initializer that would require run-time code
execution.
Feel free to redirect to comp.lang.c++ if you want to discuss the C++
aspects further.
--
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-05-24 11:03 +0200 |
| Message-ID | <v2pl5g$28ola$1@dont-email.me> |
| In reply to | #384923 |
On 23/05/2024 23:49, Keith Thompson wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
>> On 23/05/2024 10:11, David Brown wrote:
>>> On 23/05/2024 14:38, Thiago Adams wrote:
> [...]
>>>> I already see bad usages of constexpr in C++ code. It was used in
>>>> cases where we know for sure that is NOT compile time. This just
>>>> make review harder "why did someone put this here?" conclusion was
>>>> it was totally unnecessary and ignored by the compiler. The
>>>> programmer was trying to add something extra, like "magic" hoping
>>>> for something that would never happen.
>>>>
>>> IME poor or confusing uses of "constexpr" are for functions, not
>>> objects, and C23 does not support "constexpr" for functions.
>>
>> The sample C++ was something like
>>
>> constexpr char * s[] = {"a", "b"};
>> for (int i = 0; i < sizeof(s); i++)
>> {
>> //using s[i]
>> }
>>
>> I checked in C, it is an error.
>
> Apparently C23 has stricter rules for constexpr than C++ does. I can
> imagine those rules being relaxed in future editions of the C standard.
>
From the proposal for "constexpr" in C23,
<https://open-std.org/JTC1/SC22/WG14/www/docs/n3018.htm>, it says:
"""
There are some restrictions on the type of an object that can be
declared with constexpr storage duration. There is a limited number of
constructs that are not allowed:
pointer types:
allowing these to use non-trivial addresses would delay the
deduction of the concrete value from translation to link-time. For most
of the use cases, such a feature can already be coded by using a static
and const qualified pointer object, we don’t need constexpr for that.
Therefore we only allow pointer types if the initializer value is null.
"""
I'm not sure (and haven't looked at all the discussions involved, so I
could be completely wrong), but I think there is concern that constexpr
pointers, other than null pointers, might need more features in the
linker than C currently requires. C++ already has more demands of
linkers to handle things like inline variables and statics in templates.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2024-05-24 14:17 -0300 |
| Message-ID | <f5774ff3-d2b0-4787-b16c-3b193dc418ef@gmail.com> |
| In reply to | #384923 |
On 23/05/2024 18:49, Keith Thompson wrote:
>> error: 'constexpr' pointer initializer is not null
>> 5 | constexpr char * s[] = {"a", "b"};
>>
>>
>> Then we were asking why constexpr was used in that case.
> Why not?
When I see a constexpr I ask if the compiler is able to compute
everything at compile time. If not immediately it is a bad usage in my view.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-05-24 12:45 -0700 |
| Message-ID | <87bk4v2du1.fsf@nosuchdomain.example.com> |
| In reply to | #385007 |
Thiago Adams <thiago.adams@gmail.com> writes:
> On 23/05/2024 18:49, Keith Thompson wrote:
>>> error: 'constexpr' pointer initializer is not null
>>> 5 | constexpr char * s[] = {"a", "b"};
>>>
>>>
>>> Then we were asking why constexpr was used in that case.
>> Why not?
>
> When I see a constexpr I ask if the compiler is able to compute
> everything at compile time. If not immediately it is a bad usage in my
> view.
I don't understand. Do you object because it's not *immediately
obvious* that everthing can be computed at compile time? If so, why
should it have to be?
If nothing else, the fact that the code compiles should be proof enough.
You said something upthread about the compiler ignoring constexpr if the
expression isn't compile-time evaluable; perhaps you were using a buggy
compiler?
Note that the above code is C++, not C, and that it should be "constexpr
const char *".
--
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 | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2024-05-24 17:06 -0300 |
| Message-ID | <ec20f752-6132-40f5-a4e8-f884746d2f3a@gmail.com> |
| In reply to | #385019 |
On 24/05/2024 16:45, Keith Thompson wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
>> On 23/05/2024 18:49, Keith Thompson wrote:
>>>> error: 'constexpr' pointer initializer is not null
>>>> 5 | constexpr char * s[] = {"a", "b"};
>>>>
>>>>
>>>> Then we were asking why constexpr was used in that case.
>>> Why not?
>>
>> When I see a constexpr I ask if the compiler is able to compute
>> everything at compile time. If not immediately it is a bad usage in my
>> view.
>
> I don't understand. Do you object because it's not *immediately
> obvious* that everthing can be computed at compile time? If so, why
> should it have to be?
My understanding is that constexpr is a tip for the compiler. Does not
ensure anything. Unless you use where constant expression is required.
So I don't like to see constexpr where I know it is not a constant
expression.
C++ has consteval (https://en.cppreference.com/w/cpp/language/consteval)
. When I first saw it I thought it was a joke.
"every potentially-evaluated call to the function must (directly or
indirectly) produce a compile time constant expression. "
Also constinit
https://en.cppreference.com/w/cpp/language/constinit
I never used these features I want never want to use. It is a total mess
in my opinion.
> If nothing else, the fact that the code compiles should be proof enough.
> You said something upthread about the compiler ignoring constexpr if the
> expression isn't compile-time evaluable; perhaps you were using a buggy
> compiler?
>
> Note that the above code is C++, not C, and that it should be "constexpr
> const char *".
>
I may have to implement constexpr in cake... So at some point I will see
all details.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-05-24 13:19 -0700 |
| Message-ID | <87v8330xq3.fsf@nosuchdomain.example.com> |
| In reply to | #385021 |
Thiago Adams <thiago.adams@gmail.com> writes:
> On 24/05/2024 16:45, Keith Thompson wrote:
>> Thiago Adams <thiago.adams@gmail.com> writes:
>>> On 23/05/2024 18:49, Keith Thompson wrote:
>>>>> error: 'constexpr' pointer initializer is not null
>>>>> 5 | constexpr char * s[] = {"a", "b"};
>>>>>
>>>>>
>>>>> Then we were asking why constexpr was used in that case.
>>>> Why not?
>>>
>>> When I see a constexpr I ask if the compiler is able to compute
>>> everything at compile time. If not immediately it is a bad usage in my
>>> view.
>> I don't understand. Do you object because it's not *immediately
>> obvious* that everthing can be computed at compile time? If so, why
>> should it have to be?
>
> My understanding is that constexpr is a tip for the compiler. Does not
> ensure anything. Unless you use where constant expression is required.
> So I don't like to see constexpr where I know it is not a constant
> expression.
Your understanding is incorrect. "constexpr" is not a mere hint.
In C23, an object defined with "constexpr" must be initialized with a
constant expression. C++ has similar rules. Attempting to initialize
it with a non-constant expression requires a diagnostic.
int non_const = 42;
constexpr int bad = non_const; // invalid, must be diagnosed
I'd be surprised to see a C or C++ compiler that failed to diagnose such
an error. Have you run into this, or are you speculating?
Given that the C++ code
constexpr const char * s[] = {"a", "b"}; // I added "const"
compiles successfully, you can safely assume that the initializer can be
and is evaluated at compile time.
> C++ has consteval
> (https://en.cppreference.com/w/cpp/language/consteval) . When I first
> saw it I thought it was a joke.
And I know just the newsgroup where it can be discussed.
[...]
--
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 | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2024-05-24 21:27 -0300 |
| Message-ID | <97c17a49-a940-42ff-83b8-df755fb6e88e@gmail.com> |
| In reply to | #385023 |
Em 5/24/2024 5:19 PM, Keith Thompson escreveu:
> Thiago Adams <thiago.adams@gmail.com> writes:
>> On 24/05/2024 16:45, Keith Thompson wrote:
>>> Thiago Adams <thiago.adams@gmail.com> writes:
>>>> On 23/05/2024 18:49, Keith Thompson wrote:
>>>>>> error: 'constexpr' pointer initializer is not null
>>>>>> 5 | constexpr char * s[] = {"a", "b"};
>>>>>>
>>>>>>
>>>>>> Then we were asking why constexpr was used in that case.
>>>>> Why not?
>>>>
>>>> When I see a constexpr I ask if the compiler is able to compute
>>>> everything at compile time. If not immediately it is a bad usage in my
>>>> view.
>>> I don't understand. Do you object because it's not *immediately
>>> obvious* that everthing can be computed at compile time? If so, why
>>> should it have to be?
>>
>> My understanding is that constexpr is a tip for the compiler. Does not
>> ensure anything. Unless you use where constant expression is required.
>> So I don't like to see constexpr where I know it is not a constant
>> expression.
>
> Your understanding is incorrect. "constexpr" is not a mere hint.
I think I can explain I little better
Let´s consider we have a compile time array of integers and a loop.
https://godbolt.org/z/e8cM1KGWT
#include <stdio.h>
#include <stdlib.h>
int main() {
constexpr int a[] = {1, 2, 3, 4, 5, 6, 7, 8};
for (int i = 0 ; i < sizeof(a)/sizeof(a[0]); i++)
{
printf("%d", a[i]);
}
}
What the programmer expected using a constant array in a loop?
The loop is in runtime, unless the compiler expanded the loop into 8
calls using constant expressions. But this is not the case.
This was the usage of constexpr I saw but with literal strings.
So, the array a is not used as constant even if it has constexpr.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-05-24 17:46 -0700 |
| Message-ID | <87r0dq1zxf.fsf@nosuchdomain.example.com> |
| In reply to | #385028 |
Thiago Adams <thiago.adams@gmail.com> writes:
> Em 5/24/2024 5:19 PM, Keith Thompson escreveu:
>> Thiago Adams <thiago.adams@gmail.com> writes:
>>> On 24/05/2024 16:45, Keith Thompson wrote:
>>>> Thiago Adams <thiago.adams@gmail.com> writes:
>>>>> On 23/05/2024 18:49, Keith Thompson wrote:
>>>>>>> error: 'constexpr' pointer initializer is not null
>>>>>>> 5 | constexpr char * s[] = {"a", "b"};
>>>>>>>
>>>>>>>
>>>>>>> Then we were asking why constexpr was used in that case.
>>>>>> Why not?
>>>>>
>>>>> When I see a constexpr I ask if the compiler is able to compute
>>>>> everything at compile time. If not immediately it is a bad usage in my
>>>>> view.
>>>> I don't understand. Do you object because it's not *immediately
>>>> obvious* that everthing can be computed at compile time? If so, why
>>>> should it have to be?
>>>
>>> My understanding is that constexpr is a tip for the compiler. Does not
>>> ensure anything. Unless you use where constant expression is required.
>>> So I don't like to see constexpr where I know it is not a constant
>>> expression.
>> Your understanding is incorrect. "constexpr" is not a mere hint.
> I think I can explain I little better
>
> Let´s consider we have a compile time array of integers and a loop.
>
> https://godbolt.org/z/e8cM1KGWT
>
> #include <stdio.h>
> #include <stdlib.h>
> int main() {
> constexpr int a[] = {1, 2, 3, 4, 5, 6, 7, 8};
> for (int i = 0 ; i < sizeof(a)/sizeof(a[0]); i++)
> {
> printf("%d", a[i]);
> }
> }
>
> What the programmer expected using a constant array in a loop?
> The loop is in runtime, unless the compiler expanded the loop into 8
> calls using constant expressions. But this is not the case.
> This was the usage of constexpr I saw but with literal strings.
> So, the array a is not used as constant even if it has constexpr.
What do you mean by "used as constant"?
The "constexpr" in the above asserts that the initializer for a consists
of constant expressions. Perhaps there's a reason that's desirable.
Perhaps the initial values come from `#embed`. a[3] is a constant
expression, as I understand it; a[i] is not.
The code that accesses `a` doesn't depend on the fact that it's constant
-- but the code still works, and the constexpr is harmless. Reading the
code, you can be certain that, assuming it compiles, the value is
determined at compile time. You don't necessarily have to make use of
that information. If you see
int n = 42;
you know that the value of 42 is determined at compile time, even if you
don't make use of that knowledge.
My preference is to mark declared objects as `const` (read-only)
unless there's a specific reason not to (I need to modify it).
Some more recent languages make the equivalent of `const` the
default, and require a qualifier to make an object modifiable.
I really like that (though adding that to C would be impractical).
I'm thinking that I'll probably have the same preference for
`constexpr`.
--
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 | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2024-05-25 08:33 -0300 |
| Message-ID | <b7704352-e11c-49b7-9fe5-3435e5f7e2bc@gmail.com> |
| In reply to | #385033 |
Em 5/24/2024 9:46 PM, Keith Thompson escreveu:
> Thiago Adams <thiago.adams@gmail.com> writes:
>> Em 5/24/2024 5:19 PM, Keith Thompson escreveu:
>>> Thiago Adams <thiago.adams@gmail.com> writes:
>>>> On 24/05/2024 16:45, Keith Thompson wrote:
>>>>> Thiago Adams <thiago.adams@gmail.com> writes:
>>>>>> On 23/05/2024 18:49, Keith Thompson wrote:
>>>>>>>> error: 'constexpr' pointer initializer is not null
>>>>>>>> 5 | constexpr char * s[] = {"a", "b"};
>>>>>>>>
>>>>>>>>
>>>>>>>> Then we were asking why constexpr was used in that case.
>>>>>>> Why not?
>>>>>>
>>>>>> When I see a constexpr I ask if the compiler is able to compute
>>>>>> everything at compile time. If not immediately it is a bad usage in my
>>>>>> view.
>>>>> I don't understand. Do you object because it's not *immediately
>>>>> obvious* that everthing can be computed at compile time? If so, why
>>>>> should it have to be?
>>>>
>>>> My understanding is that constexpr is a tip for the compiler. Does not
>>>> ensure anything. Unless you use where constant expression is required.
>>>> So I don't like to see constexpr where I know it is not a constant
>>>> expression.
>>> Your understanding is incorrect. "constexpr" is not a mere hint.
>> I think I can explain I little better
>>
>> Let´s consider we have a compile time array of integers and a loop.
>>
>> https://godbolt.org/z/e8cM1KGWT
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>> int main() {
>> constexpr int a[] = {1, 2, 3, 4, 5, 6, 7, 8};
>> for (int i = 0 ; i < sizeof(a)/sizeof(a[0]); i++)
>> {
>> printf("%d", a[i]);
>> }
>> }
>>
>> What the programmer expected using a constant array in a loop?
>> The loop is in runtime, unless the compiler expanded the loop into 8
>> calls using constant expressions. But this is not the case.
>> This was the usage of constexpr I saw but with literal strings.
>> So, the array a is not used as constant even if it has constexpr.
>
> What do you mean by "used as constant"?
>
Something used to produce a constant expression.
In the loop the compiler would have to get the value in runtime from
array, or unroll the loop.
I just checked, trying to extract an constant value from the array
https://godbolt.org/z/v33Pqd7W8
#include <stdio.h>
#include <stdlib.h>
int main() {
constexpr int a[] = {1, 2, 3, 4, 5, 6, 7, 8};
static_assert(a[0] ==1 );
}
I was expecting this to work!
But gcc says
<source>:5:24: error: expression in static assertion is not constant
5 | static_assert(a[0] ==1 );
|
The mess is even bigger than I thought.
In c++ it works
https://godbolt.org/z/qG6vGhEMj
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-05-25 16:51 +0200 |
| Message-ID | <v2stuf$2tphj$1@dont-email.me> |
| In reply to | #385053 |
On 25/05/2024 13:33, Thiago Adams wrote:
> Em 5/24/2024 9:46 PM, Keith Thompson escreveu:
>> Thiago Adams <thiago.adams@gmail.com> writes:
>>> Em 5/24/2024 5:19 PM, Keith Thompson escreveu:
>>>> Thiago Adams <thiago.adams@gmail.com> writes:
>>>>> On 24/05/2024 16:45, Keith Thompson wrote:
>>>>>> Thiago Adams <thiago.adams@gmail.com> writes:
>>>>>>> On 23/05/2024 18:49, Keith Thompson wrote:
>>>>>>>>> error: 'constexpr' pointer initializer is not null
>>>>>>>>> 5 | constexpr char * s[] = {"a", "b"};
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Then we were asking why constexpr was used in that case.
>>>>>>>> Why not?
>>>>>>>
>>>>>>> When I see a constexpr I ask if the compiler is able to compute
>>>>>>> everything at compile time. If not immediately it is a bad usage
>>>>>>> in my
>>>>>>> view.
>>>>>> I don't understand. Do you object because it's not *immediately
>>>>>> obvious* that everthing can be computed at compile time? If so, why
>>>>>> should it have to be?
>>>>>
>>>>> My understanding is that constexpr is a tip for the compiler. Does not
>>>>> ensure anything. Unless you use where constant expression is required.
>>>>> So I don't like to see constexpr where I know it is not a constant
>>>>> expression.
>>>> Your understanding is incorrect. "constexpr" is not a mere hint.
>>> I think I can explain I little better
>>>
>>> Let´s consider we have a compile time array of integers and a loop.
>>>
>>> https://godbolt.org/z/e8cM1KGWT
>>>
>>> #include <stdio.h>
>>> #include <stdlib.h>
>>> int main() {
>>> constexpr int a[] = {1, 2, 3, 4, 5, 6, 7, 8};
>>> for (int i = 0 ; i < sizeof(a)/sizeof(a[0]); i++)
>>> {
>>> printf("%d", a[i]);
>>> }
>>> }
>>>
>>> What the programmer expected using a constant array in a loop?
>>> The loop is in runtime, unless the compiler expanded the loop into 8
>>> calls using constant expressions. But this is not the case.
>>> This was the usage of constexpr I saw but with literal strings.
>>> So, the array a is not used as constant even if it has constexpr.
>>
>> What do you mean by "used as constant"?
>>
>
> Something used to produce a constant expression.
> In the loop the compiler would have to get the value in runtime from
> array, or unroll the loop.
>
> I just checked, trying to extract an constant value from the array
>
>
> https://godbolt.org/z/v33Pqd7W8
>
> #include <stdio.h>
> #include <stdlib.h>
> int main() {
> constexpr int a[] = {1, 2, 3, 4, 5, 6, 7, 8};
> static_assert(a[0] ==1 );
>
> }
>
> I was expecting this to work!
>
> But gcc says
>
> <source>:5:24: error: expression in static assertion is not constant
> 5 | static_assert(a[0] ==1 );
> |
>
That is disappointing. I too would have expected that to work in C23.
My guess is that it is the implicit pointer dereference that is the
problem. But I hope this is something that gets fixed shortly.
> The mess is even bigger than I thought.
>
> In c++ it works
> https://godbolt.org/z/qG6vGhEMj
>
>
[toc] | [prev] | [next] | [standalone]
Page 1 of 28 [1] 2 3 … 28 Next page →
Back to top | Article view | comp.lang.c
csiph-web