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 20 of 28 — ← Prev page 1 … 18 19 [20] 21 22 … 28 Next page →
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-05-23 03:13 +0000 |
| Message-ID | <v2mc9d$1iv52$1@dont-email.me> |
| In reply to | #384794 |
On Wed, 22 May 2024 18:55:36 +0200, David Brown wrote:
> <https://open-std.org/JTC1/SC22/WG14/www/docs/n3220.pdf>
Unicode identifiers!
typedef int
typėdef;
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-05-23 15:42 +0200 |
| Message-ID | <v2nh45$1p3o2$4@dont-email.me> |
| In reply to | #384855 |
On 23/05/2024 05:13, Lawrence D'Oliveiro wrote: > On Wed, 22 May 2024 18:55:36 +0200, David Brown wrote: > >> <https://open-std.org/JTC1/SC22/WG14/www/docs/n3220.pdf> > > Unicode identifiers! > > typedef int > typėdef; These have been around since C99... There are a couple of minor tweaks to the characters supported, I think, but nothing anyone is likely to notice in practice.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2024-05-23 14:35 -0400 |
| Subject | Re: C23 thoughts and opinions - why so conservative? |
| Message-ID | <v2o2ad$1sg5e$1@dont-email.me> |
| In reply to | #384794 |
On 5/23/24 10:19, Michael S wrote: ... > Another area that was mostly unchanged since 1st edition of K&R is > storage classes. Even such obvious thing as removal of 'auto' class > took too long. If I am not mistaken, totally obsolete 'register' class > is still allowed. And I don't remember any additions. constexpr and thread_local have both been added to the list of Storage-class specifiers since K&R.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-05-23 09:40 -0700 |
| Message-ID | <87a5kg5voc.fsf@nosuchdomain.example.com> |
| In reply to | #384794 |
Michael S <already5chosen@yahoo.com> writes:
[...]
> Removed
[...]
> 7) static_assert is not provided as a macro defined in <assert.h>
> (becomes a keyword)
> 8) thread_local is not provided as a macro defined in <threads.h>
> (becomes a keyword)
>
[...]
> 7) bad. Breaks existing code for weak reason
> 8) bad. Breaks existing code for weak reason
In pre-C23, _Static_assert and _Thread_local are keywords, and
static_assert and thread_local are macros that expand to those keywords.
In C23, _Static_assert, _Thread_local, static_assert, and thread_local
are all keywords. Code that simply uses the old ugly keywords would not
break.
Code that does something like "#ifdef static_assert". I suppose the
headers could have retained the old macro definitions.
#define static_assert static_assert
#define thread_local thread_local
--
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 17:10 +0200 |
| Message-ID | <v2qal7$2c8rq$3@dont-email.me> |
| In reply to | #384872 |
On 23/05/2024 18:40, Keith Thompson wrote:
> Michael S <already5chosen@yahoo.com> writes:
> [...]
>> Removed
> [...]
>> 7) static_assert is not provided as a macro defined in <assert.h>
>> (becomes a keyword)
>> 8) thread_local is not provided as a macro defined in <threads.h>
>> (becomes a keyword)
>>
> [...]
>> 7) bad. Breaks existing code for weak reason
>> 8) bad. Breaks existing code for weak reason
>
> In pre-C23, _Static_assert and _Thread_local are keywords, and
> static_assert and thread_local are macros that expand to those keywords.
>
> In C23, _Static_assert, _Thread_local, static_assert, and thread_local
> are all keywords. Code that simply uses the old ugly keywords would not
> break.
>
> Code that does something like "#ifdef static_assert". I suppose the
> headers could have retained the old macro definitions.
>
> #define static_assert static_assert
> #define thread_local thread_local
>
The sort of code that could theoretically break is when you have
definitions like this:
#define STATIC_ASSERT_NAME_(line) STATIC_ASSERT_NAME2_(line)
#define STATIC_ASSERT_NAME2_(line) assertion_failed_at_line_##line
#define static_assert(claim, warning) \
typedef struct { \
char STATIC_ASSERT_NAME_(__COUNTER__) [(claim) ? 2 : -2]; \
} STATIC_ASSERT_NAME_(__COUNTER__)
That works in any C version, until C23, almost as well as
_static_assert. I used this when C11 support was rare in the tools I used.
While using #define for a C keyword is undefined behaviour, in practice
I think you'd have a hard time finding code and a compiler that used
such a macro and which did not work just as well in C23 mode.
(I don't know if anyone is in the habit of declaring macros named
"thread_local".)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-05-24 12:29 -0700 |
| Message-ID | <87fru72elx.fsf@nosuchdomain.example.com> |
| In reply to | #384994 |
David Brown <david.brown@hesbynett.no> writes:
> On 23/05/2024 18:40, Keith Thompson wrote:
>> Michael S <already5chosen@yahoo.com> writes:
>> [...]
>>> Removed
>> [...]
>>> 7) static_assert is not provided as a macro defined in <assert.h>
>>> (becomes a keyword)
>>> 8) thread_local is not provided as a macro defined in <threads.h>
>>> (becomes a keyword)
>>>
>> [...]
>>> 7) bad. Breaks existing code for weak reason
>>> 8) bad. Breaks existing code for weak reason
>> In pre-C23, _Static_assert and _Thread_local are keywords, and
>> static_assert and thread_local are macros that expand to those keywords.
>> In C23, _Static_assert, _Thread_local, static_assert, and
>> thread_local
>> are all keywords. Code that simply uses the old ugly keywords would not
>> break.
>> Code that does something like "#ifdef static_assert". I suppose the
>> headers could have retained the old macro definitions.
>> #define static_assert static_assert
>> #define thread_local thread_local
>>
>
> The sort of code that could theoretically break is when you have
> definitions like this:
>
> #define STATIC_ASSERT_NAME_(line) STATIC_ASSERT_NAME2_(line)
> #define STATIC_ASSERT_NAME2_(line) assertion_failed_at_line_##line
> #define static_assert(claim, warning) \
> typedef struct { \
> char STATIC_ASSERT_NAME_(__COUNTER__) [(claim) ? 2 : -2]; \
> } STATIC_ASSERT_NAME_(__COUNTER__)
>
> That works in any C version, until C23, almost as well as
> _static_assert. I used this when C11 support was rare in the tools I
> used.
You mean _Static_assert.
> While using #define for a C keyword is undefined behaviour, in
> practice I think you'd have a hard time finding code and a compiler
> that used such a macro and which did not work just as well in C23
> mode.
>
> (I don't know if anyone is in the habit of declaring macros named
> "thread_local".)
"static_assert" is already a macro defined in <assert.h> starting in
C11. The above code is valid in pre-C23, but will break in C11 and C17
if it includes <assert.h> directly or indirectly. You can fix it by
adding "#undef static_assert" or by picking a different name, or by
making your macro definition conditional on __STDC_VERSION__ >= 202311L.
--
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-25 13:29 +0200 |
| Message-ID | <v2si1s$2rle2$4@dont-email.me> |
| In reply to | #385018 |
On 24/05/2024 21:29, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 23/05/2024 18:40, Keith Thompson wrote:
>>> Michael S <already5chosen@yahoo.com> writes:
>>> [...]
>>>> Removed
>>> [...]
>>>> 7) static_assert is not provided as a macro defined in <assert.h>
>>>> (becomes a keyword)
>>>> 8) thread_local is not provided as a macro defined in <threads.h>
>>>> (becomes a keyword)
>>>>
>>> [...]
>>>> 7) bad. Breaks existing code for weak reason
>>>> 8) bad. Breaks existing code for weak reason
>>> In pre-C23, _Static_assert and _Thread_local are keywords, and
>>> static_assert and thread_local are macros that expand to those keywords.
>>> In C23, _Static_assert, _Thread_local, static_assert, and
>>> thread_local
>>> are all keywords. Code that simply uses the old ugly keywords would not
>>> break.
>>> Code that does something like "#ifdef static_assert". I suppose the
>>> headers could have retained the old macro definitions.
>>> #define static_assert static_assert
>>> #define thread_local thread_local
>>>
>>
>> The sort of code that could theoretically break is when you have
>> definitions like this:
>>
>> #define STATIC_ASSERT_NAME_(line) STATIC_ASSERT_NAME2_(line)
>> #define STATIC_ASSERT_NAME2_(line) assertion_failed_at_line_##line
>> #define static_assert(claim, warning) \
>> typedef struct { \
>> char STATIC_ASSERT_NAME_(__COUNTER__) [(claim) ? 2 : -2]; \
>> } STATIC_ASSERT_NAME_(__COUNTER__)
>>
>> That works in any C version, until C23, almost as well as
>> _static_assert. I used this when C11 support was rare in the tools I
>> used.
>
> You mean _Static_assert.
I meant either "static_assert" or "_Static_assert", rather than a
mixture of the two! (I consider "static_assert" part of C11 even though
it needs a header.)
>
>> While using #define for a C keyword is undefined behaviour, in
>> practice I think you'd have a hard time finding code and a compiler
>> that used such a macro and which did not work just as well in C23
>> mode.
>>
>> (I don't know if anyone is in the habit of declaring macros named
>> "thread_local".)
>
> "static_assert" is already a macro defined in <assert.h> starting in
> C11. The above code is valid in pre-C23, but will break in C11 and C17
> if it includes <assert.h> directly or indirectly.
Yes. But including <assert.h> is optional.
> You can fix it by
> adding "#undef static_assert" or by picking a different name, or by
> making your macro definition conditional on __STDC_VERSION__ >= 202311L.
>
The actual code I use had a number of conditional checks for different C
standards and C++, so that it does not define a static_assert macro for
C++ (my C++ usage for the code was always at least C++11), and for C11
onwards it was defined to _Static_assert. (I specifically did not want
to include <assert.h>.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-05-25 16:21 -0700 |
| Message-ID | <87ed9p1nry.fsf@nosuchdomain.example.com> |
| In reply to | #385050 |
David Brown <david.brown@hesbynett.no> writes:
> On 24/05/2024 21:29, Keith Thompson wrote:
[...]
>> "static_assert" is already a macro defined in <assert.h> starting in
>> C11. The above code is valid in pre-C23, but will break in C11 and C17
>> if it includes <assert.h> directly or indirectly.
>
> Yes. But including <assert.h> is optional.
Your header that defines your own "static_assert" macro might depend on
some other header outside your control. A future version of that other
header might add a "#include <assert.h>", breaking your code.
There are solutions (check "#ifdef static_assert" for the macro and
__STDC_VERSION__ for the keyword, etc.)
Perhaps it's not an issue for you, but it's a corner case to keep in
mind.
--
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-26 16:15 +0200 |
| Message-ID | <v2vg6e$3eaba$1@dont-email.me> |
| In reply to | #385079 |
On 26/05/2024 01:21, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 24/05/2024 21:29, Keith Thompson wrote: > [...] >>> "static_assert" is already a macro defined in <assert.h> starting in >>> C11. The above code is valid in pre-C23, but will break in C11 and C17 >>> if it includes <assert.h> directly or indirectly. >> >> Yes. But including <assert.h> is optional. > > Your header that defines your own "static_assert" macro might depend on > some other header outside your control. A future version of that other > header might add a "#include <assert.h>", breaking your code. > I believe - but am not entirely sure - that the standard library headers are not allowed to include each other, precisely so that there will not be conflicts between user-defined identifiers and standard library identifiers from headers that you did not explicitly include. I appreciate what you are saying, and it can often make sense for other people. But in /my/ code, there is no possibility of future versions of headers having other includes. In my projects, I consider the entire toolchain to be part of the project, along with any other libraries or SDK's. Surprises like that don't happen when I am working on a project - nor when I take the same project out of archives and rebuild it 20 years later to get exactly the same binary, nor when anyone else does that. Reproducible builds are vital to my work. Of course, if I re-use the same code in a different project with different toolchains or libraries, such issues could crop up - but they are easily spotted and handled at the time. > There are solutions (check "#ifdef static_assert" for the macro and > __STDC_VERSION__ for the keyword, etc.) > Indeed. > Perhaps it's not an issue for you, but it's a corner case to keep in > mind. > It is not an issue for me, no - but I agree that it can be an issue for some people, and I agree it is worth keeping in mind. I am not suggesting that defining your own static_assert macro is a good idea for general use - I was merely saying that /I/ had used it as a temporary measure before C11 (and C++11) became practical for the majority of work I did, and that it could have compatibility issues when moving to C23.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-05-23 15:02 +0300 |
| Message-ID | <20240523150226.00007e7d@yahoo.com> |
| In reply to | #384794 |
On Wed, 22 May 2024 18:55:36 +0200
David Brown <david.brown@hesbynett.no> 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.
>
Removed
1) Old-style function declarations and definitions
2) Representations for signed integers other than two's complement
3) Permission that u/U-prefixed character constants and string
literals may be not UTF-16/32
4) Mixed wide string literal concatenation
5) Support for calling realloc() with zero size (the behavior becomes
undefined) 6) __alignof_is_defined and __alignas_is_defined
7) static_assert is not provided as a macro defined in <assert.h>
(becomes a keyword) 8) thread_local is not provided as a macro defined
in <threads.h> (becomes a keyword)
1) good
2) good, but insufficient. The next logical step is to make both left
and right shift of negative integers by count that does not exceed #
of bits in respective type fully defined
3) IDNC
4) IDNC
5) IDNC
6) IDNC
7) bad. Breaks existing code for weak reason
8) bad. Breaks existing code for weak reason
Deprecated
1) <stdnoreturn.h>
2) Old feature-test macros
__STDC_IEC_559__
__STDC_IEC_559_COMPLEX__
3) _Noreturn function specifier
4) _Noreturn attribute token
5) asctime()
6) ctime()
7) DECIMAL_DIG (use the appropriate type-specific macro
(FLT_DECIMAL_DIG, etc) instead)
8) Definition of following numeric limit macros in <math.h> (they
should be used via <float.h>)
INFINITY
DEC_INFINITY
NAN
DEC_NAN
9) __bool_true_false_are_defined
No opinion on most of those.
W.r.t. 5 and 6.
IMHO, all old-UNIX-style APIs that return pointers to static
objects within library or rely on presence of static object within
library for purpose of preserving state for subsequent calls should be
systematically deprecated and for majority of them there should be
provided thread-safe alternatives akin to ctime_s().
That is, with exception of family of functions that uses FILE*. Not
that I like them very much, but they are ingrained too deeply.
So, peeking just asctime and ctime out of long list of problematic
APIs does not appear particularly consistent. If they were asking me
where to start, I'd start with rand().
With regard to new feature, the list is too long to comment in one post.
Just want to say that strfrom* family is long overdue, but still appear
incomplete. The guiding principle should be that all format specifiers
available in printf() with sole exception of %s should be provided as
strfrom* as well.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-05-23 15:56 +0200 |
| Message-ID | <v2nhun$1pf0l$1@dont-email.me> |
| In reply to | #384875 |
On 23/05/2024 14:02, Michael S wrote: > On Wed, 22 May 2024 18:55:36 +0200 > David Brown <david.brown@hesbynett.no> 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. >> > > > Removed > 1) Old-style function declarations and definitions > 2) Representations for signed integers other than two's complement > 3) Permission that u/U-prefixed character constants and string > literals may be not UTF-16/32 > 4) Mixed wide string literal concatenation > 5) Support for calling realloc() with zero size (the behavior becomes > undefined) > 6) __alignof_is_defined and __alignas_is_defined > 7) static_assert is not provided as a macro defined in <assert.h> > (becomes a keyword) > 8) thread_local is not provided as a macro defined > in <threads.h> (becomes a keyword) > > 1) good Yes, at long last. > 2) good, but insufficient. The next logical step is to make both left > and right shift of negative integers by count that does not exceed # > of bits in respective type fully defined Agreed. > 3) IDNC > 4) IDNC > 5) IDNC > 6) IDNC > 7) bad. Breaks existing code for weak reason > 8) bad. Breaks existing code for weak reason > I am of the opinion that people should specify the standard they use as part of their build procedures. (I'd have liked a standard way to specify the C standard version code uses, so that it could be fixed in source code files.) I don't think people should take random code for Cxx and assume blindly that it will work for Cyy. Yes, these will break some code. But I don't think it will break much, and it will be nice to cut down on some of these headers. I have some very old code that defines static_assert as a macro involving typedefs with structs that can have positive or negative sizes, for C90 and C99. I don't expect to compiler these as C23 without testing - backwards compatibility is vital, but excessive backwards compatibility restricts improvements to the language. Still, it's a valid complaint. No change is going to please everyone!
[toc] | [prev] | [next] | [standalone]
| From | BGB-Alt <bohannonindustriesllc@gmail.com> |
|---|---|
| Date | 2024-05-23 17:15 -0500 |
| Message-ID | <v2of6i$1uvnr$1@dont-email.me> |
| In reply to | #384875 |
On 5/23/2024 7:02 AM, Michael S wrote: > On Wed, 22 May 2024 18:55:36 +0200 > David Brown <david.brown@hesbynett.no> 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. >> > > > Removed > 1) Old-style function declarations and definitions > 2) Representations for signed integers other than two's complement > 3) Permission that u/U-prefixed character constants and string > literals may be not UTF-16/32 > 4) Mixed wide string literal concatenation > 5) Support for calling realloc() with zero size (the behavior becomes > undefined) 6) __alignof_is_defined and __alignas_is_defined > 7) static_assert is not provided as a macro defined in <assert.h> > (becomes a keyword) 8) thread_local is not provided as a macro defined > in <threads.h> (becomes a keyword) > > 1) good I am mixed on 1, while I don't write any code using it, I am still using some code that uses them (and requiring, say, modifying the Dhrystone benchmark because it was using K&R style C, seems a bit weak). > 2) good, but insufficient. The next logical step is to make both left > and right shift of negative integers by count that does not exceed # > of bits in respective type fully defined Agreed. I might go further, but either way. Though, I have found that there is wonk in a few cases, like some code expecting that variable shifts are Mod N, while also expecting that constant shifts are non-modulo (and that negative shifts will shift in the opposite direction). Granted, better for code to *not* rely on the behavior of out-of-range or negative shifts, but alas... May not matter that much (IIRC, when porting code like this to GCC, it will give an error about the out-of-range shifts). Granted, in some ways GCC was less conservative. Though, the same program had also relied on the ability to use out-of-bounds access to global arrays to access things inside other global arrays (this broke in my initial porting attempt, as my compiler does not preserve the relative order or alignment of global variables; IOW: the C toplevel is not a struct...). > 3) IDNC > 4) IDNC > 5) IDNC > 6) IDNC > 7) bad. Breaks existing code for weak reason > 8) bad. Breaks existing code for weak reason Agreed, would probably keep them as #define's. One general thing of mine is, despite adding some amount of language extensions in my own compiler, not changing things that breaks existing code. > > Deprecated > 1) <stdnoreturn.h> > 2) Old feature-test macros > __STDC_IEC_559__ > __STDC_IEC_559_COMPLEX__ > 3) _Noreturn function specifier > 4) _Noreturn attribute token > 5) asctime() > 6) ctime() > 7) DECIMAL_DIG (use the appropriate type-specific macro > (FLT_DECIMAL_DIG, etc) instead) > 8) Definition of following numeric limit macros in <math.h> (they > should be used via <float.h>) > INFINITY > DEC_INFINITY > NAN > DEC_NAN > 9) __bool_true_false_are_defined > 3 and 4. Mixed, would mostly only effect library headers so probably OK. > No opinion on most of those. > W.r.t. 5 and 6. > IMHO, all old-UNIX-style APIs that return pointers to static > objects within library or rely on presence of static object within > library for purpose of preserving state for subsequent calls should be > systematically deprecated and for majority of them there should be > provided thread-safe alternatives akin to ctime_s(). > That is, with exception of family of functions that uses FILE*. Not > that I like them very much, but they are ingrained too deeply. > So, peeking just asctime and ctime out of long list of problematic > APIs does not appear particularly consistent. If they were asking me > where to start, I'd start with rand(). > I ended up turning "errno" into thread-local state in my implementation with no real ill effect. This mostly leaves the "locale" stuff as global state (in my case, the locale mostly effects whether to interpret some things as UTF-8 or 1252 / 8859-1, if it can't be figured out in other ways). > With regard to new feature, the list is too long to comment in one post. > Just want to say that strfrom* family is long overdue, but still appear > incomplete. The guiding principle should be that all format specifiers > available in printf() with sole exception of %s should be provided as > strfrom* as well. > Not much opinion here. > > > > > > > >
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-05-23 17:37 -0700 |
| Message-ID | <86msoghwoc.fsf@linuxsc.com> |
| In reply to | #384875 |
Michael S <already5chosen@yahoo.com> writes: [comments on various new features in C23] Overall I am quite disappointed by C23. IMO it's a step backwards rather than forwards. > W.r.t. [asctime() and ctime() being removed] > IMHO, all old-UNIX-style APIs that return pointers to static > objects within library or rely on presence of static object within > library for purpose of preserving state for subsequent calls > should be systematically deprecated and for majority of them there > should be provided thread-safe alternatives akin to ctime_s(). > > That is, with exception of family of functions that uses FILE*. > Not that I like them very much, but they are ingrained too deeply. > So, peeking just asctime and ctime out of long list of problematic > APIs does not appear particularly consistent. If they were asking > me where to start, I'd start with rand(). I agree with the suggestion that restartable versions of "dirty" functions be added to the C standard. I strongly disagree that the old ones should be taken out. If compilers choose to give warnings, that's fine, but these functions should not be removed just because some people think they are clunky. > [...] Just want to say that strfrom* family is long overdue, but > still appear incomplete. The guiding principle should be that all > format specifiers available in printf() with sole exception of %s > should be provided as strfrom* as well. What's the motivation for having separate functions? To me this looks like creeping featuritis.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-05-24 12:05 +0300 |
| Message-ID | <20240524120544.00000a7d@yahoo.com> |
| In reply to | #384946 |
On Thu, 23 May 2024 17:37:39 -0700 Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > Michael S <already5chosen@yahoo.com> writes: > > [comments on various new features in C23] > > Overall I am quite disappointed by C23. IMO it's a step > backwards rather than forwards. > > > W.r.t. [asctime() and ctime() being removed] > > IMHO, all old-UNIX-style APIs that return pointers to static > > objects within library or rely on presence of static object within > > library for purpose of preserving state for subsequent calls > > should be systematically deprecated and for majority of them there > > should be provided thread-safe alternatives akin to ctime_s(). > > > > That is, with exception of family of functions that uses FILE*. > > Not that I like them very much, but they are ingrained too deeply. > > So, peeking just asctime and ctime out of long list of problematic > > APIs does not appear particularly consistent. If they were asking > > me where to start, I'd start with rand(). > > I agree with the suggestion that restartable versions of "dirty" > functions be added to the C standard. I strongly disagree that > the old ones should be taken out. If compilers choose to give > warnings, that's fine, but these functions should not be removed > just because some people think they are clunky. > > > [...] Just want to say that strfrom* family is long overdue, but > > still appear incomplete. The guiding principle should be that all > > format specifiers available in printf() with sole exception of %s > > should be provided as strfrom* as well. > > What's the motivation for having separate functions? To me this > looks like creeping featuritis. My practical motivation is space-constrained environments, where I possibly want one or two or three formatters. sprintf() gives me all or nothing and all can be too expensive. Many embedded environments have big and small variants of sprintf that can be chosen at link time, but what's in small variant does not necessarily match a set that I want in my specific project. And is not necessarily well documented. My aesthetic motivation is a symmetry between strto* and strfrom*. My esoteric motivation is : sprintf() is historically associated with "standard I/O". Functionality in question has no relationship to I/O. But let's leave it aside, it's not important.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-05-24 06:54 -0700 |
| Message-ID | <86y17zgvs4.fsf@linuxsc.com> |
| In reply to | #384969 |
Michael S <already5chosen@yahoo.com> writes: > On Thu, 23 May 2024 17:37:39 -0700 > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> Michael S <already5chosen@yahoo.com> writes: >> >>> [...] Just want to say that strfrom* family is long overdue, but >>> still appear incomplete. The guiding principle should be that all >>> format specifiers available in printf() with sole exception of %s >>> should be provided as strfrom* as well. >> >> What's the motivation for having separate functions? To me this >> looks like creeping featuritis. > > My practical motivation is space-constrained environments, where I > possibly want one or two or three formatters. sprintf() gives me all > or nothing and all can be too expensive. Many embedded environments > have big and small variants of sprintf that can be chosen at link > time, but what's in small variant does not necessarily match a set > that I want in my specific project. And is not necessarily well > documented. Okay, I see now where you're coming from, although I'm not sure that the strfrom*() functions will give you what you want (in terms of memory footprint, etc). But I get your motivation. Question: which of the four formats (%A, %E, %F, %G) are ones you expect to use? Also I'm curious: do all of your target platforms use IEEE floating point, or do some use other representations?
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-05-24 18:46 +0300 |
| Message-ID | <20240524184623.00004e7f@yahoo.com> |
| In reply to | #384981 |
On Fri, 24 May 2024 06:54:35 -0700 Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > Michael S <already5chosen@yahoo.com> writes: > > > On Thu, 23 May 2024 17:37:39 -0700 > > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > > > >> Michael S <already5chosen@yahoo.com> writes: > >> > >>> [...] Just want to say that strfrom* family is long overdue, but > >>> still appear incomplete. The guiding principle should be that all > >>> format specifiers available in printf() with sole exception of %s > >>> should be provided as strfrom* as well. > >> > >> What's the motivation for having separate functions? To me this > >> looks like creeping featuritis. > > > > My practical motivation is space-constrained environments, where I > > possibly want one or two or three formatters. sprintf() gives me > > all or nothing and all can be too expensive. Many embedded > > environments have big and small variants of sprintf that can be > > chosen at link time, but what's in small variant does not > > necessarily match a set that I want in my specific project. And is > > not necessarily well documented. > > Okay, I see now where you're coming from, although I'm not sure that > the strfrom*() functions will give you what you want (in terms of > memory footprint, etc). But I get your motivation. > > Question: which of the four formats (%A, %E, %F, %G) are ones you > expect to use? Rarely: any of those, mostly for debugging. In productioon code: %e is most likely, but %f could happen. But it's not just a floating point. "Small" variants of sprintf() on 32-bit platforms often unable to handle %lld and %llu. > Also I'm curious: do all of your target platforms > use IEEE floating point, or do some use other representations? Currently, only IEEE. In the past, there were others, but that was quite a long tyme ago. Back, when after few years in other field I just started my pro programming carieer, I spend couple of years doing mostly TMS320C30. I don't remember for sure, but it is likely that I never used formatted FP output there; our boards were probably too short of memory for that.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-05-25 03:01 -0700 |
| Message-ID | <867cfigqho.fsf@linuxsc.com> |
| In reply to | #384995 |
Michael S <already5chosen@yahoo.com> writes: > On Fri, 24 May 2024 06:54:35 -0700 > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> Michael S <already5chosen@yahoo.com> writes: >> >>> On Thu, 23 May 2024 17:37:39 -0700 >>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> >>>> Michael S <already5chosen@yahoo.com> writes: >>>> >>>>> [...] Just want to say that strfrom* family is long overdue, but >>>>> still appear incomplete. The guiding principle should be that all >>>>> format specifiers available in printf() with sole exception of %s >>>>> should be provided as strfrom* as well. >>>> >>>> What's the motivation for having separate functions? To me this >>>> looks like creeping featuritis. >>> >>> My practical motivation is space-constrained environments, where I >>> possibly want one or two or three formatters. sprintf() gives me >>> all or nothing and all can be too expensive. Many embedded >>> environments have big and small variants of sprintf that can be >>> chosen at link time, but what's in small variant does not >>> necessarily match a set that I want in my specific project. And is >>> not necessarily well documented. >> >> Okay, I see now where you're coming from, although I'm not sure that >> the strfrom*() functions will give you what you want (in terms of >> memory footprint, etc). But I get your motivation. >> >> Question: which of the four formats (%A, %E, %F, %G) are ones you >> expect to use? > > Rarely: any of those, mostly for debugging. > In productioon code: %e is most likely, but %f could happen. If you can get by without %g, I recommend writing your own. The effort needed isn't trivial but it isn't impossibly large either. (If you really need %g that's a whole other kettle of fish... and really old smelly fish at that. :) > But it's not just a floating point. "Small" variants of sprintf() > on 32-bit platforms often unable to handle %lld and %llu. Here again, just write them. Easy as falling off a log. >> Also I'm curious: do all of your target platforms >> use IEEE floating point, or do some use other representations? > > Currently, only IEEE. [...] My comments above are predicated on being able to count on floating point being in IEEE format. Oh, if you want more information about this, please feel free to email me.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-05-23 17:19 +0300 |
| Subject | Re: C23 thoughts and opinions - why so conservative? |
| Message-ID | <20240523171911.00002f5a@yahoo.com> |
| In reply to | #384794 |
On Wed, 22 May 2024 18:55:36 +0200 David Brown <david.brown@hesbynett.no> 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. > Why C Standard Committee, while being recently quite liberal in field of introducing new keywords (too liberal for my liking, many new things do not really deserve keywords not prefixed by __) is so conservative in introduction of program control constructs? I don't remember any new program control introduced under Committee regime. And I want at least one. Another area that was mostly unchanged since 1st edition of K&R is storage classes. Even such obvious thing as removal of 'auto' class took too long. If I am not mistaken, totally obsolete 'register' class is still allowed. And I don't remember any additions. Personally I can think about at least two useful backward-compatible additions in that area.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-05-23 22:10 +0200 |
| Subject | Re: C23 thoughts and opinions - why so conservative? |
| Message-ID | <v2o7re$1tlge$1@dont-email.me> |
| In reply to | #384889 |
On 23/05/2024 16:19, Michael S wrote: > On Wed, 22 May 2024 18:55:36 +0200 > David Brown <david.brown@hesbynett.no> 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. >> > > Why C Standard Committee, while being recently quite liberal in field > of introducing new keywords (too liberal for my liking, many new things > do not really deserve keywords not prefixed by __) is so conservative > in introduction of program control constructs? I don't remember any > new program control introduced under Committee regime. > And I want at least one. > What program control construct would you like? > > Another area that was mostly unchanged since 1st edition of K&R is > storage classes. Even such obvious thing as removal of 'auto' class > took too long. If I am not mistaken, totally obsolete 'register' class > is still allowed. "register" is still in C23. (Some compilers pay attention to it. gcc with optimisation disabled puts local variables on the stack, except for those marked "register" that get put in registers.) It got dropped from C++ when "auto" was re-purposed in C++11, but with the keyword "register" kept for future use. I would not have objected to the same thing happening in C23. > And I don't remember any additions. _Thread_local was added in C11, with the alias thread_local in C23. What would you like to see here? > Personally I can think about at least two useful backward-compatible > additions in that area. >
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-05-24 00:34 +0300 |
| Subject | Re: C23 thoughts and opinions - why so conservative? |
| Message-ID | <20240524003424.0000590a@yahoo.com> |
| In reply to | #384914 |
On Thu, 23 May 2024 22:10:22 +0200 David Brown <david.brown@hesbynett.no> wrote: > On 23/05/2024 16:19, Michael S wrote: > > On Wed, 22 May 2024 18:55:36 +0200 > > David Brown <david.brown@hesbynett.no> 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. > >> > > > > Why C Standard Committee, while being recently quite liberal in > > field of introducing new keywords (too liberal for my liking, many > > new things do not really deserve keywords not prefixed by __) is so > > conservative in introduction of program control constructs? I don't > > remember any new program control introduced under Committee regime. > > And I want at least one. > > > > What program control construct would you like? > Ability to break from nested loops. Ability to"continue" outer loops would be nice too, but less important. I am not sure what syntax I want for this feature, never considered myself a competent language designer. > > > > > Another area that was mostly unchanged since 1st edition of K&R is > > storage classes. Even such obvious thing as removal of 'auto' class > > took too long. If I am not mistaken, totally obsolete 'register' > > class is still allowed. > > "register" is still in C23. (Some compilers pay attention to it. > gcc with optimisation disabled puts local variables on the stack, > except for those marked "register" that get put in registers.) It > got dropped from C++ when "auto" was re-purposed in C++11, but with > the keyword "register" kept for future use. I would not have > objected to the same thing happening in C23. > > > And I don't remember any additions. > > _Thread_local was added in C11, with the alias thread_local in C23. > _Thread_local is a special-purpose thing, probably not applicable at all for programming of small embedded systems, which nowadays is the only type of programming in C that I do for money rather than as hobby. With regard to constexpr, mentioned above by James Kuyper, my feeling about it is that it belongs to metaprogramming so I would not consider it a real storage class. > What would you like to see here? > Instead of solutions, let's talk about problems that I want to solve: 1. global objects, declared in header files and included several times. Where defined? For some linkers, mostly unixy linkers, in case of none-initialized objects (implicitly initialized to zero) it somehow works. For linkers used on embedded systems it requires additional effort. I think, for initialized globals it takes additional effort even with unixy linkers. I wnat it to "just work" everywhere. I think that the best way to get it without breaking existing semantics is a new storage class. 2. Reversing defaults for visibility of objects and functions at file scope. Something like: #pragma export_by_default(off). When this pragma is in effect, we need a way to make objects and functions globally visible. I think that it's done best with new storage class. > > Personally I can think about at least two useful backward-compatible > > additions in that area. > > > > >
[toc] | [prev] | [next] | [standalone]
Page 20 of 28 — ← Prev page 1 … 18 19 [20] 21 22 … 28 Next page →
Back to top | Article view | comp.lang.c
csiph-web