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 5 of 28 — ← Prev page 1 … 3 4 [5] 6 7 … 28 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-06-17 11:42 +0200 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <v4p0dv$jeb2$1@dont-email.me> |
| In reply to | #386042 |
On 17/06/2024 01:48, Keith Thompson wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> [...]
>> uc"..." string literals might be made even simpler, for example allowing
>> only hex digits and not requiring \x (uc"01020304" rather than
>> uc"\x01\x02\x03\x04"). That's probably overkill. uc"..." literals
>> could be useful in other contexts, and programmers will want
>> flexibility. Maybe something like hex"01020304" (embedded spaces could
>> be ignored) could be defined in addition to uc"\x01\x02\x03\x04".
> [...]
>
> *If* hexadecimal string literals were to be added to a future version
> of the language, I think I have a syntax that I like better than
> what I suggested.
>
I like your suggestion here. It's very similar to mine, though with a
prefix 0x"..." rather than b"...". I'd be fine with either.
> Inspired by the existing syntax for integer and floating-point
> hex constants, I propose using a "0x" prefix. 0x"deadbeef" is an
> expression of type `const unsigned char[4]` (assuming CHAR_BIT==8),
> with values 0xde, 0xad, 0xbe, 0xef in that order. Byte order is
> irrelevant; we're specifying byte values in order, not bytes of
> the representation of some larger type. memcpy()ing 0x"deadbeef"
> to a uint32 might yield either 0xdeadbeef or uxefbeadde (or other
> more exotic possibilities).
>
> Again, unlike other string literals, there is no implicit terminating
> null byte. And I suggest making them const, since there's no
> existing code to break.
>
> If CHAR_BIT==8, each byte is represented by two hex digits. More
> generally, each byte is represented by (CHAR_BIT+3)/4 hex digits in
> the absence of whitespace. Added whitespace marks the end of a byte,
> 0x"deadbeef" is 1, 2, 3, or 4 bytes if CHAR_BIT is 32, 16, 12, or 8
> respectively, but 0x"de ad be ef" is 4 bytes regardless of CHAR_BIT.
> 0x"" is a syntax error, since C doesn't support zero-length arrays.
> Anything between the quotes other than hex digits and spaces is a
> syntax error.
Fair enough.
>
> 0x"dead beef" is still 4 bytes if CHAR_BIT==8; the space forces the
> end of a byte, but the usage of spaces doesn't have to be consistent.
>
> This could be made more flexible by allowing various backslash
> escapes, but I'm not inclined to complicate it too much.
I would /definitely/ vote against any kind of backslash escapes here.
That would mess up the simplicity of the syntax.
There might be benefits in having standardised macros that generate
multiple copies of a given hex string and that sort of thing.
>
> Note that the value of a (proposed) hex string literal is not a
> string unless it happens to end in zero. I still use the term
> "string literal" because it's closely tied to existing string
> literal syntax, and existing string literals don't necessarily
> represent strings anyway ("embedded\0null\0characters").
>
> Binary string literals 0b"11001001" might also be worth
> considering (that's of type `const unsigned char[1]`).
That is /highly/ unlikely to be useful. I work in the field that uses
binary more than anywhere else, and where compilers have supported
0b11001001 format for binary literals from /long/ before they reached
the C standards - and I have very rarely seen them in practice. When
you do see them, they are in isolation - no one will write enough binary
values in a row for such a format to be useful. Hex strings are
potentially useful because you are cutting { 0x12, 0x34, 0x45, 0x67 } to
0x"12344567", which is a fair bit more compact. For binary, the
compaction is irrelevant and indeed counter-productive - binary literals
became a lot more practical with the introduction of digit separators.
(For standard C, these are from C23, but for C++ they came in C++14, and
compilers have supported them as extensions in C.)
> Octal
> string literals 0"012 345 670" *might* be worth considering.
Most situations where octal could be useful died out many decades ago -
it is vastly more likely that "012" is intended to mean 12 than 10. No
serious programming language supports a leading 0 as an indication of
octal unless they are forced to do so by backwards compatibility, and
many that used to support them have dropped them.
Having /some/ way to write octal can be helpful to old *nix programmers
who prefer 046 to "S_IRUSR | S_IWUSR | S_IRGRP" in their chmod calls.
(And to be fair, the constant names made in ancient history with short
identifier length limits are pretty ugly.) But it is not something to
be encouraged, and I think there is no simple syntax that is obviously
octal, and not easily mistaken for something else.
> <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3193.htm>
> proposes a new "0o123" syntax for octal constants; if that's adopted,
> I propose allowing 0o"..." and *not" 0"...". I'm not sure whether
> to suggest hex only, or doing hex, octal, and binary for the sake
> of completeness.
Binary support is useless, and octal support would be worse than useless
- even using an 0o rather than 0 prefix. Completeness is not a
justification for repeating old mistakes or complicating a good idea
with features that will never be used.
>
> What I'm trying to design here is a more straightforward way to
> represent raw (unsigned char[]) data in C code, largely but not
> exclusively for use by #embed.
>
Personally, I'd see it as useful when /not/ using #embed. I really do
not think programmers will care what format #embed uses. I don't share
your concerns about efficiency of implementation, or that programmers
need to know when it is efficient or not. In almost all circumstances,
C programmers never see or need to think about a separation between a C
preprocessor and a post-processed C compiler - they are seen as a single
entity, and can use whatever format is convenient between them. And
once you ignore the implementation details, which are an SEP, the way
#embed is defined is better than a definition using these new hex blob
strings.
But I have seen situations where it is useful to have embedded blobs
directly in the source file, and then a compact solution would be
convenient. Currently most people use a list of hex constants, either
byte for byte or sometimes in larger units, and hex strings like this
would make it neater and more convenient. (Attempts to use current
string literals for the purpose look more like corruption in the file
than source code.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-06-17 17:19 -0700 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <87cyof14rd.fsf@nosuchdomain.example.com> |
| In reply to | #386075 |
David Brown <david.brown@hesbynett.no> writes:
> On 17/06/2024 01:48, Keith Thompson wrote:
[...]
> For binary,
> the compaction is irrelevant and indeed counter-productive - binary
> literals became a lot more practical with the introduction of digit
> separators. (For standard C, these are from C23, but for C++ they came
> in C++14, and compilers have supported them as extensions in C.)
I forgot about digit separators.
C23 adds the option to use apostrophes as separators in numeric
constants: 123'456'789 or 0xdead'beef, for example. (This is
borrowed from C++. Commas are more commonly used in real life,
at least in my experience, but that wouldn't work given the other
meanings of commas.)
I briefly considered that, for consistency, we might want to
use apostrophes rather than spaces in hex string constants:
0x"de'ad'be'ef". But since digit separators are purely decorative,
and spaces in my proposed hex string literals are semantically
significant (they terminate a byte), I'll stick with spaces.
You could even write 0x"0 0 0 0" to denote 4 zero bytes (where
"0x0000" is 2 bytes) but 0x"00 00 00 00" or "0x00000000" is probably
clearer.
I think allowing both spaces and apostrophes would be too confusing.
>> Octal
>> string literals 0"012 345 670" *might* be worth considering.
>
> Most situations where octal could be useful died out many decades ago
> - it is vastly more likely that "012" is intended to mean 12 than 10.
> No serious programming language supports a leading 0 as an indication
> of octal unless they are forced to do so by backwards compatibility,
> and many that used to support them have dropped them.
>
> Having /some/ way to write octal can be helpful to old *nix
> programmers who prefer 046 to "S_IRUSR | S_IWUSR | S_IRGRP" in their
> chmod calls. (And to be fair, the constant names made in ancient
> history with short identifier length limits are pretty ugly.) But it
> is not something to be encouraged, and I think there is no simple
> syntax that is obviously octal, and not easily mistaken for something
> else.
There is, the proposed "0o" prefix. It's already supported in both Perl
and Python, and likely other languages.
>> <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3193.htm>
>> proposes a new "0o123" syntax for octal constants; if that's adopted,
>> I propose allowing 0o"..." and *not" 0"...". I'm not sure whether
>> to suggest hex only, or doing hex, octal, and binary for the sake
>> of completeness.
>
> Binary support is useless, and octal support would be worse than
> useless - even using an 0o rather than 0 prefix. Completeness is not
> a justification for repeating old mistakes or complicating a good idea
> with features that will never be used.
I like binary integer constants (0b11001001), but I suppose I
agree that they're not useful for larger chunks of data. I have no
problem supporting only hex string literals, not binary or octal --
but I'd have no problem with having all three if anyone thinks that
would be sufficiently useful.
>> What I'm trying to design here is a more straightforward way to
>> represent raw (unsigned char[]) data in C code, largely but not
>> exclusively for use by #embed.
>
> Personally, I'd see it as useful when /not/ using #embed. I really do
> not think programmers will care what format #embed uses. I don't
> share your concerns about efficiency of implementation, or that
> programmers need to know when it is efficient or not. In almost all
> circumstances, C programmers never see or need to think about a
> separation between a C preprocessor and a post-processed C compiler -
> they are seen as a single entity, and can use whatever format is
> convenient between them. And once you ignore the implementation
> details, which are an SEP, the way #embed is defined is better than a
> definition using these new hex blob strings.
I think my main problem with the current #embed is that it's
conceptually messy. I'm probably an outlier in how much I care about
that.
It's not clear whether the problems with the current definition of
#embed are as serious as I suggest; you clearly think they aren't. But
even if the current #embed is ok, I think adding hex string literals and
adding a language defined embed parameter that specifies using hex
string literals rather than a list of integer constant expressions would
be useful. Among other things, it lets the programmer specify that a
given #embed is only to be used to initialize an array of unsigned char.
For example, given a 4-byte foo.dat containing bytes 1, 2, 3, and 4:
const unsigned char buf[] = {
#embed "foo.dat"
};
would expand to something like:
const unsigned char buf[] = {
1, 2, 3, 4
};
(and the same if buf is of type int[] or double[]), while this:
const unsigned char buf[] =
#embed "foo.dat" hex(true) // proposed new parameter
;
would expand to something like:
const unsigned char buf[] =
0x"01020304"
;
(and would result in an error if buf is of type int[] or double[]).
[...]
--
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 | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-06-18 04:19 +0000 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <v4r1tf$166bb$2@dont-email.me> |
| In reply to | #386131 |
On Mon, 17 Jun 2024 17:19:50 -0700, Keith Thompson wrote: > C23 adds the option to use apostrophes as separators in numeric > constants: 123'456'789 or 0xdead'beef, for example. (This is borrowed > from C++. Why not underscores, as supported in both Ada and Python?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-06-17 22:39 -0700 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <87zfrizu56.fsf@nosuchdomain.example.com> |
| In reply to | #386135 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Mon, 17 Jun 2024 17:19:50 -0700, Keith Thompson wrote:
>> C23 adds the option to use apostrophes as separators in numeric
>> constants: 123'456'789 or 0xdead'beef, for example. (This is borrowed
>> from C++.
>
> Why not underscores, as supported in both Ada and Python?
And Perl, and probably other languages.
That would have been my preference, but C++ (starting in C++17)
and C (starting in C23) have already specified apostrophes. C++
uses underscores as part of the syntax for user-defined literals,
also introduced in C++17.
The apostrophe is the standard thousands separator in Switzerland.
I don't know how much that influenced the decision in C++.
--
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-06-18 15:54 +0200 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <v4s3i8$1cjdr$1@dont-email.me> |
| In reply to | #386131 |
On 18/06/2024 02:19, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 17/06/2024 01:48, Keith Thompson wrote:
> [...]
>> For binary,
>> the compaction is irrelevant and indeed counter-productive - binary
>> literals became a lot more practical with the introduction of digit
>> separators. (For standard C, these are from C23, but for C++ they came
>> in C++14, and compilers have supported them as extensions in C.)
>
> I forgot about digit separators.
>
> C23 adds the option to use apostrophes as separators in numeric
> constants: 123'456'789 or 0xdead'beef, for example. (This is
> borrowed from C++. Commas are more commonly used in real life,
> at least in my experience, but that wouldn't work given the other
> meanings of commas.)
Commas would be entirely unsuitable here, since half the world uses
decimal commas rather than decimal points. I think underscores are a
nicer choice, used by many languages, but C++ could not use underscores
due to their use in user-defined literals, and C followed C++.
>
> I briefly considered that, for consistency, we might want to
> use apostrophes rather than spaces in hex string constants:
> 0x"de'ad'be'ef". But since digit separators are purely decorative,
> and spaces in my proposed hex string literals are semantically
> significant (they terminate a byte), I'll stick with spaces.
I think you were using spaces as byte separators, whereas apostrophes
should be completely ignored when parsing.
>
> You could even write 0x"0 0 0 0" to denote 4 zero bytes (where
> "0x0000" is 2 bytes) but 0x"00 00 00 00" or "0x00000000" is probably
> clearer.
>
> I think allowing both spaces and apostrophes would be too confusing.
>
Fair enough.
>>> Octal
>>> string literals 0"012 345 670" *might* be worth considering.
>>
>> Most situations where octal could be useful died out many decades ago
>> - it is vastly more likely that "012" is intended to mean 12 than 10.
>> No serious programming language supports a leading 0 as an indication
>> of octal unless they are forced to do so by backwards compatibility,
>> and many that used to support them have dropped them.
>>
>> Having /some/ way to write octal can be helpful to old *nix
>> programmers who prefer 046 to "S_IRUSR | S_IWUSR | S_IRGRP" in their
>> chmod calls. (And to be fair, the constant names made in ancient
>> history with short identifier length limits are pretty ugly.) But it
>> is not something to be encouraged, and I think there is no simple
>> syntax that is obviously octal, and not easily mistaken for something
>> else.
>
> There is, the proposed "0o" prefix. It's already supported in both Perl
> and Python, and likely other languages.
Some languages apparently use 0q, because 0o might be confusing in some
fonts. I'm not sure I agree, and 0q is not very intuitive. I'd rate 0o
as vastly better than 0, but I would not bother with supporting it in a
new feature like this.
>
>>> <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3193.htm>
>>> proposes a new "0o123" syntax for octal constants; if that's adopted,
>>> I propose allowing 0o"..." and *not" 0"...". I'm not sure whether
>>> to suggest hex only, or doing hex, octal, and binary for the sake
>>> of completeness.
>>
>> Binary support is useless, and octal support would be worse than
>> useless - even using an 0o rather than 0 prefix. Completeness is not
>> a justification for repeating old mistakes or complicating a good idea
>> with features that will never be used.
>
> I like binary integer constants (0b11001001), but I suppose I
> agree that they're not useful for larger chunks of data.
Perhaps I am so used to binary and hex that I convert without thinking,
and thus rarely need binary.
The one place I find binary useful is for bitmap fonts. I use these a
lot less than I used to, but sometimes you need to make new characters
for an old-style low resolution LCD screen, and then binary constants
can be useful. Often, however, I prefer characters like . and @ rather
than 0 and 1 as it makes the contrast much higher.
> I have no
> problem supporting only hex string literals, not binary or octal --
> but I'd have no problem with having all three if anyone thinks that
> would be sufficiently useful.
>
Fair enough.
>>> What I'm trying to design here is a more straightforward way to
>>> represent raw (unsigned char[]) data in C code, largely but not
>>> exclusively for use by #embed.
>>
>> Personally, I'd see it as useful when /not/ using #embed. I really do
>> not think programmers will care what format #embed uses. I don't
>> share your concerns about efficiency of implementation, or that
>> programmers need to know when it is efficient or not. In almost all
>> circumstances, C programmers never see or need to think about a
>> separation between a C preprocessor and a post-processed C compiler -
>> they are seen as a single entity, and can use whatever format is
>> convenient between them. And once you ignore the implementation
>> details, which are an SEP, the way #embed is defined is better than a
>> definition using these new hex blob strings.
>
> I think my main problem with the current #embed is that it's
> conceptually messy. I'm probably an outlier in how much I care about
> that.
>
> It's not clear whether the problems with the current definition of
> #embed are as serious as I suggest; you clearly think they aren't.
I am still not convinced that there /are/ problems, never mind serious
problems, nor that it it is "conceptually messy". (I'd care about that
too, at least to some extent.) I don't think the feature will lead to
any dramatic changes in the way I work, but it could sometimes be
convenient and avoid the need of external scripts or programs in a build
file.
> But
> even if the current #embed is ok, I think adding hex string literals and
> adding a language defined embed parameter that specifies using hex
> string literals rather than a list of integer constant expressions would
> be useful.
Agreed.
> Among other things, it lets the programmer specify that a
> given #embed is only to be used to initialize an array of unsigned char.
>
> For example, given a 4-byte foo.dat containing bytes 1, 2, 3, and 4:
> const unsigned char buf[] = {
> #embed "foo.dat"
> };
> would expand to something like:
> const unsigned char buf[] = {
> 1, 2, 3, 4
> };
> (and the same if buf is of type int[] or double[]), while this:
> const unsigned char buf[] =
> #embed "foo.dat" hex(true) // proposed new parameter
> ;
> would expand to something like:
> const unsigned char buf[] =
> 0x"01020304"
> ;
> (and would result in an error if buf is of type int[] or double[]).
>
> [...]
>
I don't see the benefit here. This is C - the programmer is expected to
get the type right, and I think it would be rare to get it wrong (or
worse wrong than forgetting "unsigned") in a case like this. So the
extra type checking here has little or no benefit. (In general, I am a
fan of stronger type checking, but it is only important if it catches
real errors.)
The end result is completely identical to the user - adding "hex(true)"
makes no difference to the generated code. Thus it is just an
implementation detail which the user should not have to deal with.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-06-18 15:00 -0700 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <87frt9zzbm.fsf@nosuchdomain.example.com> |
| In reply to | #386172 |
David Brown <david.brown@hesbynett.no> writes:
> On 18/06/2024 02:19, Keith Thompson wrote:
[...]
>> I forgot about digit separators.
>> C23 adds the option to use apostrophes as separators in numeric
>> constants: 123'456'789 or 0xdead'beef, for example. (This is
>> borrowed from C++. Commas are more commonly used in real life,
>> at least in my experience, but that wouldn't work given the other
>> meanings of commas.)
>
> Commas would be entirely unsuitable here, since half the world uses
> decimal commas rather than decimal points. I think underscores are a
> nicer choice, used by many languages, but C++ could not use
> underscores due to their use in user-defined literals, and C followed
> C++.
C already uses '.' as the decimal point, though half the world uses ','.
That's already US-centric. ',' is unusable as a digit separator because
`123,456` already has any of several meanings, depending on the context.
If it weren't for that issue, I think that using ',' as a digit separator
would be no more problematic than using '.' as a decimal point. And C++
and C23 already use the apostrophe as a digit separator, which is likely
to be jarring to anyone outside Switzerland.
In any case, as discussed, I'm not proposing an ignorable digit
separator for hex string literals.
[...]
> I don't see the benefit here. This is C - the programmer is expected
> to get the type right, and I think it would be rare to get it wrong
> (or worse wrong than forgetting "unsigned") in a case like this. So
> the extra type checking here has little or no benefit. (In general, I
> am a fan of stronger type checking, but it is only important if it
> catches real errors.)
>
> The end result is completely identical to the user - adding
> "hex(true)" makes no difference to the generated code. Thus it is
> just an implementation detail which the user should not have to deal
> with.
The point isn't to change the generated code. The point is to let
programmers say more directly what they mean: "Treat the contents
of this file as an array of unsigned char", rather than the existing
"Treat the contents of this file as a sequence of comma-separated
integer constant expressions (which, by the way, I'm going to use
in an initializer for an array of unsigned char)".
(I don't think either of us is going to change our minds on the
esthetics. And yes, that sentence isn't entirely grammatically
correct.)
--
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-06-19 09:37 +0200 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <v4u1rg$1rslf$1@dont-email.me> |
| In reply to | #386202 |
On 19/06/2024 00:00, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 18/06/2024 02:19, Keith Thompson wrote: > [...] >>> I forgot about digit separators. >>> C23 adds the option to use apostrophes as separators in numeric >>> constants: 123'456'789 or 0xdead'beef, for example. (This is >>> borrowed from C++. Commas are more commonly used in real life, >>> at least in my experience, but that wouldn't work given the other >>> meanings of commas.) >> >> Commas would be entirely unsuitable here, since half the world uses >> decimal commas rather than decimal points. I think underscores are a >> nicer choice, used by many languages, but C++ could not use >> underscores due to their use in user-defined literals, and C followed >> C++. > > C already uses '.' as the decimal point, though half the world uses ','. Sure - a programming language has to pick /one/ such option. And since C was written by Americans, they got to choose. (I don't mind - we use a decimal point in the UK too.) However, if someone from one of several European countries sees "1,234" they will read it as 1.234, not 1234. This means using a comma as a separator would be a bad idea. Of course the current multiple uses of commas in C grammar mean that commas as digit separators are out of the question anyway. > That's already US-centric. ',' is unusable as a digit separator because > `123,456` already has any of several meanings, depending on the context. > If it weren't for that issue, I think that using ',' as a digit separator > would be no more problematic than using '.' as a decimal point. And C++ > and C23 already use the apostrophe as a digit separator, which is likely > to be jarring to anyone outside Switzerland. > Yes, but the apostrophe is equally jarring to almost everyone, and directly confusing to almost no one. It might have been better if C++ had used ' for user-defined literals (reminiscent of Ada attributes), and then left underscore for a digit separator, but that's all history now. > In any case, as discussed, I'm not proposing an ignorable digit > separator for hex string literals. > OK. Digit separators are useful for numbers you read and write manually, while these hex string literals are more likely to come from generated sources (such as copy-and-paste from a hexdump output). > [...] > >> I don't see the benefit here. This is C - the programmer is expected >> to get the type right, and I think it would be rare to get it wrong >> (or worse wrong than forgetting "unsigned") in a case like this. So >> the extra type checking here has little or no benefit. (In general, I >> am a fan of stronger type checking, but it is only important if it >> catches real errors.) >> >> The end result is completely identical to the user - adding >> "hex(true)" makes no difference to the generated code. Thus it is >> just an implementation detail which the user should not have to deal >> with. > > The point isn't to change the generated code. The point is to let > programmers say more directly what they mean: "Treat the contents > of this file as an array of unsigned char", rather than the existing > "Treat the contents of this file as a sequence of comma-separated > integer constant expressions (which, by the way, I'm going to use > in an initializer for an array of unsigned char)". > > (I don't think either of us is going to change our minds on the > esthetics. And yes, that sentence isn't entirely grammatically > correct.) > Fair enough.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2024-06-19 10:17 +0000 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <20240619025524.144@kylheku.com> |
| In reply to | #386222 |
On 2024-06-19, David Brown <david.brown@hesbynett.no> wrote: > On 19/06/2024 00:00, Keith Thompson wrote: >> David Brown <david.brown@hesbynett.no> writes: >>> On 18/06/2024 02:19, Keith Thompson wrote: >> [...] >>>> I forgot about digit separators. >>>> C23 adds the option to use apostrophes as separators in numeric >>>> constants: 123'456'789 or 0xdead'beef, for example. (This is >>>> borrowed from C++. Commas are more commonly used in real life, >>>> at least in my experience, but that wouldn't work given the other >>>> meanings of commas.) >>> >>> Commas would be entirely unsuitable here, since half the world uses >>> decimal commas rather than decimal points. I think underscores are a >>> nicer choice, used by many languages, but C++ could not use >>> underscores due to their use in user-defined literals, and C followed >>> C++. >> >> C already uses '.' as the decimal point, though half the world uses ','. > > Sure - a programming language has to pick /one/ such option. And since > C was written by Americans, they got to choose. (I don't mind - we use > a decimal point in the UK too.) However, if someone from one of several > European countries sees "1,234" they will read it as 1.234, not 1234. > This means using a comma as a separator would be a bad idea. That is what I chose to integrate in TXR Lisp: 1> (+ 1,234.56 2,000) 3234.56 That format lets me copy and paste figures from the outside world (e.g. financial or scientific reports or applications) and have them be understood. As you can see, commas are not used as separators between items; simple whitespace is. That helps to make this possible. The pic macro I developed also only outputs commas and decimal points. 1> (pic "#,###,###" 1) " 1" 2> (pic "0,###,###" 1) "0,000,001" 3> (pic "0,###,###.##" 1) "0,000,001.00" 4> (pic "0,###_###.##" 1) ** expr-1:1: pic: insufficient arguments for format 4> (pic "0,###_###.##" 1 2) "0,001_ 2.00" I don't care about conventions outside of North America. Computing is Amerian, basically. Almost any big co. you can think of, current or historic, was or is American. IBM, DEC, Sun Microsystems, Microsoft, Google, Apple, ... Everyone doing any programming in any mainstream programming language for which there are significant job postings has to begrudingly accept the period as the fraction separator, and English keywords and function names. (I suspect that one day the world will convert to a single standard for this, and it might not be far off.) -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-06-19 13:44 +0300 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <20240619134424.0000157e@yahoo.com> |
| In reply to | #386231 |
On Wed, 19 Jun 2024 10:17:45 -0000 (UTC) Kaz Kylheku <643-408-1753@kylheku.com> wrote: > > Computing is Amerian, basically. Almost any big co. you can think of, > current or historic, was or is American. IBM, DEC, Sun Microsystems, > Microsoft, Google, Apple, ... > Arguably, today's most influential CPU company is British, even if two of the 3 founders were American and current owner is from Japan. Today's most important silicon manufacturer, the one that keeps the progress crawling forward instead of standing still, is Taiwanese. And the company which made most of research that allowed to this manufacturer to make progress is based in Netherlands.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-06-19 11:57 +0100 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <v4udjn$1u270$2@dont-email.me> |
| In reply to | #386233 |
On 19/06/2024 11:44, Michael S wrote: > On Wed, 19 Jun 2024 10:17:45 -0000 (UTC) > Kaz Kylheku <643-408-1753@kylheku.com> wrote: > >> >> Computing is Amerian, basically. Almost any big co. you can think of, >> current or historic, was or is American. IBM, DEC, Sun Microsystems, >> Microsoft, Google, Apple, ... >> > > Arguably, today's most influential CPU company is British, even if two > of the 3 founders were American and current owner is from Japan. > Today's most important silicon manufacturer, the one that keeps the > progress crawling forward instead of standing still, is Taiwanese. > And the company which made most of research that allowed to this > manufacturer to make progress is based in Netherlands. > > And the language which seems dominant in North America, and within programming languages, and the basis for ASCII, is English. Which came from England, I guess!
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-06-19 13:46 +0000 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <WiBcO.22299$O5lc.7454@fx33.iad> |
| In reply to | #386233 |
Michael S <already5chosen@yahoo.com> writes: >On Wed, 19 Jun 2024 10:17:45 -0000 (UTC) >Kaz Kylheku <643-408-1753@kylheku.com> wrote: > >> >> Computing is Amerian, basically. Almost any big co. you can think of, >> current or historic, was or is American. IBM, DEC, Sun Microsystems, >> Microsoft, Google, Apple, ... >> > >Arguably, today's most influential CPU company is British, By what criteria? Yes, they ship a lot of CPUs, but architecturally, what have they influenced?
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-06-19 18:02 +0300 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <20240619180256.00004829@yahoo.com> |
| In reply to | #386239 |
On Wed, 19 Jun 2024 13:46:30 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > Michael S <already5chosen@yahoo.com> writes: > >On Wed, 19 Jun 2024 10:17:45 -0000 (UTC) > >Kaz Kylheku <643-408-1753@kylheku.com> wrote: > > > >> > >> Computing is Amerian, basically. Almost any big co. you can think > >> of, current or historic, was or is American. IBM, DEC, Sun > >> Microsystems, Microsoft, Google, Apple, ... > >> > > > >Arguably, today's most influential CPU company is British, > > By what criteria? Yes, they ship a lot of CPUs, but architecturally, > what have they influenced? > > They convinced everybody except UC Berkeley that development of new general-purpose instruction sets is futile.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-06-19 07:25 +0000 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <v4u14o$1rq9m$2@dont-email.me> |
| In reply to | #386172 |
On Tue, 18 Jun 2024 15:54:15 +0200, David Brown wrote: > ... C++ could not use underscores > due to their use in user-defined literals, and C followed C++. C can still offer the option for them, though.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-06-19 10:49 +0200 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <v4u62k$1sp1s$1@dont-email.me> |
| In reply to | #386221 |
On 19/06/2024 09:25, Lawrence D'Oliveiro wrote: > On Tue, 18 Jun 2024 15:54:15 +0200, David Brown wrote: > >> ... C++ could not use underscores >> due to their use in user-defined literals, and C followed C++. > > C can still offer the option for them, though. Sometimes it makes sense for C to do the same thing in a different way from C++ - but it is rare, and needs very strong justification.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-06-21 07:13 +0000 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <v5395s$3280j$1@dont-email.me> |
| In reply to | #386225 |
On Wed, 19 Jun 2024 10:49:24 +0200, David Brown wrote: > On 19/06/2024 09:25, Lawrence D'Oliveiro wrote: > >> On Tue, 18 Jun 2024 15:54:15 +0200, David Brown wrote: >> >>> ... C++ could not use underscores due to their use in user-defined >>> literals, and C followed C++. >> >> C can still offer the option for them, though. > > Sometimes it makes sense for C to do the same thing in a different way > from C++ - but it is rare, and needs very strong justification. The fact that it is something of a de-facto standard among other popular languages would count. Is C doomed to remain forever a strict subset of C++?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-06-21 13:06 +0200 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <v53mr6$34g49$3@dont-email.me> |
| In reply to | #386304 |
On 21/06/2024 09:13, Lawrence D'Oliveiro wrote: > On Wed, 19 Jun 2024 10:49:24 +0200, David Brown wrote: > >> On 19/06/2024 09:25, Lawrence D'Oliveiro wrote: >> >>> On Tue, 18 Jun 2024 15:54:15 +0200, David Brown wrote: >>> >>>> ... C++ could not use underscores due to their use in user-defined >>>> literals, and C followed C++. >>> >>> C can still offer the option for them, though. >> >> Sometimes it makes sense for C to do the same thing in a different way >> from C++ - but it is rare, and needs very strong justification. > > The fact that it is something of a de-facto standard among other popular > languages would count. > The apostrophe was already the standard - not just a "de-facto standard" - in the language that is most relevant for cooperation with C. > Is C doomed to remain forever a strict subset of C++? C is not a subset of C++. Their intersection covers most of C, but not all of it. But C and C++ are often used together and compiled together in the same binaries. A large proportion of C and C++ programmers work with both languages, while almost none of them have any use for, say, Ada with its underscore digit separator. It makes sense when introducing new features to either language to be compatible with the other (if the feature is relevant to both languages). C thus copies from C++, and C++ copies from C. Sometimes there must be differences, but gratuitous differences are bad for everyone, even if they might seem a little nicer in one language in isolation.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-06-21 22:48 +0000 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <v54vv7$3cg00$2@dont-email.me> |
| In reply to | #386311 |
On Fri, 21 Jun 2024 13:06:14 +0200, David Brown wrote: > - in the language that is most relevant for cooperation with C. Not sure why C++ is relevant to C at all, since C++ does pretty much everything that C does (if a bit differently) and more, which renders C essentially obsolete in that scenario. Where the usage of C would be more relevant is as an implementation language for CPU-intensive “engine” code meant to be callable from higher- level languages. For example, extension modules for Python. Being able to interoperate with such languages would be more of a benefit.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-06-22 13:40 +0200 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <v56d6h$3o2to$1@dont-email.me> |
| In reply to | #386336 |
On 22/06/2024 00:48, Lawrence D'Oliveiro wrote: > On Fri, 21 Jun 2024 13:06:14 +0200, David Brown wrote: > >> - in the language that is most relevant for cooperation with C. > > Not sure why C++ is relevant to C at all, since C++ does pretty much > everything that C does (if a bit differently) and more, which renders C > essentially obsolete in that scenario. > Have you actually worked with any C++ programs? Have you ever included a C header in your C++ code? Fortunately, the C and C++ standards committees both know more about the importance of consistency than you do. > Where the usage of C would be more relevant is as an implementation > language for CPU-intensive “engine” code meant to be callable from higher- > level languages. For example, extension modules for Python. Being able to > interoperate with such languages would be more of a benefit. I wonder why nobody ever thought of that before you suggested it!
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2024-06-21 10:15 -0400 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <v541un$36rmj$1@dont-email.me> |
| In reply to | #386304 |
On 6/21/24 03:13, Lawrence D'Oliveiro wrote: > On Wed, 19 Jun 2024 10:49:24 +0200, David Brown wrote: ... >> Sometimes it makes sense for C to do the same thing in a different way >> from C++ - but it is rare, and needs very strong justification. > > The fact that it is something of a de-facto standard among other popular > languages would count. > > Is C doomed to remain forever a strict subset of C++? C is not now, nor has it ever been, a strict subset of C++, so it seems unlikely that it is doomed to become one. C++ was initially intended to be an extension to C, and a desire to maintain backwards compatibility with C played a role in many of the design decisions for C++. Nowadays, the C committee and C++ committee have agreed to a policy of avoiding incompatibilities with each other. That doesn't mean that there should be no incompatibilities, only that they need to be strongly motivated.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-06-19 02:32 -0700 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <87h6dpxopd.fsf@nosuchdomain.example.com> |
| In reply to | #386221 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Tue, 18 Jun 2024 15:54:15 +0200, David Brown wrote:
>> ... C++ could not use underscores
>> due to their use in user-defined literals, and C followed C++.
>
> C can still offer the option for them, though.
As of the new C23 standard (not yet officially published) C *already*
uses apostrophes as digit separators. I would have preferred
underscores to apostrophes myself, but allowing both would be worse.
And C might want to introduce something similar to C++'s user-defined
literals some day.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
Page 5 of 28 — ← Prev page 1 … 3 4 [5] 6 7 … 28 Next page →
Back to top | Article view | comp.lang.c
csiph-web