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 6 of 28 — ← Prev page 1 … 4 5 [6] 7 8 … 28 Next page →
| 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 | <v4r1s7$166bb$1@dont-email.me> |
| In reply to | #386075 |
On Mon, 17 Jun 2024 11:42:22 +0200, David Brown wrote: > 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. For one example, Python didn’t drop octal numbers in the 2→3 transition, but it changed the syntax from a simple “0” prefix to having a “0o” prefix (analogous to “0x” for hex literals) instead.
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <invalid@invalid.invalid> |
|---|---|
| Date | 2024-06-17 11:41 +0100 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <wwva5jj4zsw.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #386042 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> 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).
I like the syntax and I’d find it useful.
There’s more to life than byte arrays, though, so I wonder if there’s
more to be said here. I find myself dealing a lot with large integers
generally represented as arrays of some unsigned type (commonly uint32_t
but other possibilities arise too).
In C as it stands today this requires a translation step before
constants can be embedded in source code (which is error-prone if
someone attempts to do it manually).
So being able to say ‘0x8732456872648956348596893765836543 as array of
uint64_t, LSW first’ (in some suitably C-like syntax) would be a big
improvement from my perspective, primarily as an accelerator to
development but also as a small improvement in robustness.
> 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.
Would "0x1 23 45 67" be a syntax error or { 0x1, 0x23, 0x45, 0x67 }?
> 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.
Compilers can already implement #embed however they like, there’s no
need for a standardized way to represent the ‘inside’ of a #embed.
--
https://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <invalid@invalid.invalid> |
|---|---|
| Date | 2024-06-17 14:57 +0100 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <wwvo77z6599.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #386080 |
Richard Kettlewell <invalid@invalid.invalid> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> 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.
>
> Would "0x1 23 45 67" be a syntax error or { 0x1, 0x23, 0x45, 0x67 }?
FTAOD I mean
0x"1 23 45 67"
--
https://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-06-17 18:57 -0700 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <878qz31096.fsf@nosuchdomain.example.com> |
| In reply to | #386080 |
Richard Kettlewell <invalid@invalid.invalid> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> 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).
>
> I like the syntax and I’d find it useful.
>
> There’s more to life than byte arrays, though, so I wonder if there’s
> more to be said here. I find myself dealing a lot with large integers
> generally represented as arrays of some unsigned type (commonly uint32_t
> but other possibilities arise too).
>
> In C as it stands today this requires a translation step before
> constants can be embedded in source code (which is error-prone if
> someone attempts to do it manually).
>
> So being able to say ‘0x8732456872648956348596893765836543 as array of
> uint64_t, LSW first’ (in some suitably C-like syntax) would be a big
> improvement from my perspective, primarily as an accelerator to
> development but also as a small improvement in robustness.
You could use some kind of type punning. For example, this is currently
legal:
union {
unsigned char buf[4];
uint32_t n;
} obj = {
.buf = { 0x01, 0x02, 0x03, 0x04 }
};
The { 0x01, 0x02, 0x03, 0x04 } could be replaced with 0x"01020304".
Of course you have to deal with endianness.
Since C defines representation in terms of arrays of unsigned char, I'm
inclined to stick to just that. If there's a *clean* way to extend it
to wider types, I'm ok with that (and I'm not the one who needs to be
convinced).
>> 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.
>
> Would "0x1 23 45 67" be a syntax error or { 0x1, 0x23, 0x45, 0x67 }?
The latter.
As you acknowledge in a followup, the 0x goes outside the quotation
marks.
The end of a byte is indicated either by having the right number of
hex digits (2 if CHAR_BIT==8, more otherwise) or by a space character.
0x"1 23 45 67" would be equivalent to 0x"01 23 45 67", or to "0x01234567"
if CHAR_BIT==8.
>> 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.
>
> Compilers can already implement #embed however they like, there’s no
> need for a standardized way to represent the ‘inside’ of a #embed.
The (draft) standard already specifies what #embed expands to,
a comma-delimited sequence of integer constant expressions.
Compilers must implement it in a way that yields the same behavior,
including in contrived cases like the struct example I posted before.
A compiler might implement it in a more optimal manner if it knows
that the target object is an array of unsigned char.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-06-18 08:12 +0000 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <v4rfgv$18eq9$5@dont-email.me> |
| In reply to | #386132 |
On Mon, 17 Jun 2024 18:57:09 -0700, Keith Thompson wrote:
> You could use some kind of type punning. For example, this is currently
> legal:
>
> union {
> unsigned char buf[4];
> uint32_t n;
> } obj = {
> .buf = { 0x01, 0x02, 0x03, 0x04 }
> };
>
> The { 0x01, 0x02, 0x03, 0x04 } could be replaced with 0x"01020304".
In Open Source, the definition of “source” is (to the effect of) “the
preferred representation of the program for doing development with”.
The implication to me is, if the C source form has to be cryptic and
error-prone and basically hard to work with, then I would back up one step
and use some other form for that part of the source, that would be
translated to C source as part of the build process and linked against the
rest of the code. The generated C source would not be part of the repo
commit history, but the input used to generate it (along with any custom
build tool setup/programming) would.
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <invalid@invalid.invalid> |
|---|---|
| Date | 2024-06-18 16:14 +0100 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <wwvzfris2ox.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #386132 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Richard Kettlewell <invalid@invalid.invalid> writes:
>> There’s more to life than byte arrays, though, so I wonder if there’s
>> more to be said here. I find myself dealing a lot with large integers
>> generally represented as arrays of some unsigned type (commonly uint32_t
>> but other possibilities arise too).
>>
>> In C as it stands today this requires a translation step before
>> constants can be embedded in source code (which is error-prone if
>> someone attempts to do it manually).
>>
>> So being able to say ‘0x8732456872648956348596893765836543 as array of
>> uint64_t, LSW first’ (in some suitably C-like syntax) would be a big
>> improvement from my perspective, primarily as an accelerator to
>> development but also as a small improvement in robustness.
>
> You could use some kind of type punning. For example, this is currently
> legal:
>
> union {
> unsigned char buf[4];
> uint32_t n;
> } obj = {
> .buf = { 0x01, 0x02, 0x03, 0x04 }
> };
I can’t use type punning if the data type is already set, which it often
is.
> The { 0x01, 0x02, 0x03, 0x04 } could be replaced with 0x"01020304".
>
> Of course you have to deal with endianness.
That’s a fatal problem for my use case.
--
https://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-06-17 14:21 +0100 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <v4pd8t$m52o$1@dont-email.me> |
| In reply to | #386042 |
On 17/06/2024 00: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.
>
> 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).
Some points:
* Can the hex string span multiple lines? (You say space is the only
white-space allowed)
* If not, would adjacent hex strings be concatenated, as happens with
ordinary strings? Since hex data for one char array can be large.
* Your examples use only digits a-f but I assume A-F will work too.
* Can individual byte values end early, so allowing B to mean 0B? (My
scheme requires hex digits to be in pairs.)
> 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.
>
> 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.
Here it gets confusing. But first, I understand that CHAR_BIT could be
64, where hex literals get long enough that they could do with
separators. But spaces now are significant in marking the early end of a
64-bit value.
What I have in mind is that somebody might write 0x"12 34 56 78" to
designate 4 8-bit values totalling 32 bits, and wants the spaces for
readability. Compiled for a machine with 16-bit characters, it will now
represent (in little-endian) the 64-bit value 0x0078005600340012 instead
of 0x78563412.
I assume the hex string can only be used to initialise a char[] array?
(The feature I presented elsewhere, 'data-strings', could be used to
initialise any array type, just like #embed IIUC.)
>
> This could be made more flexible by allowing various backslash
> escapes, but I'm not inclined to complicate it too much.
>
> 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]`).
You mean, values that can only be one byte long? I don't get it. How
many use-cases are there for char-arrays that are only a byte long?
Assuming that [1] was a typo for [], then I still have trouble finding
uses for this.
Perhaps initialise a char[][] table representing a one-bit-per-pixel
image? Bit-order becomes critical here.
Here, C already has 64-bit binary literals, using those might be a
better idea, since a char[][] is the wrong type anyway, unless you can
have bool[][] which is guaranteed to use 1-bit bools.
> Octal
> string literals 0"012 345 670" *might* be worth considering.
AFAIK nobody uses octal anymore.
> 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.
Sorry, I thought this was an alternative to #embed, for smaller amounts
of data directly written in source code.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-06-17 19:20 -0700 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <874j9r0z6s.fsf@nosuchdomain.example.com> |
| In reply to | #386089 |
bart <bc@freeuk.com> writes:
> On 17/06/2024 00: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.
>> 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).
>
> Some points:
>
> * Can the hex string span multiple lines? (You say space is the only
> white-space allowed)
No.
> * If not, would adjacent hex strings be concatenated, as happens with
> ordinary strings? Since hex data for one char array can be large.
Yes (ordinary string literals, not strings). C23 says, "If a sequence
of adjacent string literal tokens includes prefixed string literal
tokens, the prefixed tokens shall all have the same prefix.", so you
can't concatenate hex string literals with ordinary string literals.
A use case I have in mind is having #embed, perhaps with a new
parameter, expand to a sequence of one or more hex string literals.
I'd expect
#embed "big_file.dat" hex(true)
to expand to something like:
0x"29db6210971cc5bafc17292cb047c143db305eabbee23a4d6ccd63eee37344cc"
0x"735a83327d056b87d167ecd8626f0059556735a66b7a1761d8ffe94ff5b1dc38"
...
> * Your examples use only digits a-f but I assume A-F will work too.
Certainly, and the prefix can be either 0x or 0X, as for hex numeric
constants.
> * Can individual byte values end early, so allowing B to mean 0B? (My
> scheme requires hex digits to be in pairs.)
Yes, the end of a byte is indicated either by having enough hex digits
(2 if CHAR_BIT==8, more otherwise) or by a space. 0x"1 2" is equivalent
to 0x"01 02" or 0x"0102" if CHAR_BIT==8.
>> 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.
>> 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.
>
> Here it gets confusing. But first, I understand that CHAR_BIT could be
> 64, where hex literals get long enough that they could do with
> separators. But spaces now are significant in marking the early end of
> a 64-bit value.
Yes, CHAR_BIT could be 64, but that's vanishingly rare (it might be the
case for some DSP implementations).
> What I have in mind is that somebody might write 0x"12 34 56 78" to
> designate 4 8-bit values totalling 32 bits, and wants the spaces for
> readability. Compiled for a machine with 16-bit characters, it will
> now represent (in little-endian) the 64-bit value 0x0078005600340012
> instead of 0x78563412.
Right. Clarity for systems with CHAR_BIT>8 is not a high priority
IMHO. I'm trying to specify the syntax and semantics to allow
for such systems, but not to make things a little easier for such
exotic systems at the expense of complexity. And I'd expect most
long hex string literals to be automatically generated, whether by
#embed or some other mechanism, so legibility isn't hugely important.
C23 adds optional digit separators for numeric constants so you can
write 123'456'789 or 0xde'ad'be'ef . I tend to think that allowing
purely decorative separators *and* semantically significant blanks
would be too confusing, but I wouldn't strongly object to it.
> I assume the hex string can only be used to initialise a char[] array?
> (The feature I presented elsewhere, 'data-strings', could be used to
> initialise any array type, just like #embed IIUC.)
In the design I have in mind, no, a hex string literal is of type
const unsigned char[N]. The standard defines the *representation*
of a value as the contents of an object of type unsigned char[N].
If you want to initialize something other than array of unsigned
char, you can use some kind of type-punning.
>> This could be made more flexible by allowing various backslash
>> escapes, but I'm not inclined to complicate it too much.
>> 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]`).
>
> You mean, values that can only be one byte long? I don't get it. How
> many use-cases are there for char-arrays that are only a byte long?
No, that was just an example. *If* binary string literals were
allowed they could be arbitrarily long. 0b"11001001 00110110"
would be of type `const unsigned char[2]`. (I'm not stringly in
favor of supporting binary or octal string literals; they're just
something to be considered if we want to be overly consistent.
Hex alone is probably 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.
>
> Sorry, I thought this was an alternative to #embed, for smaller
> amounts of data directly written in source code.
It's not *just* an alternative to #embed. It's intended partly as
an alternative for what #embed can expand to. If we were earlier
in the C23 process, I might have proposed this as the default way
#embed works. Since it's probably too late for such a change, I'd
suggest a new #embed parameter so that `#embed "filename" hex(true)`
expands to one or more hex string constants. (A compiler could
implement this as an extension even if the standard isn't changed.)
And of course hex string literals could also be used without #embed.
--
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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-06-17 22:39 -0700 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <86v826kdxn.fsf@linuxsc.com> |
| In reply to | #386089 |
bart <bc@freeuk.com> writes: > AFAIK nobody uses octal anymore. There are circumstances where being able to write constants in octal is useful. It also would be nice to be able to write constants in base 4 and base 32 (because 5 is half of 10). I don't have occasion to prefer octal very often but I'm glad it's there for those times when I do.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-06-18 12:39 +0300 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <20240618123940.00007f1a@yahoo.com> |
| In reply to | #386139 |
On Mon, 17 Jun 2024 22:39:00 -0700 Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > bart <bc@freeuk.com> writes: > > > AFAIK nobody uses octal anymore. > > There are circumstances where being able to write constants > in octal is useful. It also would be nice to be able to > write constants in base 4 and base 32 (because 5 is half > of 10). I don't have occasion to prefer octal very often > but I'm glad it's there for those times when I do. Ada/VHDL permits any base from 2 to 16. They didn't go as far up as 32. I would imagine that reading base 32 number would take time to become accustomed. Besides, using I and O as digits is problematic because of visual similarity to 1 an 0. Using l is problematic both because of visual similarity to 1 and because of clash with existing use as suffix.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-06-18 11:28 +0100 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <v4rnfh$1a6m8$1@dont-email.me> |
| In reply to | #386157 |
On 18/06/2024 10:39, Michael S wrote:
> On Mon, 17 Jun 2024 22:39:00 -0700
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> bart <bc@freeuk.com> writes:
>>
>>> AFAIK nobody uses octal anymore.
>>
>> There are circumstances where being able to write constants
>> in octal is useful. It also would be nice to be able to
>> write constants in base 4 and base 32 (because 5 is half
>> of 10). I don't have occasion to prefer octal very often
>> but I'm glad it's there for those times when I do.
>
> Ada/VHDL permits any base from 2 to 16. They didn't go as far up as
> 32.
So did I for a while (in my language), for both integer and float
constants. (Possibly influenced by languages such as Ada which allowed
any base.)
But it was more of a novelty. In the end I decided they were just not
useful enough, and simplified it so that only bases 2, 10 and 16 were
supported.
Although output of integers in those bases is still possible (supported
by code in a library, rather than within a compiler):
print 81:"x3" # displays 10000
(Output of floats is done via sprintf; the C library won't do those odd
bases.)
While I did have it though, I noticed this strange discrepancy between
between my hex floats and C's. In C, this value:
0x12.34p10
has the decimal value 18640.0; why was that? It turns that this is:
18.203125 x 2 ** 10
The main part is interpreted as actual hex; the exponent is in decimal,
and exponent scaling is in binary bits. So THREE diferent bases are
involved!
In my scheme (which as I said worked for bases from 2 to 16), the
0x12.34p10 value would mean this:
18.203125 x 16 ** 16 ~= 3.58e20
The same base is used for all parts, including the exponent, and the
digits that are to be shifted. After all in decimal, 12.34e10 would mean:
12.34 x 10 ** 10 = 123400000000.0
In my language, a base 5 version 5x12.34e10 (not valid below base 5)
would mean this (I think, as I no longer have the compiler):
7.76 x 5 ** 5 = 24250.0
This has a consistency lacking in C's hex floats.
> I would imagine that reading base 32 number would take time to become
> accustomed.
My big-number /decimal/ library uses base 1000000000. That value fits
into one i32 'limb'. But it doesn't need a billion distinct symbols, it
just uses base-10 decimal as input and output.
As to why you can't use a similar idea for base-32, you'd have to look
at what base-32 was used for. Certainly within source code, you could
have a construct like:
base32(31,31,31) equivalent to 31*32**2 + 31*32 + 32 = 32767
A user running an application that promises base-32 arithmetic may
expect something more exotic however.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-06-18 11:12 -0700 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <86wmmmi0hm.fsf@linuxsc.com> |
| In reply to | #386164 |
bart <bc@freeuk.com> writes: > [...] I noticed this strange discrepancy between > between my hex floats and C's. In C, this value: > > 0x12.34p10 > > has the decimal value 18640.0; why was that? It turns that this is: > > 18.203125 x 2 ** 10 > > The main part is interpreted as actual hex; the exponent is in > decimal, and exponent scaling is in binary bits. So THREE diferent > bases are involved! > > In my scheme (which as I said worked for bases from 2 to 16), the > 0x12.34p10 value would mean this: > > 18.203125 x 16 ** 16 ~= 3.58e20 > > The same base is used for all parts, including the exponent, and the > digits that are to be shifted. After all in decimal, 12.34e10 would > mean: > > 12.34 x 10 ** 10 = 123400000000.0 > > In my language, a base 5 version 5x12.34e10 (not valid below base 5) > would mean this (I think, as I no longer have the compiler): > > 7.76 x 5 ** 5 = 24250.0 > > This has a consistency lacking in C's hex floats. The C hex float format has benefits that your format does not.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-06-18 17:20 +0200 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <v4s8jc$1d30n$1@dont-email.me> |
| In reply to | #386157 |
On 18/06/2024 11:39, Michael S wrote: > On Mon, 17 Jun 2024 22:39:00 -0700 > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> bart <bc@freeuk.com> writes: >> >>> AFAIK nobody uses octal anymore. >> >> There are circumstances where being able to write constants >> in octal is useful. It also would be nice to be able to >> write constants in base 4 and base 32 (because 5 is half >> of 10). I don't have occasion to prefer octal very often >> but I'm glad it's there for those times when I do. > > Ada/VHDL permits any base from 2 to 16. They didn't go as far up as > 32. > I would imagine that reading base 32 number would take time to become > accustomed. I can't imagine any possible use for such bases. Base 16 is very common, and base 2 is useful in some circumstances. Base 8 has, to my knowledge, a single non-archaic use-case and that is for chmod modes in *nix programming. I think support for other bases exists in some languages as a side-effect of wanting an explicit numbered base notation for bases 2, 16 and possibly 8, rather than using 0b, 0x and 0o (or 0q, or just 0 as an April fool's joke). If I were the BDFL of C, I'd remove octal constants and add a macro "_Octal" with definition: #define _Octal(n) (((n) % 10) + ((n) / 10 % 10) * 8 \ + ((n) / 100 % 10) * 64 + ((n) / 1000 % 10) * 512) If anyone can present a good use for base 4 or base 32, I might change my mind :-)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-06-18 11:04 -0700 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <865xu6jffq.fsf@linuxsc.com> |
| In reply to | #386157 |
Michael S <already5chosen@yahoo.com> writes: > On Mon, 17 Jun 2024 22:39:00 -0700 > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> bart <bc@freeuk.com> writes: >> >>> AFAIK nobody uses octal anymore. >> >> There are circumstances where being able to write constants >> in octal is useful. It also would be nice to be able to >> write constants in base 4 and base 32 (because 5 is half >> of 10). I don't have occasion to prefer octal very often >> but I'm glad it's there for those times when I do. > > Ada/VHDL permits any base from 2 to 16. They didn't go as far up as > 32. > I would imagine that reading base 32 number would take time to become > accustomed. > Besides, using I and O as digits is problematic because of visual > similarity to 1 an 0. Using l is problematic both because of visual > similarity to 1 and because of clash with existing use as suffix. It would be nice (in some circumstances) to be able to write constants in base 32. That doesn't mean I'm proposing that such constants be written using the common 10-digits-22-letters form of representation. Realistically I think it's unlikely that the C standard will ever add a base-32 form for integer constants, and even if it did I wouldn't want to wait that long before it could be used reliably. So all I'm saying is that base-32 constants are sometimes useful, even if they aren't incorporated into standard C.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-06-20 06:51 +0000 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <v50ji5$2f1sq$1@dont-email.me> |
| In reply to | #386157 |
On Tue, 18 Jun 2024 12:39:40 +0300, Michael S wrote: > I would imagine that reading base 32 number would take time to become > accustomed. Base 30 would be a useful base, because it includes 2, 3 and 5 as prime factors. This means fractions incorporating those factors as denominators can be represented exactly.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2024-06-18 09:50 +0000 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <20240618024703.632@kylheku.com> |
| In reply to | #386089 |
On 2024-06-17, bart <bc@freeuk.com> wrote: > AFAIK nobody uses octal anymore. Unix shell and C programmers fairly often use octal unintentionally, whereby harmless-looking leading zero changes what was supposed to be, say, 77 to 63. -- 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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-06-18 13:56 +0000 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <emgcO.10689$BRt3.7131@fx05.iad> |
| In reply to | #386158 |
Kaz Kylheku <643-408-1753@kylheku.com> writes: >On 2024-06-17, bart <bc@freeuk.com> wrote: >> AFAIK nobody uses octal anymore. > >Unix shell and C programmers fairly often use octal unintentionally, Perhaps you do. Don't speak for others, please.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-06-18 17:21 +0200 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <v4s8ks$1d30n$2@dont-email.me> |
| In reply to | #386174 |
On 18/06/2024 15:56, Scott Lurndal wrote: > Kaz Kylheku <643-408-1753@kylheku.com> writes: >> On 2024-06-17, bart <bc@freeuk.com> wrote: >>> AFAIK nobody uses octal anymore. >> >> Unix shell and C programmers fairly often use octal unintentionally, > > Perhaps you do. Don't speak for others, please. > Others do it too. Perhaps not "fairly often", but it certainly happens.
[toc] | [prev] | [next] | [standalone]
| From | Richard Harnden <richard.nospam@gmail.invalid> |
|---|---|
| Date | 2024-06-18 19:25 +0100 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <v4sjf3$1fm4h$1@dont-email.me> |
| In reply to | #386180 |
On 18/06/2024 16:21, David Brown wrote: > On 18/06/2024 15:56, Scott Lurndal wrote: >> Kaz Kylheku <643-408-1753@kylheku.com> writes: >>> On 2024-06-17, bart <bc@freeuk.com> wrote: >>>> AFAIK nobody uses octal anymore. >>> >>> Unix shell and C programmers fairly often use octal unintentionally, >> >> Perhaps you do. Don't speak for others, please. >> > > Others do it too. Perhaps not "fairly often", but it certainly happens. > This has bit me ... $ ping -c 1 192.168.1.17 PING 192.168.1.17 (192.168.1.17) 56(84) bytes of data. 64 bytes from 192.168.1.17: icmp_seq=1 ttl=64 time=0.097 ms --- 192.168.1.17 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.097/0.097/0.097/0.000 ms $ ping -c 1 192.168.001.017 PING 192.168.001.017 (192.168.1.15) 56(84) bytes of data. From 192.168.1.17 icmp_seq=1 Destination Host Unreachable --- 192.168.001.017 ping statistics --- 1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
[toc] | [prev] | [next] | [standalone]
| From | Richard Harnden <richard.nospam@gmail.invalid> |
|---|---|
| Date | 2024-06-18 19:38 +0100 |
| Subject | Re: Hex string literals (was Re: C23 thoughts and opinions) |
| Message-ID | <v4sk6j$1fm4h$2@dont-email.me> |
| In reply to | #386197 |
On 18/06/2024 19:25, Richard Harnden wrote: > On 18/06/2024 16:21, David Brown wrote: >> On 18/06/2024 15:56, Scott Lurndal wrote: >>> Kaz Kylheku <643-408-1753@kylheku.com> writes: >>>> On 2024-06-17, bart <bc@freeuk.com> wrote: >>>>> AFAIK nobody uses octal anymore. >>>> >>>> Unix shell and C programmers fairly often use octal unintentionally, >>> >>> Perhaps you do. Don't speak for others, please. >>> >> >> Others do it too. Perhaps not "fairly often", but it certainly happens. >> > > This has bit me ... > > $ ping -c 1 192.168.1.17 > PING 192.168.1.17 (192.168.1.17) 56(84) bytes of data. > 64 bytes from 192.168.1.17: icmp_seq=1 ttl=64 time=0.097 ms > > --- 192.168.1.17 ping statistics --- > 1 packets transmitted, 1 received, 0% packet loss, time 0ms > rtt min/avg/max/mdev = 0.097/0.097/0.097/0.000 ms > > $ ping -c 1 192.168.001.017 > PING 192.168.001.017 (192.168.1.15) 56(84) bytes of data. > From 192.168.1.17 icmp_seq=1 Destination Host Unreachable > > --- 192.168.001.017 ping statistics --- > 1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms > > Which is obviously more fun when the .15 also exists.
[toc] | [prev] | [next] | [standalone]
Page 6 of 28 — ← Prev page 1 … 4 5 [6] 7 8 … 28 Next page →
Back to top | Article view | comp.lang.c
csiph-web