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 2 of 28 — ← Prev page 1 [2] 3 4 … 28 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-05-25 16:34 -0700 |
| Message-ID | <87a5kd1n54.fsf@nosuchdomain.example.com> |
| In reply to | #385057 |
David Brown <david.brown@hesbynett.no> writes:
> On 25/05/2024 13:33, Thiago Adams wrote:
>> Em 5/24/2024 9:46 PM, Keith Thompson escreveu:
>>> Thiago Adams <thiago.adams@gmail.com> writes:
>>>> Em 5/24/2024 5:19 PM, Keith Thompson escreveu:
>>>>> Thiago Adams <thiago.adams@gmail.com> writes:
>>>>>> On 24/05/2024 16:45, Keith Thompson wrote:
>>>>>>> Thiago Adams <thiago.adams@gmail.com> writes:
>>>>>>>> On 23/05/2024 18:49, Keith Thompson wrote:
>>>>>>>>>> error: 'constexpr' pointer initializer is not null
>>>>>>>>>> 5 | constexpr char * s[] = {"a", "b"};
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Then we were asking why constexpr was used in that case.
>>>>>>>>> Why not?
>>>>>>>>
>>>>>>>> When I see a constexpr I ask if the compiler is able to compute
>>>>>>>> everything at compile time. If not immediately it is a bad
>>>>>>>> usage in my
>>>>>>>> view.
>>>>>>> I don't understand. Do you object because it's not *immediately
>>>>>>> obvious* that everthing can be computed at compile time? If so, why
>>>>>>> should it have to be?
>>>>>>
>>>>>> My understanding is that constexpr is a tip for the compiler. Does not
>>>>>> ensure anything. Unless you use where constant expression is required.
>>>>>> So I don't like to see constexpr where I know it is not a constant
>>>>>> expression.
>>>>> Your understanding is incorrect. "constexpr" is not a mere hint.
>>>> I think I can explain I little better
>>>>
>>>> Let´s consider we have a compile time array of integers and a loop.
>>>>
>>>> https://godbolt.org/z/e8cM1KGWT
>>>>
>>>> #include <stdio.h>
>>>> #include <stdlib.h>
>>>> int main() {
>>>> constexpr int a[] = {1, 2, 3, 4, 5, 6, 7, 8};
>>>> for (int i = 0 ; i < sizeof(a)/sizeof(a[0]); i++)
>>>> {
>>>> printf("%d", a[i]);
>>>> }
>>>> }
>>>>
>>>> What the programmer expected using a constant array in a loop?
>>>> The loop is in runtime, unless the compiler expanded the loop into 8
>>>> calls using constant expressions. But this is not the case.
>>>> This was the usage of constexpr I saw but with literal strings.
>>>> So, the array a is not used as constant even if it has constexpr.
>>>
>>> What do you mean by "used as constant"?
>>>
>> Something used to produce a constant expression.
>> In the loop the compiler would have to get the value in runtime from
>> array, or unroll the loop.
>> I just checked, trying to extract an constant value from the array
>>
>> https://godbolt.org/z/v33Pqd7W8
>> #include <stdio.h>
>> #include <stdlib.h>
>> int main() {
>> constexpr int a[] = {1, 2, 3, 4, 5, 6, 7, 8};
>> static_assert(a[0] ==1 );
>> }
>> I was expecting this to work!
>> But gcc says
>> <source>:5:24: error: expression in static assertion is not constant
>> 5 | static_assert(a[0] ==1 );
>> |
>>
>
> That is disappointing. I too would have expected that to work in
> C23. My guess is that it is the implicit pointer dereference that is
> the problem. But I hope this is something that gets fixed shortly.
[...]
The definition of constant expressions in C23 isn't much different from
the definition in C17. I think the committee was cautious about making
too many changes. Adding the full semantics of C++'s constexpr likely
would have been impractical.
Don't expect this to be "fixed" before C26 at the earliest.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-05-25 13:05 +0200 |
| Message-ID | <v2sgm6$2rle2$1@dont-email.me> |
| In reply to | #385028 |
On 25/05/2024 02:27, Thiago Adams wrote:
> Em 5/24/2024 5:19 PM, Keith Thompson escreveu:
>> Thiago Adams <thiago.adams@gmail.com> writes:
>>> On 24/05/2024 16:45, Keith Thompson wrote:
>>>> Thiago Adams <thiago.adams@gmail.com> writes:
>>>>> On 23/05/2024 18:49, Keith Thompson wrote:
>>>>>>> error: 'constexpr' pointer initializer is not null
>>>>>>> 5 | constexpr char * s[] = {"a", "b"};
>>>>>>>
>>>>>>>
>>>>>>> Then we were asking why constexpr was used in that case.
>>>>>> Why not?
>>>>>
>>>>> When I see a constexpr I ask if the compiler is able to compute
>>>>> everything at compile time. If not immediately it is a bad usage in my
>>>>> view.
>>>> I don't understand. Do you object because it's not *immediately
>>>> obvious* that everthing can be computed at compile time? If so, why
>>>> should it have to be?
>>>
>>> My understanding is that constexpr is a tip for the compiler. Does not
>>> ensure anything. Unless you use where constant expression is required.
>>> So I don't like to see constexpr where I know it is not a constant
>>> expression.
>>
>> Your understanding is incorrect. "constexpr" is not a mere hint.
> I think I can explain I little better
>
> Let´s consider we have a compile time array of integers and a loop.
>
> https://godbolt.org/z/e8cM1KGWT
>
> #include <stdio.h>
> #include <stdlib.h>
> int main() {
> constexpr int a[] = {1, 2, 3, 4, 5, 6, 7, 8};
> for (int i = 0 ; i < sizeof(a)/sizeof(a[0]); i++)
> {
> printf("%d", a[i]);
> }
> }
>
> What the programmer expected using a constant array in a loop?
> The loop is in runtime, unless the compiler expanded the loop into 8
> calls using constant expressions. But this is not the case.
> This was the usage of constexpr I saw but with literal strings.
> So, the array a is not used as constant even if it has constexpr.
>
The array /is/ constant. It never changes. The compiler can use that.
I would expect the array to be fixed in the code section of the binary,
along with any other read-only data in the program, rather than put on
the stack.
In this particular case, the constexpr makes little difference because
the compiler knows everything about what happens to the array "a", since
its address does not "escape" from the current translation unit. The
compiler will generate the same code regardless of whether the array is
declared "constexpr int", "const int", or plain "int". (But it can
check for accidental modification better with "const" or "constexpr" in
case the programmer made a mistake.)
I am not entirely sure of the specifications for printf, but the
compiler may even be able to turn this into:
int main() {
printf("12345678");
}
It is /certainly/ allowed to turn it into :
int main() {
for (int i = 1; i < 9; i++) {
printf("%d", i);
}
}
In C (not C++), defining an object as "constexpr" gives you two things
compared to defining it as "const". One is that its value can be used
when you need a constant expression according to the rules of the
language (such as for the size of an array in a struct). The other is
that it gives a compile-time error if its initialiser is not itself a
constant expression - and that means an extra check and protection
against some kinds of programmer errors, and extra information to people
reading the code.
I don't expect it to make a difference in generated code from an
optimising compiler, in comparison to objects declared with "const".
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2024-05-25 08:19 -0300 |
| Message-ID | <3510a9be-2962-4f8a-a040-62e2716eed92@gmail.com> |
| In reply to | #385044 |
Em 5/25/2024 8:05 AM, David Brown escreveu:
> On 25/05/2024 02:27, Thiago Adams wrote:
>> Em 5/24/2024 5:19 PM, Keith Thompson escreveu:
>>> Thiago Adams <thiago.adams@gmail.com> writes:
>>>> On 24/05/2024 16:45, Keith Thompson wrote:
>>>>> Thiago Adams <thiago.adams@gmail.com> writes:
>>>>>> On 23/05/2024 18:49, Keith Thompson wrote:
>>>>>>>> error: 'constexpr' pointer initializer is not null
>>>>>>>> 5 | constexpr char * s[] = {"a", "b"};
>>>>>>>>
>>>>>>>>
>>>>>>>> Then we were asking why constexpr was used in that case.
>>>>>>> Why not?
>>>>>>
>>>>>> When I see a constexpr I ask if the compiler is able to compute
>>>>>> everything at compile time. If not immediately it is a bad usage
>>>>>> in my
>>>>>> view.
>>>>> I don't understand. Do you object because it's not *immediately
>>>>> obvious* that everthing can be computed at compile time? If so, why
>>>>> should it have to be?
>>>>
>>>> My understanding is that constexpr is a tip for the compiler. Does not
>>>> ensure anything. Unless you use where constant expression is required.
>>>> So I don't like to see constexpr where I know it is not a constant
>>>> expression.
>>>
>>> Your understanding is incorrect. "constexpr" is not a mere hint.
>> I think I can explain I little better
>>
>> Let´s consider we have a compile time array of integers and a loop.
>>
>> https://godbolt.org/z/e8cM1KGWT
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>> int main() {
>> constexpr int a[] = {1, 2, 3, 4, 5, 6, 7, 8};
>> for (int i = 0 ; i < sizeof(a)/sizeof(a[0]); i++)
>> {
>> printf("%d", a[i]);
>> }
>> }
>>
>> What the programmer expected using a constant array in a loop?
>> The loop is in runtime, unless the compiler expanded the loop into 8
>> calls using constant expressions. But this is not the case.
>> This was the usage of constexpr I saw but with literal strings.
>> So, the array a is not used as constant even if it has constexpr.
>>
>
> The array /is/ constant. It never changes. The compiler can use that.
> I would expect the array to be fixed in the code section of the binary,
> along with any other read-only data in the program, rather than put on
> the stack.
>
> In this particular case, the constexpr makes little difference because
> the compiler knows everything about what happens to the array "a", since
> its address does not "escape" from the current translation unit. The
> compiler will generate the same code regardless of whether the array is
> declared "constexpr int", "const int", or plain "int". (But it can
> check for accidental modification better with "const" or "constexpr" in
> case the programmer made a mistake.)
>
> I am not entirely sure of the specifications for printf, but the
> compiler may even be able to turn this into:
>
> int main() {
> printf("12345678");
> }
>
> It is /certainly/ allowed to turn it into :
>
> int main() {
> for (int i = 1; i < 9; i++) {
> printf("%d", i);
> }
> }
>
> In C (not C++), defining an object as "constexpr" gives you two things
> compared to defining it as "const". One is that its value can be used
> when you need a constant expression according to the rules of the
> language (such as for the size of an array in a struct). The other is
> that it gives a compile-time error if its initialiser is not itself a
> constant expression - and that means an extra check and protection
> against some kinds of programmer errors, and extra information to people
> reading the code.
>
> I don't expect it to make a difference in generated code from an
> optimising compiler, in comparison to objects declared with "const".
>
>
In my view , for this sample constexpr generates noise. It also can make
the compilation slower, otherwise, why not everything constexpr by defaul?
I still didn't find a useful usage for constexpr that would compensate
the mess created with const, constexpr. I already saw ( I don't have it
now ) proposals to make const more like constexpr in C. In C++ const is
already a constant expression!
The justification for C was VLA. They should consider VLA not VLA if it
has a constant expression. In other words, better break this than create
a mess.
#define makes the job of constexpr.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-05-25 17:14 +0200 |
| Message-ID | <v2sv8a$2u3d4$1@dont-email.me> |
| In reply to | #385046 |
On 25/05/2024 13:19, Thiago Adams wrote: > Em 5/25/2024 8:05 AM, David Brown escreveu: >> >> In C (not C++), defining an object as "constexpr" gives you two things >> compared to defining it as "const". One is that its value can be used >> when you need a constant expression according to the rules of the >> language (such as for the size of an array in a struct). The other is >> that it gives a compile-time error if its initialiser is not itself a >> constant expression - and that means an extra check and protection >> against some kinds of programmer errors, and extra information to >> people reading the code. >> >> I don't expect it to make a difference in generated code from an >> optimising compiler, in comparison to objects declared with "const". >> >> > > In my view , for this sample constexpr generates noise. I don't share that opinion, but I understand it. > It also can make > the compilation slower, otherwise, why not everything constexpr by defaul? That claim, on the other hand, is very strange. Making everything constexpr by default would be a massive change to the language that would break all but the most negligible of existing code. And I can think of no particular reason why constexpr would slow down compilation, at least to any measurable degree. > I still didn't find a useful usage for constexpr that would compensate > the mess created with const, constexpr. I don't need a feature to "compensate" for anything to be useful. I don't need it to be perfect to be useful. There's a few things about constexpr in C23 that I think are poor decisions, unreasonable restrictions, or suboptimal integration with other language features (like static_assert) - such as the array limitations you've found. That will mean I can't use constexpr as much as I'd like, or as much as I do in C++. But even if there is just one situation where I think using constexpr is neater or clearer than using enum, #define, or some other technique, then I will use constexpr in that one situation. Why are you so insistent on throwing it out completely just because it doesn't do everything you might want? > I already saw ( I don't have it > now ) proposals to make const more like constexpr in C. In C++ const is > already a constant expression! No, it is not - but sometimes a const object with particular characteristics can be used in situations where you would otherwise need a constant expression. I mentioned earlier that I find this convenient in C++ - Keith said it was inconsistent, which is also true. I think that to a large extent, if C "const" had acquired the additional features of C++ "const" (excluding the different linkage for file-scope "const" objects, since that would be a breaking change) then it would have done everything C23 "constexpr" does today. I personally would have been fine with that as a solution. But I fully appreciate that it would have been inconsistent and perhaps hard to specify - you'd would have the situation that /some/ const objects could be used for things like static initialisers, while others could not. > The justification for C was VLA. They should consider VLA not VLA if it > has a constant expression. In other words, better break this than create > a mess. > #define makes the job of constexpr. > #define is one way to make named items that can be used in constant expressions, yes. But if it can be done using #define or constexpr, I think constexpr is the neater choice. Opinions can vary - that's my opinion.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-05-26 02:09 +0100 |
| Message-ID | <v2u23q$33ua5$1@dont-email.me> |
| In reply to | #385059 |
On 25/05/2024 16:14, David Brown wrote:
> On 25/05/2024 13:19, Thiago Adams wrote:
>> The justification for C was VLA. They should consider VLA not VLA if
>> it has a constant expression. In other words, better break this than
>> create a mess.
>> #define makes the job of constexpr.
>>
>
> #define is one way to make named items that can be used in constant
> expressions, yes. But if it can be done using #define or constexpr, I
> think constexpr is the neater choice. Opinions can vary - that's my
> opinion.
Before 'constexpr' (and it still is 'before' as implementations are
rare), there were three disparate ways of emulating named constants in C:
#define A 100
enum {B = 200};
int const C = 300;
None of them fully do the job of the named constant feature I've used in
my own languages (and which I also briefly had in my C compiler).
With 'constexpr' there are now 4 ways of doing it:
constexpr int D = 400;
Here are some characteristics of true named constants and how those
methods fare:
#define enum const constexpr
Scope rules N Y Y Y
No & addr-of Y Y N N?
Any type Y? N Y Y Any int/float
Non-VLA bounds Y Y N Y?
Switch-case? Y Y N Y?
Reduce Y Y ? Y? 2+3 => 5
Can't Mod value Y Y N N? By any means
Not Context sens N Y Y Y Value may vary by context
Single reeval N Y Y Y Expr processed once
Lower case OK N? Y Y Y
Ideally a column would have all Ys. None of these manage that, but
'enum' comes nearest. However it has a problem: it wasn't designed for
this task, which is just a useful by-product. So it looks odd.
With const/constexpr, even if the language can't stop attempts to change
the value, sometimes those attempts are trapped (via read-only mem etc).
That's not ideal either.
Regarding 'Not context sensitive', consider:
----------------------
#include <stdio.h>
enum {a = 100};
#define M (a+1)
enum {b = M};
int main(void) {
enum {a=777};
printf("b = %d\n", b);
printf("M = %d\n", M);
}
----------------------
The output is 101 and 778. The value of M is 101 when used to define
`b`, and 778 later on.
'Single reevaluation' refers to the fact that the expansion of a #define
macro will be repeated at each invocation side, so parsing, evaluation
and reduction of the expression will be done multiple times. It's just
inefficient.
It might also vary, not just because of the last point, but because
there aren't enough parentheses or something so combines differently
with surrounding context.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2024-06-06 15:01 -0300 |
| Message-ID | <v3stia$1jpih$1@dont-email.me> |
| In reply to | #385046 |
On 25/05/2024 08:19, Thiago Adams wrote:
...
> In my view , for this sample constexpr generates noise. It also can make
> the compilation slower, otherwise, why not everything constexpr by defaul?
> I still didn't find a useful usage for constexpr that would compensate
> the mess created with const, constexpr. I already saw ( I don't have it
> now ) proposals to make const more like constexpr in C. In C++ const is
> already a constant expression!
> The justification for C was VLA. They should consider VLA not VLA if it
> has a constant expression. In other words, better break this than create
> a mess.
> #define makes the job of constexpr.
>
>
>
One more sample of NOISE of constexpr from the same real source.
int compare(const Node* a, const Node* b)
{
return memcmp(a, b, sizeof(Node)) == 0;
}
bool IsValid(Node * pnid)
{
static constexpr Node node = { 1, 2 };
return compare(pnid, &node);
}
What is expectation passing the address of compile constant to a runtime
function? This is pure noise!
Nothing happens, nothing is done at compile time.
https://godbolt.org/z/ecsMf4vaY
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-05-22 15:53 -0700 |
| Message-ID | <87msoh5uh6.fsf@nosuchdomain.example.com> |
| In reply to | #384830 |
David Brown <david.brown@hesbynett.no> writes:
> On 22/05/2024 19:42, Thiago Adams wrote:
[...]
>> - nullptr
>
> I am fond of nullptr in C++, and will use it in C. Like most of the
> C23 changes, it's not a big issue - after all, you get a lot of the
> same effect with "#define nullptr (void*)(0)" or similar. But it
> means your code has a visual distinction between the integer 0 and a
> null pointer, and also lets the compiler or other static checking
> system check better than using NULL would. (And I don't like NULL - I
> dislike all-caps identifiers in general.)
Quibble: That should be
#define nullptr ((void*)0)
For example, this doesn't produce a syntax error for `sizeof nullptr`.
Better:
#if __STDC_VERSION__ < 202311L
#define nullptr ((void*)0)
#endif
C23's nullptr is of type nullptr_t, not void*. But you'd probably have
to go out of your way for that to be an issue (e.g., using nullptr in a
generic selection).
[...]
>> - constexpr
>
> I will definitely use that. Sometimes I want a constant expression
> for things like array sizes or static initialisers, and want to
> calculate it. constexpr gives you that without having to resort to
> macros. (I'd perhaps be even happier if I could just use const, as I
> can in C++.)
But const doesn't mean constant. It means read-only.
`const int r = rand();` is perfectly valid.
I dislike the C++ hack of making N a constant expression given
`const int N = 42;`; constexpr made that unnecessary. C23 makes the
same (IMHO) mistake.
If I had a time machine, I'd spell "const" as "readonly" and make
"const" mean what "constexpr" now means (evaluated at compile time).
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2024-05-22 22:21 -0300 |
| Message-ID | <f08d2c9f-5c2e-495d-b0bd-3f71bd301432@gmail.com> |
| In reply to | #384844 |
Em 5/22/2024 7:53 PM, Keith Thompson escreveu: > David Brown <david.brown@hesbynett.no> writes: >> On 22/05/2024 19:42, Thiago Adams wrote: > [...] >>> - nullptr >> >> I am fond of nullptr in C++, and will use it in C. Like most of the >> C23 changes, it's not a big issue - after all, you get a lot of the >> same effect with "#define nullptr (void*)(0)" or similar. But it >> means your code has a visual distinction between the integer 0 and a >> null pointer, and also lets the compiler or other static checking >> system check better than using NULL would. (And I don't like NULL - I >> dislike all-caps identifiers in general.) > > Quibble: That should be > > #define nullptr ((void*)0) > > For example, this doesn't produce a syntax error for `sizeof nullptr`. > > Better: > > #if __STDC_VERSION__ < 202311L > #define nullptr ((void*)0) > #endif > > C23's nullptr is of type nullptr_t, not void*. But you'd probably have > to go out of your way for that to be an issue (e.g., using nullptr in a > generic selection). > > [...] > >>> - constexpr >> >> I will definitely use that. Sometimes I want a constant expression >> for things like array sizes or static initialisers, and want to >> calculate it. constexpr gives you that without having to resort to >> macros. (I'd perhaps be even happier if I could just use const, as I >> can in C++.) > > But const doesn't mean constant. It means read-only. > `const int r = rand();` is perfectly valid. > > I dislike the C++ hack of making N a constant expression given > `const int N = 42;`; constexpr made that unnecessary. C23 makes the > same (IMHO) mistake. > > If I had a time machine, I'd spell "const" as "readonly" and make > "const" mean what "constexpr" now means (evaluated at compile time). > > [...] Everything is a mess: const in C++, the differences from const in C, etc. constexpr in C23 just makes the mess bigger. auto is a mess as well not well specified for pointer. not sure if we had this topic here, but auto * p in C is not specified. I would remove from C23 - nullptr -auto -constexpr -embed I like the idea of embed but there is no implementation in production so this is crazy!
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-05-23 13:11 +0100 |
| Message-ID | <v2nbp4$1o9h6$1@dont-email.me> |
| In reply to | #384846 |
On 23/05/2024 02:21, Thiago Adams wrote:
> Em 5/22/2024 7:53 PM, Keith Thompson escreveu:
>> But const doesn't mean constant. It means read-only.
>> `const int r = rand();` is perfectly valid.
>>
>> I dislike the C++ hack of making N a constant expression given
>> `const int N = 42;`; constexpr made that unnecessary. C23 makes the
>> same (IMHO) mistake.
>>
>> If I had a time machine, I'd spell "const" as "readonly" and make
>> "const" mean what "constexpr" now means (evaluated at compile time).
>>
>> [...]
>
> Everything is a mess: const in C++, the differences from const in C,
> etc. constexpr in C23 just makes the mess bigger.
>
> auto is a mess as well not well specified for pointer. not sure if we
> had this topic here, but auto * p in C is not specified.
>
> I would remove from C23
> - nullptr
> -auto
> -constexpr
> -embed
>
> I like the idea of embed but there is no implementation in production so
> this is crazy!
'embed' was discussed a few months ago. I disagreed with the poor way it
was to be implemented: 'embed' notionally generates a list of
comma-separated numbers as tokens, where you have to take care of any
trailing zero yourself if needed. It would also be hopelessly
inefficient if actually implemented like that.
I compared it to the scheme in my own language, which could import text
files, but binary ones didn't really work.
Since then embedding has been considerably improved, so that it works
like this:
[]char str = sinclude("hello.c")
[]byte data = binclude("hello.exe")
The file-embedding is done by sinclude or binclude. The former adds a
zero terminator to the embedded file data (expected to be a text file),
otherwise they are the same.
binclude can initialise any kind of array, including a 2D array of any
element type, although the data in the file needs to be suitable.
C23's 'embed' was claimed to be more flexible, as you can have
consecutive 'embed' directives initialising the same array. I can do the
same:
[]byte file = binclude("hello.exe") + binclude("/cx/big/sql.exe")
proc main=
println file.len
end
This generates an executable of 1077248 bytes, and displays 1050112 when
run, the combined size of those two embedded binaries. Compiling this
took 50ms.
("+" here is a compile-time operator that can concatenate constant
strings or also binary data like this.)
Basically, you are right that the ad hoc features of C23 are messy.
I suspect that ones like 'embed' have been derived from C++ which always
likes to make things too wide-ranging and much harder to use and
implement than necessary.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-05-23 09:43 -0700 |
| Message-ID | <875xv45viu.fsf@nosuchdomain.example.com> |
| In reply to | #384868 |
bart <bc@freeuk.com> writes:
[...]
> I suspect that ones like 'embed' have been derived from C++ which
> always likes to make things too wide-ranging and much harder to use
> and implement than necessary.
No, C++ doesn't have #embed. (If it did, many C compilers would already
have it, since C and C++ commonly share the preprocessor
implementation.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-05-24 16:19 +0200 |
| Message-ID | <v2q7m5$2c2bt$1@dont-email.me> |
| In reply to | #384874 |
On 23/05/2024 18:43, Keith Thompson wrote: > bart <bc@freeuk.com> writes: > [...] >> I suspect that ones like 'embed' have been derived from C++ which >> always likes to make things too wide-ranging and much harder to use >> and implement than necessary. > > No, C++ doesn't have #embed. (If it did, many C compilers would already > have it, since C and C++ commonly share the preprocessor > implementation.) > C++ has proposals for both #embed and std::embed<>, but AFAIK these are not yet accepted. I expect #embed to make it (since the big tools will support it for C anyway). std::embed<> is more powerful but has additional complications.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-05-23 15:25 +0200 |
| Message-ID | <v2ng4n$1p3o2$1@dont-email.me> |
| In reply to | #384868 |
On 23/05/2024 14:11, bart wrote: > On 23/05/2024 02:21, Thiago Adams wrote: >> Em 5/22/2024 7:53 PM, Keith Thompson escreveu: > >>> But const doesn't mean constant. It means read-only. >>> `const int r = rand();` is perfectly valid. >>> >>> I dislike the C++ hack of making N a constant expression given >>> `const int N = 42;`; constexpr made that unnecessary. C23 makes the >>> same (IMHO) mistake. >>> >>> If I had a time machine, I'd spell "const" as "readonly" and make >>> "const" mean what "constexpr" now means (evaluated at compile time). >>> >>> [...] >> >> Everything is a mess: const in C++, the differences from const in C, >> etc. constexpr in C23 just makes the mess bigger. >> >> auto is a mess as well not well specified for pointer. not sure if we >> had this topic here, but auto * p in C is not specified. >> >> I would remove from C23 >> - nullptr >> -auto >> -constexpr >> -embed >> >> I like the idea of embed but there is no implementation in production >> so this is crazy! > > 'embed' was discussed a few months ago. I disagreed with the poor way it > was to be implemented: 'embed' notionally generates a list of > comma-separated numbers as tokens, where you have to take care of any > trailing zero yourself if needed. It would also be hopelessly > inefficient if actually implemented like that. Fortunately, it is /not/ actually implemented like that - it is only implemented "as if" it were like that. Real prototype implementations (for gcc and clang - I don't know about other tools) are extremely efficient at handling #embed. And the comma-separated numbers can be more flexible in less common use-cases. (That was also made clear in the previous discussion. It's been a while since you posted much here - it's nice to see you back on form :-) )
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-05-23 13:06 -0700 |
| Message-ID | <87y18047jk.fsf@nosuchdomain.example.com> |
| In reply to | #384901 |
David Brown <david.brown@hesbynett.no> writes:
> On 23/05/2024 14:11, bart wrote:
[...]
>> 'embed' was discussed a few months ago. I disagreed with the poor
>> way it was to be implemented: 'embed' notionally generates a list of
>> comma-separated numbers as tokens, where you have to take care of
>> any trailing zero yourself if needed. It would also be hopelessly
>> inefficient if actually implemented like that.
>
> Fortunately, it is /not/ actually implemented like that - it is only
> implemented "as if" it were like that. Real prototype implementations
> (for gcc and clang - I don't know about other tools) are extremely
> efficient at handling #embed. And the comma-separated numbers can be
> more flexible in less common use-cases.
[...]
I'm aware of a proposed implementation for clang:
https://github.com/llvm/llvm-project/pull/68620
https://github.com/ThePhD/llvm-project
I'm currently cloning the git repo, with the aim of building it so I can
try it out and test some corner cases. It will take a while.
I'm not aware of any prototype implementation for gcc. If you are, I'd
be very interested in trying it out.
(And thanks for starting this thread!)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-05-24 15:45 +0200 |
| Message-ID | <v2q5mg$2bj78$1@dont-email.me> |
| In reply to | #384913 |
On 23/05/2024 22:06, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 23/05/2024 14:11, bart wrote: > [...] >>> 'embed' was discussed a few months ago. I disagreed with the poor >>> way it was to be implemented: 'embed' notionally generates a list of >>> comma-separated numbers as tokens, where you have to take care of >>> any trailing zero yourself if needed. It would also be hopelessly >>> inefficient if actually implemented like that. >> >> Fortunately, it is /not/ actually implemented like that - it is only >> implemented "as if" it were like that. Real prototype implementations >> (for gcc and clang - I don't know about other tools) are extremely >> efficient at handling #embed. And the comma-separated numbers can be >> more flexible in less common use-cases. > [...] > > I'm aware of a proposed implementation for clang: > > https://github.com/llvm/llvm-project/pull/68620 > https://github.com/ThePhD/llvm-project > > I'm currently cloning the git repo, with the aim of building it so I can > try it out and test some corner cases. It will take a while. > > I'm not aware of any prototype implementation for gcc. If you are, I'd > be very interested in trying it out. > I haven't seen anything concrete, but I believe I read about it in one of the papers discussing #embed. It may have been just some tests and proofs-of-concept, and not a development branch or proposed implementation. > (And thanks for starting this thread!) > It's not easy to find a topic that is entirely about C, hasn't been discussed to death already, has enough controversial aspects for a serious discussion but not so many that it leads to fights and flames, and is not so esoteric that it causes most readers eyes to glaze over!
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-05-24 18:29 -0700 |
| Message-ID | <87msoe1xxo.fsf@nosuchdomain.example.com> |
| In reply to | #384913 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> David Brown <david.brown@hesbynett.no> writes:
>> On 23/05/2024 14:11, bart wrote:
> [...]
>>> 'embed' was discussed a few months ago. I disagreed with the poor
>>> way it was to be implemented: 'embed' notionally generates a list of
>>> comma-separated numbers as tokens, where you have to take care of
>>> any trailing zero yourself if needed. It would also be hopelessly
>>> inefficient if actually implemented like that.
>>
>> Fortunately, it is /not/ actually implemented like that - it is only
>> implemented "as if" it were like that. Real prototype implementations
>> (for gcc and clang - I don't know about other tools) are extremely
>> efficient at handling #embed. And the comma-separated numbers can be
>> more flexible in less common use-cases.
> [...]
>
> I'm aware of a proposed implementation for clang:
>
> https://github.com/llvm/llvm-project/pull/68620
> https://github.com/ThePhD/llvm-project
>
> I'm currently cloning the git repo, with the aim of building it so I can
> try it out and test some corner cases. It will take a while.
>
> I'm not aware of any prototype implementation for gcc. If you are, I'd
> be very interested in trying it out.
>
> (And thanks for starting this thread!)
I've built this from source, and it mostly works. I haven't seen it do
any optimization; the `#embed` directive expands to a sequence of
comma-separated integer constants.
Which means that this:
#include <stdio.h>
int main(void) {
struct foo {
unsigned char a;
unsigned short b;
unsigned int c;
double d;
};
struct foo obj = {
#embed "foo.dat"
};
printf("a=%d b=%d c=%d d=%f\n", obj.a, obj.b, obj.c, obj.d);
}
given "foo.dat" containing bytes with values 1, 2, 3, and 4, produces
this output:
a=1 b=2 c=3 d=4.000000
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-05-25 13:11 +0200 |
| Message-ID | <v2sh19$2rle2$2@dont-email.me> |
| In reply to | #385034 |
On 25/05/2024 03:29, Keith Thompson wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 23/05/2024 14:11, bart wrote:
>> [...]
>>>> 'embed' was discussed a few months ago. I disagreed with the poor
>>>> way it was to be implemented: 'embed' notionally generates a list of
>>>> comma-separated numbers as tokens, where you have to take care of
>>>> any trailing zero yourself if needed. It would also be hopelessly
>>>> inefficient if actually implemented like that.
>>>
>>> Fortunately, it is /not/ actually implemented like that - it is only
>>> implemented "as if" it were like that. Real prototype implementations
>>> (for gcc and clang - I don't know about other tools) are extremely
>>> efficient at handling #embed. And the comma-separated numbers can be
>>> more flexible in less common use-cases.
>> [...]
>>
>> I'm aware of a proposed implementation for clang:
>>
>> https://github.com/llvm/llvm-project/pull/68620
>> https://github.com/ThePhD/llvm-project
>>
>> I'm currently cloning the git repo, with the aim of building it so I can
>> try it out and test some corner cases. It will take a while.
>>
>> I'm not aware of any prototype implementation for gcc. If you are, I'd
>> be very interested in trying it out.
>>
>> (And thanks for starting this thread!)
>
> I've built this from source, and it mostly works. I haven't seen it do
> any optimization; the `#embed` directive expands to a sequence of
> comma-separated integer constants.
>
> Which means that this:
>
> #include <stdio.h>
> int main(void) {
> struct foo {
> unsigned char a;
> unsigned short b;
> unsigned int c;
> double d;
> };
> struct foo obj = {
> #embed "foo.dat"
> };
> printf("a=%d b=%d c=%d d=%f\n", obj.a, obj.b, obj.c, obj.d);
> }
>
> given "foo.dat" containing bytes with values 1, 2, 3, and 4, produces
> this output:
>
> a=1 b=2 c=3 d=4.000000
>
That is what you would expect by the way #embed is specified. You would
not expect to see any "optimisation", since optimisations should not
change the results (apparent from choosing between alternative valid
results).
Where you will see the optimisation difference is between :
const int xs[] = {
#embed "x.dat"
};
and
const int xs[] = {
#include "x.csv"
};
where "x.dat" is a large binary file, and "x.csv" is the same data as
comma-separated values. The #embed version will compile very much
faster, using far less memory. /That/ is the optimisation.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-05-25 15:58 -0700 |
| Message-ID | <87ikz11osy.fsf@nosuchdomain.example.com> |
| In reply to | #385045 |
David Brown <david.brown@hesbynett.no> writes:
> On 25/05/2024 03:29, Keith Thompson wrote:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> On 23/05/2024 14:11, bart wrote:
>>> [...]
>>>>> 'embed' was discussed a few months ago. I disagreed with the poor
>>>>> way it was to be implemented: 'embed' notionally generates a list of
>>>>> comma-separated numbers as tokens, where you have to take care of
>>>>> any trailing zero yourself if needed. It would also be hopelessly
>>>>> inefficient if actually implemented like that.
>>>>
>>>> Fortunately, it is /not/ actually implemented like that - it is only
>>>> implemented "as if" it were like that. Real prototype implementations
>>>> (for gcc and clang - I don't know about other tools) are extremely
>>>> efficient at handling #embed. And the comma-separated numbers can be
>>>> more flexible in less common use-cases.
>>> [...]
>>>
>>> I'm aware of a proposed implementation for clang:
>>>
>>> https://github.com/llvm/llvm-project/pull/68620
>>> https://github.com/ThePhD/llvm-project
>>>
>>> I'm currently cloning the git repo, with the aim of building it so I can
>>> try it out and test some corner cases. It will take a while.
>>>
>>> I'm not aware of any prototype implementation for gcc. If you are, I'd
>>> be very interested in trying it out.
>>>
>>> (And thanks for starting this thread!)
>> I've built this from source, and it mostly works. I haven't seen it
>> do
>> any optimization; the `#embed` directive expands to a sequence of
>> comma-separated integer constants.
>> Which means that this:
>> #include <stdio.h>
>> int main(void) {
>> struct foo {
>> unsigned char a;
>> unsigned short b;
>> unsigned int c;
>> double d;
>> };
>> struct foo obj = {
>> #embed "foo.dat"
>> };
>> printf("a=%d b=%d c=%d d=%f\n", obj.a, obj.b, obj.c, obj.d);
>> }
>> given "foo.dat" containing bytes with values 1, 2, 3, and 4,
>> produces
>> this output:
>> a=1 b=2 c=3 d=4.000000
>
> That is what you would expect by the way #embed is specified. You
> would not expect to see any "optimisation", since optimisations should
> not change the results (apparent from choosing between alternative
> valid results).
>
> Where you will see the optimisation difference is between :
>
> const int xs[] = {
> #embed "x.dat"
> };
>
> and
>
> const int xs[] = {
> #include "x.csv"
> };
>
>
> where "x.dat" is a large binary file, and "x.csv" is the same data as
> comma-separated values. The #embed version will compile very much
> faster, using far less memory. /That/ is the optimisation.
Why would it compile faster? #embed expands to something similar to
CSV, which still has to be parsed.
Reference: <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf>
6.10.4.
The first one will probably initialize each int element of xs to a
single byte value extracted from x.dat. Is that what you intended?
#embed works best with arrays of unsigned char.
If you mean that the #embed will expand to something other than the
sequence of integer constants, how does it know to do that in this
context?
If you have a binary file containing a sequence of int values, you can
use #embed to initialize an unsigned char array that's aliased with or
copied to the int array.
The *embed element width* is typically going to be CHAR_BIT bits by
default. It can only be changed by an *implementation-defined* embed
parameter. It seems odd that there's no standard way to specify the
element width.
It seems even more odd that the embed element width is
implementation defined and not set to CHAR_BIT by default.
A conforming implementation could set the embed element width to,
say, 4*CHAR_BIT and then not provide an implementation-defined embed
parameter to specify a different width, making #embed unusable for
unsigned char arrays. (N3220 is a draft, not the final C23 standard,
but I haven't heard about any changes in this area.)
The kind of optimization I was thinking about was having #embed, in some
cases, expand to something other than the specified sequence of
comma-separated integer constants. Such an optimization would be
intended to improve compile-time speed and memory usage, not run-time
performance.
With a straightforward implementation, the preprocessor has to generate
a sequence of integer constants as text, and then later compiler phases
have to parse that text sequence and generate the corresponding code.
Given:
const unsigned char data[4] = {
#embed "four_bytes.dat"
}
That 4 byte data file is translated to something like "1, 2, 3, 4", then
converted into a stream of tokens, then those tokens are parsed, then,
given the context, the original 4-byte sequence is written into the
generated object file.
For a very large file, that could be a significant burden. (I don't
have any numbers on that.)
An optimized version might have the preprocessor generate some
compiler-specific binary output, say something like "@rawdata N"
followed by N bytes of raw data. Later compiler phases recognize the
"@rawdata" construct and directly dump the data into the object file in
the right place. Making #embed generate @rawdata is only part of the
solution; the compiler has to implement @rawdata in a way that allows it
to be used inside an initializer, or perhaps in any other appropriate
context.
This could be substantially more efficient for something like:
static const unsigned char data[] = {
#embed "bigfile.dat"
};
Of course it wouldn't handle my test case above. But #embed can take
parameters, so it could generate the standard sequence by default and
"@rawdata" if you ask for it.
I don't know whether this kind of optimization is worthwhile, i.e.,
whether the straightforward implementation really imposes significant
commpile-time performance penalties that @rawdata or equivalent can
solve. I also don't know whether existing implementations will
implement this kind of optimization (so far they haven't implemented
#embed at all).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-05-26 13:09 +0200 |
| Message-ID | <v2v59g$3cr0f$1@dont-email.me> |
| In reply to | #385078 |
On 26/05/2024 00:58, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 25/05/2024 03:29, Keith Thompson wrote:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>> On 23/05/2024 14:11, bart wrote:
>>>> [...]
>>>>>> 'embed' was discussed a few months ago. I disagreed with the poor
>>>>>> way it was to be implemented: 'embed' notionally generates a list of
>>>>>> comma-separated numbers as tokens, where you have to take care of
>>>>>> any trailing zero yourself if needed. It would also be hopelessly
>>>>>> inefficient if actually implemented like that.
>>>>>
>>>>> Fortunately, it is /not/ actually implemented like that - it is only
>>>>> implemented "as if" it were like that. Real prototype implementations
>>>>> (for gcc and clang - I don't know about other tools) are extremely
>>>>> efficient at handling #embed. And the comma-separated numbers can be
>>>>> more flexible in less common use-cases.
>>>> [...]
>>>>
>>>> I'm aware of a proposed implementation for clang:
>>>>
>>>> https://github.com/llvm/llvm-project/pull/68620
>>>> https://github.com/ThePhD/llvm-project
>>>>
>>>> I'm currently cloning the git repo, with the aim of building it so I can
>>>> try it out and test some corner cases. It will take a while.
>>>>
>>>> I'm not aware of any prototype implementation for gcc. If you are, I'd
>>>> be very interested in trying it out.
>>>>
>>>> (And thanks for starting this thread!)
>>> I've built this from source, and it mostly works. I haven't seen it
>>> do
>>> any optimization; the `#embed` directive expands to a sequence of
>>> comma-separated integer constants.
>>> Which means that this:
>>> #include <stdio.h>
>>> int main(void) {
>>> struct foo {
>>> unsigned char a;
>>> unsigned short b;
>>> unsigned int c;
>>> double d;
>>> };
>>> struct foo obj = {
>>> #embed "foo.dat"
>>> };
>>> printf("a=%d b=%d c=%d d=%f\n", obj.a, obj.b, obj.c, obj.d);
>>> }
>>> given "foo.dat" containing bytes with values 1, 2, 3, and 4,
>>> produces
>>> this output:
>>> a=1 b=2 c=3 d=4.000000
>>
>> That is what you would expect by the way #embed is specified. You
>> would not expect to see any "optimisation", since optimisations should
>> not change the results (apparent from choosing between alternative
>> valid results).
>>
>> Where you will see the optimisation difference is between :
>>
>> const int xs[] = {
>> #embed "x.dat"
>> };
>>
>> and
>>
>> const int xs[] = {
>> #include "x.csv"
>> };
>>
>>
>> where "x.dat" is a large binary file, and "x.csv" is the same data as
>> comma-separated values. The #embed version will compile very much
>> faster, using far less memory. /That/ is the optimisation.
>
> Why would it compile faster? #embed expands to something similar to
> CSV, which still has to be parsed.
No, it does /not/. That's the /whole/ point of #embed, and the main
motivation for its existence. People have always managed to embed
binary source files into their binary output files - using linker
tricks, or using xxd or other tools (common or specialised) to turn
binary files into initialisers for constant arrays (or structs). I've
done so myself on many projects, all integrated together in makefiles.
#embed has two purposes. One is to save you from using external tools
for that kind of thing. The other is to do it more efficiently for big
files.
There are two ways this is done for examples like this. One is that is
that the compiler does /not/ turn each byte into a series of ASCII
digits for the number, then parse that number to get back to a byte. It
jumps straight from byte in to byte out, possibly after expanding to a
bigger type size if necessary. Secondly, compilers typically track lots
more information about each initialiser - such as the file, line and
column number so that it can give you helpful messages if there is a
value out of range, or too many or too few initialisers. With #embed,
the compiler doesn't have to do any of that.
The compiler will generate results /as if/ it had expanded the file to a
list of numbers and parsed them. But it will not do that in practice.
(At least, not for more serious implementations - simple solutions might
do so to get support implemented quickly.)
>
> Reference: <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf>
> 6.10.4.
>
> The first one will probably initialize each int element of xs to a
> single byte value extracted from x.dat. Is that what you intended?
Yes, if that's what the programmer wrote - though I agree that character
types will be more common and will be the prime target for optimisation.
> #embed works best with arrays of unsigned char.
Sure, that will be a very common use.
>
> If you mean that the #embed will expand to something other than the
> sequence of integer constants, how does it know to do that in this
> context?
It knows because the compiler writers are actually quite smart. The C
standards may describe the translation process in a series of distinct
and independent phases, but that's not how it is done in practice. The
key point is that the compiler knows how the sequence of integers is
going to be used before it gets that far in the preprocessing.
I'd expect implementations to have extremely fast implementations for
initialising arrays of character types, and probably also for other
arrays of scaler types. More complicated examples - such as parameters
in a macro or function call - would probably use a fall-back of
generating naïve lists of integer constants.
>
> If you have a binary file containing a sequence of int values, you can
> use #embed to initialize an unsigned char array that's aliased with or
> copied to the int array.
>
> The *embed element width* is typically going to be CHAR_BIT bits by
> default. It can only be changed by an *implementation-defined* embed
> parameter. It seems odd that there's no standard way to specify the
> element width.
>
> It seems even more odd that the embed element width is
> implementation defined and not set to CHAR_BIT by default.
I agree. But it may be left flexible for situations where the host and
target have different ideas about CHAR_BIT. (Targets with CHAR_BIT
other than 8 are very rare, hosts with CHAR_BIT other than 8 are
non-existent, but C remains flexible.)
> A conforming implementation could set the embed element width to,
> say, 4*CHAR_BIT and then not provide an implementation-defined embed
> parameter to specify a different width, making #embed unusable for
> unsigned char arrays. (N3220 is a draft, not the final C23 standard,
> but I haven't heard about any changes in this area.)
>
> The kind of optimization I was thinking about was having #embed, in some
> cases, expand to something other than the specified sequence of
> comma-separated integer constants. Such an optimization would be
> intended to improve compile-time speed and memory usage, not run-time
> performance.
>
> With a straightforward implementation, the preprocessor has to generate
> a sequence of integer constants as text, and then later compiler phases
> have to parse that text sequence and generate the corresponding code.
>
> Given:
>
> const unsigned char data[4] = {
> #embed "four_bytes.dat"
> }
>
> That 4 byte data file is translated to something like "1, 2, 3, 4", then
> converted into a stream of tokens, then those tokens are parsed, then,
> given the context, the original 4-byte sequence is written into the
> generated object file.
>
> For a very large file, that could be a significant burden. (I don't
> have any numbers on that.)
I do :
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3017.htm#design-efficiency-metrics>
(That's from a proposal for #embed for C and C++. Generating the
numbers and parsing them is akin to using xxd.)
More useful links:
<https://thephd.dev/embed-the-details#results>
<https://thephd.dev/implementing-embed-c-and-c++>
(These are from someone who did a lot of the work for the proposals, and
prototype implementations, as far as I understand it.)
Note that I can't say how much of a difference this will make in real
life. I don't know how often people need to include multi-megabyte
files in their code. It certainly is not at a level where I would
change any of my existing projects from external generator scripts to
using #embed, but I might use it in future projects.
>
> An optimized version might have the preprocessor generate some
> compiler-specific binary output, say something like "@rawdata N"
> followed by N bytes of raw data. Later compiler phases recognize the
> "@rawdata" construct and directly dump the data into the object file in
> the right place. Making #embed generate @rawdata is only part of the
> solution; the compiler has to implement @rawdata in a way that allows it
> to be used inside an initializer, or perhaps in any other appropriate
> context.
That's the idea. In theory, C pre-processors and C compilers are
independent programs with a standardised format between them - in
practice, they are often part of the same binary, and almost invariably
come from the same developers. The "cpp" program may have to generate
standard preprocessed output, and the "cc" program may have to accept
standard preprocessed output, but there is nothing to stop the pair of
programs supporting extended formats that are more efficient.
>
> This could be substantially more efficient for something like:
>
> static const unsigned char data[] = {
> #embed "bigfile.dat"
> };
>
> Of course it wouldn't handle my test case above. But #embed can take
> parameters, so it could generate the standard sequence by default and
> "@rawdata" if you ask for it.
>
> I don't know whether this kind of optimization is worthwhile, i.e.,
> whether the straightforward implementation really imposes significant
> commpile-time performance penalties that @rawdata or equivalent can
> solve. I also don't know whether existing implementations will
> implement this kind of optimization (so far they haven't implemented
> #embed at all).
>
Prototypes have been made, and they do have such optimisations. How
things end up in real tools remains to be seen, of course.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-05-26 12:51 +0100 |
| Message-ID | <v2v7ni$3d70v$1@dont-email.me> |
| In reply to | #385092 |
On 26/05/2024 12:09, David Brown wrote:
> On 26/05/2024 00:58, Keith Thompson wrote:
>> For a very large file, that could be a significant burden. (I don't
>> have any numbers on that.)
>
> I do :
>
> <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3017.htm#design-efficiency-metrics>
>
> (That's from a proposal for #embed for C and C++. Generating the
> numbers and parsing them is akin to using xxd.)
>
> More useful links:
>
> <https://thephd.dev/embed-the-details#results>
> <https://thephd.dev/implementing-embed-c-and-c++>
>
> (These are from someone who did a lot of the work for the proposals, and
> prototype implementations, as far as I understand it.)
>
>
>
> Note that I can't say how much of a difference this will make in real
> life. I don't know how often people need to include multi-megabyte
> files in their code. It certainly is not at a level where I would
> change any of my existing projects from external generator scripts to
> using #embed, but I might use it in future projects.
I've just done my own quick test (not in C, using embed in my language):
[]byte clangexe = binclude("f:/llvm/bin/clang.exe")
proc main=
fprintln "clang.exe is # bytes", clangexe.len
end
This embeds the Clang C compiler which is 119MB. It took 1.3 seconds to
compile (note my compiler is not optimised).
If I tried it using text: a 121M-line include file, with one number per
line, it took 144 seconds (I believe it used more RAM than was
available: each line will have occupied a 64-byte AST node, so nearly
8GB, on a machine with only 6GB available RAM, much of which was occupied).
The figures at your link say it took 1 second for a 40MB test file, on
an Intel i7 with 24GB.
My compiler took just over 1.3 seconds (now annoyingly taking 1.4
seconds for a retest) for a file nearly 3 times bigger, on a much more
lowly machine (second cheapest PC in the shop), with 8GB.
So my implementation sounds faster. Of course, those 120M data bytes
haven't been optimised!
As for usage, this would be a tidy way of bundling a program like a C
compiler if your program required it, although there are a number of
alternatives in that case: the binary here doesn't need to exist in the
application's data space.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-05-26 16:18 +0300 |
| Message-ID | <20240526161832.000012a6@yahoo.com> |
| In reply to | #385095 |
On Sun, 26 May 2024 12:51:12 +0100
bart <bc@freeuk.com> wrote:
> On 26/05/2024 12:09, David Brown wrote:
> > On 26/05/2024 00:58, Keith Thompson wrote:
>
> >> For a very large file, that could be a significant burden. (I
> >> don't have any numbers on that.)
> >
> > I do :
> >
> > <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3017.htm#design-efficiency-metrics>
> >
> > (That's from a proposal for #embed for C and C++. Generating the
> > numbers and parsing them is akin to using xxd.)
> >
> > More useful links:
> >
> > <https://thephd.dev/embed-the-details#results>
> > <https://thephd.dev/implementing-embed-c-and-c++>
> >
> > (These are from someone who did a lot of the work for the
> > proposals, and prototype implementations, as far as I understand
> > it.)
> >
> >
> >
> > Note that I can't say how much of a difference this will make in
> > real life. I don't know how often people need to include
> > multi-megabyte files in their code. It certainly is not at a level
> > where I would change any of my existing projects from external
> > generator scripts to using #embed, but I might use it in future
> > projects.
>
> I've just done my own quick test (not in C, using embed in my
> language):
>
> []byte clangexe = binclude("f:/llvm/bin/clang.exe")
>
> proc main=
> fprintln "clang.exe is # bytes", clangexe.len
> end
>
>
> This embeds the Clang C compiler which is 119MB. It took 1.3 seconds
> to compile (note my compiler is not optimised).
>
> If I tried it using text: a 121M-line include file, with one number
> per line, it took 144 seconds (I believe it used more RAM than was
> available: each line will have occupied a 64-byte AST node, so nearly
> 8GB, on a machine with only 6GB available RAM, much of which was
> occupied).
On my old PC that was not the cheapest box in the shop, but is more than
10 y.o. compilation speed for similarly organized (but much smaller)
text files is as following:
MSVC 18.00.31101 (VS 2013) - 1950 KB/sec
MSVC 19.16.27032 (VS 2017) - 1180 KB/sec
MSVC 19.20.27500 (VS 2019) - 1180 KB/sec
clang 17.0.6 - 547 KB/sec (somewhat better with hex text)
gcc 13.2.0 - 580 KB/sec
So, MSVC compilers, esp. an old one, are somewhat faster than yours.
But if there was swapping involved it's not comparable. How much time
does it take for your compiler to produce 5MB byte array from text?
>
> The figures at your link say it took 1 second for a 40MB test file,
> on an Intel i7 with 24GB.
>
> My compiler took just over 1.3 seconds (now annoyingly taking 1.4
> seconds for a retest) for a file nearly 3 times bigger, on a much
> more lowly machine (second cheapest PC in the shop), with 8GB.
>
> So my implementation sounds faster. Of course, those 120M data bytes
> haven't been optimised!
>
But both are much faster than compiling through text. Even "slow"
40MB/3 is 6-7 times faster than the fastest of compilers in my tests.
> As for usage, this would be a tidy way of bundling a program like a C
> compiler if your program required it, although there are a number of
> alternatives in that case: the binary here doesn't need to exist in
> the application's data space.
>
[toc] | [prev] | [next] | [standalone]
Page 2 of 28 — ← Prev page 1 [2] 3 4 … 28 Next page →
Back to top | Article view | comp.lang.c
csiph-web