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 8 of 28 — ← Prev page 1 … 6 7 [8] 9 10 … 28 Next page →
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-06-01 01:45 +0000 |
| Message-ID | <v3duge$2febh$4@dont-email.me> |
| In reply to | #385298 |
On Thu, 30 May 2024 11:09:05 +0300, Michael S wrote: > On Thu, 30 May 2024 02:32:03 -0000 (UTC) > Lawrence D'Oliveiro <ldo@nz.invalid> wrote: > >> On Wed, 29 May 2024 13:58:20 +0200, Bonita Montero wrote: >> >> > I've got a small commandline-tool that makes a const'd char -array >> > from any binary file. >> >> It seems to me it would be more efficient to use objcopy to turn that >> binary file directly into an object file with symbols accessible from C >> code defining its beginning and ending points. Then just link it into >> the executable. > > Of course, it is more efficient. > But: > - it covers fewer use cases. There are many ways of embedding a binary blob in a software project. This is just one tool for that; there are other tools for other cases (see the Unicode Browser for Android example that I mentioned elsewhere). > - it exposes array's name and size as global symbols which is not > always desirable Lots of other things already need to be global symbols, I don’t see why a couple more make a difference to anything. Look at how large projects like the Linux kernel deal with this sort of thing. > - it feels too much like a magic. It would feel less like a magic if > done by compiler rather than by extra tool. Even better if done by > compiler in standardized manner. I don’t understand this at all. I never had the assumption, in any real- world build system, that all the generated code had to come from some “official” compiler for some “official” language.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-05-30 14:34 +0100 |
| Message-ID | <v39v87$1n7bk$1@dont-email.me> |
| In reply to | #385292 |
On 30/05/2024 03:32, Lawrence D'Oliveiro wrote:
> On Wed, 29 May 2024 13:58:20 +0200, Bonita Montero wrote:
>
>> I've got a small commandline-tool that makes a const'd char
>> -array from any binary file.
>
> It seems to me it would be more efficient to use objcopy to turn that
> binary file directly into an object file with symbols accessible from C
> code defining its beginning and ending points. Then just link it into the
> executable.
None of my compilers, whether for C or anything else, generate object files.
However, suppose I wanted to link a file called 'logo.bmp' say, into my
program, which consisted of a file called main.c.
What is the entire process using your suggestion? What do I put into
main.c? Assume the data is represented by a char-array.
In my language, it would simply be this:
[]byte logobmp = binclude("logo.bmp")
Using my C extension, it might be this:
uint8_t logobmp[] = strinclude("logo.bmp");
(I believe this will cope with embedded zeros, and the file size is
obtainable with 'sizeof(logobmp)'.
With the new feature it might be this (I forget the exact syntax):
uint8_t logobmp[] = {
#embed "logo.bmp"
};
Nothing else is needed; just compile as normal.
The point of the feature is avoid the palavar with 'objcopy', which is a
utility with 100 different options, or messing with ones like xxd.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-05-30 17:08 +0300 |
| Message-ID | <20240530170836.00005fa0@yahoo.com> |
| In reply to | #385312 |
On Thu, 30 May 2024 14:34:00 +0100 bart <bc@freeuk.com> wrote: > On 30/05/2024 03:32, Lawrence D'Oliveiro wrote: > > On Wed, 29 May 2024 13:58:20 +0200, Bonita Montero wrote: > > > >> I've got a small commandline-tool that makes a const'd char > >> -array from any binary file. > > > > It seems to me it would be more efficient to use objcopy to turn > > that binary file directly into an object file with symbols > > accessible from C code defining its beginning and ending points. > > Then just link it into the executable. > > None of my compilers, whether for C or anything else, generate object > files. > > However, suppose I wanted to link a file called 'logo.bmp' say, into > my program, which consisted of a file called main.c. > > What is the entire process using your suggestion? What do I put into > main.c? Assume the data is represented by a char-array. > extern unsigned char _binary_logo_bmp_start[]; extern unsigned char _binary_logo_bmp_size[]; The first symbol is an array itself. The seconded symbol contains the length of array. You use it in somewhat non-intuitive way: size_t my_size = (size_t)_binary_logo_bmp_size; Pay attention that I never used this method myself, just took a look at the output of objcopy with 'objdump -t', so please don't take my words as a sure thing. BTW, options in this case are rather simple: objcopy -I binary -O elf32-little logo.bmp logo_bmp.o Replace elf32-little with relevant format for your software. However I am not sure that it would work for none-elf output formats. This command puts the variable into the section .data. If one wants it in the different section, e.g. .rwdata then the thing could indeed become less obvious.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-05-30 15:48 +0100 |
| Message-ID | <v3a3k5$1ntrn$1@dont-email.me> |
| In reply to | #385313 |
On 30/05/2024 15:08, Michael S wrote: > On Thu, 30 May 2024 14:34:00 +0100 > bart <bc@freeuk.com> wrote: > >> On 30/05/2024 03:32, Lawrence D'Oliveiro wrote: >>> On Wed, 29 May 2024 13:58:20 +0200, Bonita Montero wrote: >>> >>>> I've got a small commandline-tool that makes a const'd char >>>> -array from any binary file. >>> >>> It seems to me it would be more efficient to use objcopy to turn >>> that binary file directly into an object file with symbols >>> accessible from C code defining its beginning and ending points. >>> Then just link it into the executable. >> >> None of my compilers, whether for C or anything else, generate object >> files. >> >> However, suppose I wanted to link a file called 'logo.bmp' say, into >> my program, which consisted of a file called main.c. >> >> What is the entire process using your suggestion? What do I put into >> main.c? Assume the data is represented by a char-array. >> > > extern unsigned char _binary_logo_bmp_start[]; > extern unsigned char _binary_logo_bmp_size[]; > > The first symbol is an array itself. > The seconded symbol contains the length of array. You use it in somewhat > non-intuitive way: > size_t my_size = (size_t)_binary_logo_bmp_size; > > Pay attention that I never used this method myself, just took a look at > the output of objcopy with 'objdump -t', so please don't take my words > as a sure thing. > > BTW, options in this case are rather simple: > objcopy -I binary -O elf32-little logo.bmp logo_bmp.o Where do the _binary_logo_bmp_start and ...-size symbols come from? That is, how do they get into the object file. > Replace elf32-little with relevant format for your software. However I > am not sure that it would work for none-elf output formats. There appears to be an objcopy utility that runs under Windows.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-05-30 18:03 +0300 |
| Message-ID | <20240530180345.00003d9f@yahoo.com> |
| In reply to | #385315 |
On Thu, 30 May 2024 15:48:39 +0100 bart <bc@freeuk.com> wrote: > > Where do the _binary_logo_bmp_start and ...-size symbols come from? > That is, how do they get into the object file. > objcopy generates names of the symbols from the name of input binary file. I would think that it is possible to change these symbols to something else, but I am not sure that it is possible withing the same invocation of objcopy. It certainly is possible with a second pass. Lawrence probably can give more authoritative answer. Or as a last resort you can RTFM.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-05-31 13:55 +0100 |
| Message-ID | <v3chc4$27uij$1@dont-email.me> |
| In reply to | #385318 |
On 30/05/2024 16:03, Michael S wrote:
> On Thu, 30 May 2024 15:48:39 +0100
> bart <bc@freeuk.com> wrote:
>
>>
>> Where do the _binary_logo_bmp_start and ...-size symbols come from?
>> That is, how do they get into the object file.
>>
>
> objcopy generates names of the symbols from the name of input binary
> file. I would think that it is possible to change these symbols to
> something else, but I am not sure that it is possible withing the same
> invocation of objcopy. It certainly is possible with a second pass.
> Lawrence probably can give more authoritative answer.
> Or as a last resort you can RTFM.
>
I gave myself the simple task of incorporating the source text of
hello.c into a program, and printing it out.
My C program looked like this to start, as an initial test (ignoring
declaring the size as an array, unless I had to):
#include <stdio.h>
typedef unsigned char byte;
extern byte _binary_hello_c_start[];
extern int _binary_hello_c_size;
int main(void) {
printf("%d\n", _binary_hello_c_size);
}
One small matter is those ugly, long identifiers. A bigger one in this
case is that I really want that embedded text to be zero terminated;
here it's unlikely to be.
However I still have to create the object file with the data. I tried this:
objcopy -I binary -O pe-x86-64 hello.c hello.obj
The contents looked about right when I looked inside.
Now to build my program. Because my C compiler can't link object files
itself, I have to get it to generate an object file for the program,
then use an external linker:
C:\c>mcc -c c.c
Compiling c.c to c.obj
C:\c>gcc c.obj hello.obj
hello.obj: file not recognized: file format not recognized
collect2.exe: error: ld returned 1 exit status
Unfortunately gcc/ld doesn't recognise the output of objcopy. Even
though it accepts the output of mcc which is the same COFF format.
But even if it worked, you can see it would be a bit of a palaver.
Here's how builtin embedding worked using a feature of my older C compiler:
#include <stdio.h>
#include <string.h>
char hello[] = strinclude("hello.c");
int main(void) {
printf("hello =\n%s\n", hello);
printf("strlen(hello) = %zu\n", strlen(hello));
printf("sizeof(hello) = %zu\n", sizeof(hello));
}
I build it and run it like this:
C:\c>bcc c
Compiling c.c to c.exe
C:\c>c
hello =
#include "stdio.h"
int main(void) {
printf("Hello, World!\n");
}
strlen(hello) = 70
sizeof(hello) = 71
C:\c>dir hello.c
31/05/2024 13:48 70 hello.c
It just works; no messing about with objcopy parameters; no long
unwieldy names; no link errors due to unsupported file formats; no
problems with missing terminators for embedded text files imported as
strings; no funny ways of getting size info.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-05-31 16:19 +0300 |
| Message-ID | <20240531161937.000063af@yahoo.com> |
| In reply to | #385351 |
On Fri, 31 May 2024 13:55:33 +0100
bart <bc@freeuk.com> wrote:
> On 30/05/2024 16:03, Michael S wrote:
> > On Thu, 30 May 2024 15:48:39 +0100
> > bart <bc@freeuk.com> wrote:
> >
> >>
> >> Where do the _binary_logo_bmp_start and ...-size symbols come from?
> >> That is, how do they get into the object file.
> >>
> >
> > objcopy generates names of the symbols from the name of input binary
> > file. I would think that it is possible to change these symbols to
> > something else, but I am not sure that it is possible withing the
> > same invocation of objcopy. It certainly is possible with a second
> > pass. Lawrence probably can give more authoritative answer.
> > Or as a last resort you can RTFM.
> >
> I gave myself the simple task of incorporating the source text of
> hello.c into a program, and printing it out.
>
> My C program looked like this to start, as an initial test (ignoring
> declaring the size as an array, unless I had to):
>
> #include <stdio.h>
> typedef unsigned char byte;
>
> extern byte _binary_hello_c_start[];
> extern int _binary_hello_c_size;
>
> int main(void) {
> printf("%d\n", _binary_hello_c_size);
> }
>
No, it does not work like that.
First, copy *exactly* what I said in my previous post.
Only after you reproduced, start to be smart.
_binary_hello_c_size is a link simbol rather than variable.
Declaration:
extern char _binary_hello_c_size[];
Usage:
printf("%zd\n", (size_t)_binary_hello_c_size);
> One small matter is those ugly, long identifiers. A bigger one in
> this case is that I really want that embedded text to be zero
> terminated; here it's unlikely to be.
>
The tool is not made specifically for ASCII strings, it is more generic.
I don't want it zero-terminated, the same as I don't want output of
fread() zero-terminated. I want it exactly like it is in the
input file.
> However I still have to create the object file with the data. I tried
> this:
>
> objcopy -I binary -O pe-x86-64 hello.c hello.obj
>
> The contents looked about right when I looked inside.
>
> Now to build my program. Because my C compiler can't link object
> files itself, I have to get it to generate an object file for the
> program, then use an external linker:
>
> C:\c>mcc -c c.c
> Compiling c.c to c.obj
>
> C:\c>gcc c.obj hello.obj
> hello.obj: file not recognized: file format not recognized
> collect2.exe: error: ld returned 1 exit status
>
> Unfortunately gcc/ld doesn't recognise the output of objcopy. Even
> though it accepts the output of mcc which is the same COFF format.
>
It recognizes it if lye to objcopy about format.
Specify elf64-x86-64 instead of pe-x86-64 and everything suddenly
works.
It's all was said in my posts from yesterday. It does not sound like you
had read them.
> But even if it worked, you can see it would be a bit of a palaver.
>
> Here's how builtin embedding worked using a feature of my older C
> compiler:
>
> #include <stdio.h>
> #include <string.h>
>
> char hello[] = strinclude("hello.c");
>
> int main(void) {
> printf("hello =\n%s\n", hello);
> printf("strlen(hello) = %zu\n", strlen(hello));
> printf("sizeof(hello) = %zu\n", sizeof(hello));
> }
>
>
> I build it and run it like this:
>
> C:\c>bcc c
> Compiling c.c to c.exe
>
> C:\c>c
> hello =
> #include "stdio.h"
>
> int main(void) {
> printf("Hello, World!\n");
> }
>
> strlen(hello) = 70
> sizeof(hello) = 71
>
> C:\c>dir hello.c
> 31/05/2024 13:48 70 hello.c
>
>
> It just works; no messing about with objcopy parameters; no long
> unwieldy names; no link errors due to unsupported file formats; no
> problems with missing terminators for embedded text files imported as
> strings; no funny ways of getting size info.
>
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-05-31 16:28 +0300 |
| Message-ID | <20240531162811.00006719@yahoo.com> |
| In reply to | #385352 |
On Fri, 31 May 2024 16:19:37 +0300
Michael S <already5chosen@yahoo.com> wrote:
>
> No, it does not work like that.
> First, copy *exactly* what I said in my previous post.
> Only after you reproduced, start to be smart.
> _binary_hello_c_size is a link simbol rather than variable.
>
> Declaration:
> extern char _binary_hello_c_size[];
>
> Usage:
> printf("%zd\n", (size_t)_binary_hello_c_size);
>
Thinking about it, I could be wrong.
I should test more, with less small program.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-05-31 16:48 +0300 |
| Message-ID | <20240531164835.00007128@yahoo.com> |
| In reply to | #385353 |
On Fri, 31 May 2024 16:28:11 +0300
Michael S <already5chosen@yahoo.com> wrote:
> On Fri, 31 May 2024 16:19:37 +0300
> Michael S <already5chosen@yahoo.com> wrote:
>
> >
> > No, it does not work like that.
> > First, copy *exactly* what I said in my previous post.
> > Only after you reproduced, start to be smart.
> > _binary_hello_c_size is a link simbol rather than variable.
> >
> > Declaration:
> > extern char _binary_hello_c_size[];
> >
> > Usage:
> > printf("%zd\n", (size_t)_binary_hello_c_size);
> >
>
> Thinking about it, I could be wrong.
> I should test more, with less small program.
>
I tested with bigger program, and it's still works.
So, what written above is correct.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-05-31 15:04 +0100 |
| Message-ID | <v3cldt$28n91$2@dont-email.me> |
| In reply to | #385357 |
On 31/05/2024 14:48, Michael S wrote:
> On Fri, 31 May 2024 16:28:11 +0300
> Michael S <already5chosen@yahoo.com> wrote:
>
>> On Fri, 31 May 2024 16:19:37 +0300
>> Michael S <already5chosen@yahoo.com> wrote:
>>
>>>
>>> No, it does not work like that.
>>> First, copy *exactly* what I said in my previous post.
>>> Only after you reproduced, start to be smart.
>>> _binary_hello_c_size is a link simbol rather than variable.
>>>
>>> Declaration:
>>> extern char _binary_hello_c_size[];
>>>
>>> Usage:
>>> printf("%zd\n", (size_t)_binary_hello_c_size);
>>>
>>
>> Thinking about it, I could be wrong.
>> I should test more, with less small program.
>>
>
> I tested with bigger program, and it's still works.
> So, what written above is correct.
>
Can you show the full program and the full process?
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-05-31 17:34 +0300 |
| Message-ID | <20240531173437.00003bee@yahoo.com> |
| In reply to | #385359 |
On Fri, 31 May 2024 15:04:46 +0100
bart <bc@freeuk.com> wrote:
> On 31/05/2024 14:48, Michael S wrote:
> > On Fri, 31 May 2024 16:28:11 +0300
> > Michael S <already5chosen@yahoo.com> wrote:
> >
> >> On Fri, 31 May 2024 16:19:37 +0300
> >> Michael S <already5chosen@yahoo.com> wrote:
> >>
> >>>
> >>> No, it does not work like that.
> >>> First, copy *exactly* what I said in my previous post.
> >>> Only after you reproduced, start to be smart.
> >>> _binary_hello_c_size is a link simbol rather than variable.
> >>>
> >>> Declaration:
> >>> extern char _binary_hello_c_size[];
> >>>
> >>> Usage:
> >>> printf("%zd\n", (size_t)_binary_hello_c_size);
> >>>
> >>
> >> Thinking about it, I could be wrong.
> >> I should test more, with less small program.
> >>
> >
> > I tested with bigger program, and it's still works.
> > So, what written above is correct.
> >
>
> Can you show the full program and the full process?
test_objcopy.c:
#include <stdio.h>
int data1[42] = { 1,2,3 ,4,5};
extern unsigned char _binary_test_bi_start[];
extern unsigned char _binary_test_bi_end[];
extern unsigned char _binary_test_bi_size[];
extern unsigned char _binary_bin_to_list_c_start[];
extern unsigned char _binary_bin_to_list_c_end[];
extern unsigned char _binary_bin_to_list_c_size[];
int main()
{
printf("%-40s %p %zd\n", "_binary_test_bi_start",
_binary_test_bi_start, (size_t)_binary_test_bi_start);
printf("%-40s %p %zd\n", "_binary_test_bi_end",
_binary_test_bi_end, (size_t)_binary_test_bi_end);
printf("%-40s %p %zd\n", "_binary_test_bi_size",
_binary_test_bi_size, (size_t)_binary_test_bi_size);
printf("%-40s %p %zd\n", "_binary_bin_to_list_c_start",
_binary_bin_to_list_c_start, (size_t)_binary_bin_to_list_c_start);
printf("%-40s %p %zd\n", "_binary_bin_to_list_c_end",
_binary_bin_to_list_c_end, (size_t)_binary_bin_to_list_c_end);
printf("%-40s %p %zd\n", "_binary_bin_to_list_c_size",
_binary_bin_to_list_c_size, (size_t)_binary_bin_to_list_c_size);
return 0;
}
Test files: test.bi and bin_to_list_c.
Conversion to ojects:
objcopy -I binary -O elf64-x86-64 test.bi test_bi.o
objcopy -I binary -O elf64-x86-64 bin_to_list.c test_c.o
Compilation:
gcc -s -Wall -Oz test_objcopy.c test_bi.o test_c.o
I compiled with additional option -Xlinker -Map=test_objcopy.map
in order to make myself sure tha *_size are indeed pure symbols that
have no memory allocated underneaths.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-05-31 19:03 +0100 |
| Message-ID | <v3d3ct$2b5sl$1@dont-email.me> |
| In reply to | #385361 |
On 31/05/2024 15:34, Michael S wrote:
> On Fri, 31 May 2024 15:04:46 +0100
> bart <bc@freeuk.com> wrote:
>> Can you show the full program and the full process?
>
> test_objcopy.c:
> #include <stdio.h>
>
> int data1[42] = { 1,2,3 ,4,5};
> extern unsigned char _binary_test_bi_start[];
> extern unsigned char _binary_test_bi_end[];
> extern unsigned char _binary_test_bi_size[];
>
> extern unsigned char _binary_bin_to_list_c_start[];
> extern unsigned char _binary_bin_to_list_c_end[];
> extern unsigned char _binary_bin_to_list_c_size[];
>
> int main()
> {
> printf("%-40s %p %zd\n", "_binary_test_bi_start",
> _binary_test_bi_start, (size_t)_binary_test_bi_start);
> printf("%-40s %p %zd\n", "_binary_test_bi_end",
> _binary_test_bi_end, (size_t)_binary_test_bi_end);
> printf("%-40s %p %zd\n", "_binary_test_bi_size",
> _binary_test_bi_size, (size_t)_binary_test_bi_size);
> printf("%-40s %p %zd\n", "_binary_bin_to_list_c_start",
> _binary_bin_to_list_c_start, (size_t)_binary_bin_to_list_c_start);
> printf("%-40s %p %zd\n", "_binary_bin_to_list_c_end",
> _binary_bin_to_list_c_end, (size_t)_binary_bin_to_list_c_end);
> printf("%-40s %p %zd\n", "_binary_bin_to_list_c_size",
> _binary_bin_to_list_c_size, (size_t)_binary_bin_to_list_c_size);
> return 0;
> }
>
> Test files: test.bi and bin_to_list_c.
> Conversion to ojects:
> objcopy -I binary -O elf64-x86-64 test.bi test_bi.o
> objcopy -I binary -O elf64-x86-64 bin_to_list.c test_c.o
>
> Compilation:
> gcc -s -Wall -Oz test_objcopy.c test_bi.o test_c.o
OK, thanks. But I forget to ask what results you got from running the
program. Because if I try your code, using hello.c and hello.exe as test
binary/source data, I get this output:
_binary_test_bi_start 00007ff6497620e0 140695771160800
_binary_test_bi_end 00007ff649762ae0 140695771163360
_binary_test_bi_size 00007ff509750a00 140690402380288
_binary_bin_to_list_c_start 00007ff649762ae0 140695771163360
_binary_bin_to_list_c_end 00007ff649762b26 140695771163430
_binary_bin_to_list_c_size 00007ff509750046 140690402377798
The sizes should have been 2560 and 70 respectively; those values are
bit bigger than that.
However I see that you also have start and end addresses, which sounds a
much better way of determining the size. (In that case, what are those
*size symbols for?).
So I can put together a working test:
---------------------------------
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
extern unsigned char _binary_hello_c_start[];
extern unsigned char _binary_hello_c_end[];
char* makestr(char* start, char* end) {
int length = end-start;
char* s = malloc(length+1);
memcpy(s, start, length);
*(s+length) = 0;
return s;
}
int main() {
char* str = makestr(_binary_hello_c_start, _binary_hello_c_end);
printf("Hello = \n%s", str);
}
---------------------------------
I can build it like this:
---------------------------------
C:\c>mcc -c c
Compiling c.c to c.obj
C:\c>objcopy -I binary -O elf64-x86-64 hello.c hello.obj
C:\c>gcc c.c hello.obj
---------------------------------
And run it like this:
---------------------------------
C:\c>a
Hello =
#include "stdio.h"
int main(void) {
printf("Hello, World!\n");
}
---------------------------------
Instead of one compiler, here I used two compilers, a tool 'objcopy'
(which bizarrely needs to generate ELF format files) and lots of extra
ugly code. I also need to disregard whatever the hell _binary_..._size does.
But it works.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-05-31 18:36 +0000 |
| Message-ID | <yMo6O.3723$zfC8.2197@fx35.iad> |
| In reply to | #385364 |
bart <bc@freeuk.com> writes:
>On 31/05/2024 15:34, Michael S wrote:
>> On Fri, 31 May 2024 15:04:46 +0100
>> bart <bc@freeuk.com> wrote:
>Instead of one compiler, here I used two compilers, a tool 'objcopy'
>(which bizarrely needs to generate ELF format files) and lots of extra
>ugly code. I also need to disregard whatever the hell _binary_..._size does.
$ objcopy -I binary -O elf64-x86-64 main.cpp /tmp/test.o
$ objdump -x /tmp/test.o
/tmp/test.o: file format elf64-little
/tmp/test.o
architecture: UNKNOWN!, flags 0x00000010:
HAS_SYMS
start address 0x0000000000000000
Sections:
Idx Name Size VMA LMA File off Algn
0 .data 000030e2 0000000000000000 0000000000000000 00000040 2**0
CONTENTS, ALLOC, LOAD, DATA
SYMBOL TABLE:
0000000000000000 l d .data 0000000000000000 .data
0000000000000000 g .data 0000000000000000 _binary_main_cpp_start
00000000000030e2 g .data 0000000000000000 _binary_main_cpp_end
00000000000030e2 g *ABS* 0000000000000000 _binary_main_cpp_size
$ ls -l main.cpp
-rw-rw-r--. 1 scott scott 12514 May 9 2022 main.cpp
$ printf '%u\n' $(( 0x30e2 ))
12514
The value of the symbol _binary_main_cpp_size is the
number of bytes in the file.
(in other words,
_binary_main_cpp_size = _binary_main_cpp_end - _binary_main_cpp_start
)
In C code:
extern uint8_t _binary_main_cpp_size;
const size_t embed_size = &_binary_main_cpp_size;
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-05-31 22:15 +0100 |
| Message-ID | <v3dem9$2d2v4$1@dont-email.me> |
| In reply to | #385365 |
On 31/05/2024 19:36, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>> On 31/05/2024 15:34, Michael S wrote:
>>> On Fri, 31 May 2024 15:04:46 +0100
>>> bart <bc@freeuk.com> wrote:
>
>> Instead of one compiler, here I used two compilers, a tool 'objcopy'
>> (which bizarrely needs to generate ELF format files) and lots of extra
>> ugly code. I also need to disregard whatever the hell _binary_..._size does.
>
> $ objcopy -I binary -O elf64-x86-64 main.cpp /tmp/test.o
>
> $ objdump -x /tmp/test.o
>
> /tmp/test.o: file format elf64-little
> /tmp/test.o
> architecture: UNKNOWN!, flags 0x00000010:
> HAS_SYMS
> start address 0x0000000000000000
>
> Sections:
> Idx Name Size VMA LMA File off Algn
> 0 .data 000030e2 0000000000000000 0000000000000000 00000040 2**0
> CONTENTS, ALLOC, LOAD, DATA
> SYMBOL TABLE:
> 0000000000000000 l d .data 0000000000000000 .data
> 0000000000000000 g .data 0000000000000000 _binary_main_cpp_start
> 00000000000030e2 g .data 0000000000000000 _binary_main_cpp_end
> 00000000000030e2 g *ABS* 0000000000000000 _binary_main_cpp_size
>
> $ ls -l main.cpp
> -rw-rw-r--. 1 scott scott 12514 May 9 2022 main.cpp
> $ printf '%u\n' $(( 0x30e2 ))
> 12514
>
> The value of the symbol _binary_main_cpp_size is the
> number of bytes in the file.
>
> (in other words,
>
> _binary_main_cpp_size = _binary_main_cpp_end - _binary_main_cpp_start
>
> )
>
> In C code:
>
> extern uint8_t _binary_main_cpp_size;
>
> const size_t embed_size = &_binary_main_cpp_size;
Did you see the output from my version of Michael S's program? The size
is just an address. If I do what you do:
extern unsigned char _binary_hello_c_size;
....
size_t size = &_binary_hello_c_size;
printf("size: %zu\n", size);
It produces:
size: 140697695027270
Little of this seems to work, sorry. You guys keep saying, do this, do
that, no do it that way, go RTFM, but nobody has shown a complete
program that correctly shows the -size symbol to be giving anything
meaningful.
If I run this:
printf("%p\n", &_binary_hello_c_start);
printf("%p\n", &_binary_hello_c_end);
printf("%p\n", &_binary_hello_c_size);
I get:
00007ff6ef252010
00007ff6ef252056
00007ff5af240046
I can see that the first two can be subtracted to give the sizes of the
data, which is 70 or 0x46. 0x46 is the last byte of the address of
_size, so what's happening there? What's with the crap in bits 16-47?
I can extract the size using:
printf("%d\n", (unsigned short)&_binary_hello_c_size);
But something is not right. I've also asked what is the point of the
-size symbol if you can just do -end - -start, but nobody has explained.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-06-01 01:25 +0000 |
| Message-ID | <TLu6O.6222$xPJ1.816@fx09.iad> |
| In reply to | #385370 |
bart <bc@freeuk.com> writes:
>On 31/05/2024 19:36, Scott Lurndal wrote:
>> bart <bc@freeuk.com> writes:
>>> On 31/05/2024 15:34, Michael S wrote:
>>>> On Fri, 31 May 2024 15:04:46 +0100
>>>> bart <bc@freeuk.com> wrote:
>>
>>> Instead of one compiler, here I used two compilers, a tool 'objcopy'
>>> (which bizarrely needs to generate ELF format files) and lots of extra
>>> ugly code. I also need to disregard whatever the hell _binary_..._size does.
>>
>> $ objcopy -I binary -O elf64-x86-64 main.cpp /tmp/test.o
>>
>> $ objdump -x /tmp/test.o
>>
>> /tmp/test.o: file format elf64-little
>> /tmp/test.o
>> architecture: UNKNOWN!, flags 0x00000010:
>> HAS_SYMS
>> start address 0x0000000000000000
>>
>> Sections:
>> Idx Name Size VMA LMA File off Algn
>> 0 .data 000030e2 0000000000000000 0000000000000000 00000040 2**0
>> CONTENTS, ALLOC, LOAD, DATA
>> SYMBOL TABLE:
>> 0000000000000000 l d .data 0000000000000000 .data
>> 0000000000000000 g .data 0000000000000000 _binary_main_cpp_start
>> 00000000000030e2 g .data 0000000000000000 _binary_main_cpp_end
>> 00000000000030e2 g *ABS* 0000000000000000 _binary_main_cpp_size
>>
>> $ ls -l main.cpp
>> -rw-rw-r--. 1 scott scott 12514 May 9 2022 main.cpp
>> $ printf '%u\n' $(( 0x30e2 ))
>> 12514
>>
>> The value of the symbol _binary_main_cpp_size is the
>> number of bytes in the file.
>>
>> (in other words,
>>
>> _binary_main_cpp_size = _binary_main_cpp_end - _binary_main_cpp_start
>>
>> )
>>
>> In C code:
>>
>> extern uint8_t _binary_main_cpp_size;
>>
>> const size_t embed_size = &_binary_main_cpp_size;
>
>Did you see the output from my version of Michael S's program? The size
>is just an address. If I do what you do:
>
> extern unsigned char _binary_hello_c_size;
>
>....
> size_t size = &_binary_hello_c_size;
> printf("size: %zu\n", size);
>
>It produces:
>
> size: 140697695027270
>
>Little of this seems to work, sorry. You guys keep saying, do this, do
>that, no do it that way, go RTFM, but nobody has shown a complete
>program that correctly shows the -size symbol to be giving anything
>meaningful.
>
>If I run this:
>
> printf("%p\n", &_binary_hello_c_start);
> printf("%p\n", &_binary_hello_c_end);
> printf("%p\n", &_binary_hello_c_size);
>
>I get:
>
> 00007ff6ef252010
> 00007ff6ef252056
> 00007ff5af240046
>
>I can see that the first two can be subtracted to give the sizes of the
>data, which is 70 or 0x46. 0x46 is the last byte of the address of
>_size, so what's happening there? What's with the crap in bits 16-47?
>
>I can extract the size using:
>
> printf("%d\n", (unsigned short)&_binary_hello_c_size);
>
>But something is not right. I've also asked what is the point of the
>-size symbol if you can just do -end - -start, but nobody has explained.
$ cat /tmp/m.c
#include <stdio.h>
#include <stdint.h>
extern uint64_t _binary_main_cpp_size;
extern uint8_t *_binary_main_cpp_start;
extern uint8_t *_binary_main_cpp_end;
int main()
{
printf("%p\n", &_binary_main_cpp_size);
printf("%p\n", &_binary_main_cpp_start);
printf("%p\n", &_binary_main_cpp_end);
return 0;
}
$ objcopy -I binary -B i386 -O elf64-x86-64 main.cpp /tmp/test.o
$ cc -o /tmp/m /tmp/m.c /tmp/test.o
$ /tmp/m
0x30e2
0x601034
0x604116
$ nm /tmp/m | grep _binary_main
0000000000604116 D _binary_main_cpp_end
00000000000030e2 A _binary_main_cpp_size
0000000000601034 D _binary_main_cpp_start
$ wc -c main.cpp
12514 main.cpp
$ printf 0x%x\\n 12514
0x30e2
The size symbol requires no space in the resulting
executable memory image, and it's more convenient than
having to do the math (at run time, since the compiler
can't know the actual values).
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-06-01 11:24 +0100 |
| Message-ID | <v3essl$2nsh7$1@dont-email.me> |
| In reply to | #385375 |
On 01/06/2024 02:25, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>> Little of this seems to work, sorry. You guys keep saying, do this, do
>> that, no do it that way, go RTFM, but nobody has shown a complete
>> program that correctly shows the -size symbol to be giving anything
>> meaningful.
>>
>> If I run this:
>>
>> printf("%p\n", &_binary_hello_c_start);
>> printf("%p\n", &_binary_hello_c_end);
>> printf("%p\n", &_binary_hello_c_size);
>>
>> I get:
>>
>> 00007ff6ef252010
>> 00007ff6ef252056
>> 00007ff5af240046
>>
>> I can see that the first two can be subtracted to give the sizes of the
>> data, which is 70 or 0x46. 0x46 is the last byte of the address of
>> _size, so what's happening there? What's with the crap in bits 16-47?
>>
>> I can extract the size using:
>>
>> printf("%d\n", (unsigned short)&_binary_hello_c_size);
>>
>> But something is not right. I've also asked what is the point of the
>> -size symbol if you can just do -end - -start, but nobody has explained.
>
> $ cat /tmp/m.c
> #include <stdio.h>
> #include <stdint.h>
>
> extern uint64_t _binary_main_cpp_size;
> extern uint8_t *_binary_main_cpp_start;
> extern uint8_t *_binary_main_cpp_end;
>
> int main()
> {
> printf("%p\n", &_binary_main_cpp_size);
> printf("%p\n", &_binary_main_cpp_start);
> printf("%p\n", &_binary_main_cpp_end);
> return 0;
> }
> $ objcopy -I binary -B i386 -O elf64-x86-64 main.cpp /tmp/test.o
> $ cc -o /tmp/m /tmp/m.c /tmp/test.o
> $ /tmp/m
> 0x30e2
> 0x601034
> 0x604116
> $ nm /tmp/m | grep _binary_main
> 0000000000604116 D _binary_main_cpp_end
> 00000000000030e2 A _binary_main_cpp_size
> 0000000000601034 D _binary_main_cpp_start
> $ wc -c main.cpp
> 12514 main.cpp
> $ printf 0x%x\\n 12514
> 0x30e2
>
> The size symbol requires no space in the resulting
> executable memory image, and it's more convenient than
> having to do the math (at run time, since the compiler
> can't know the actual values).
Here's my transcript:
-------------------------------------
C:\c>copy hello.c main.cpp # create main.cpp, here it's 70 bytes
1 file(s) copied.
C:\c>type m.c # exact same code as yours
#include <stdio.h>
#include <stdint.h>
extern uint64_t _binary_main_cpp_size;
extern uint8_t *_binary_main_cpp_start;
extern uint8_t *_binary_main_cpp_end;
int main()
{
printf("%p\n", &_binary_main_cpp_size);
printf("%p\n", &_binary_main_cpp_start);
printf("%p\n", &_binary_main_cpp_end);
return 0;
}
C:\c>objcopy -I binary -O elf64-x86-64 main.cpp test.o # make test.o
C:\c>gcc m.c test.o -o m.exe # build m executable
C:\c>m # run m.exe
00007ff5d5480046 # and the size is ...
00007ff715492010
00007ff715492056
-------------------------------------
Maybe Windows is at fault? I'll try it under WSL:
-------------------------------------
root@DESKTOP-11:/mnt/c/c# objcopy -I binary -O elf64-x86-64 main.cpp test.o
root@DESKTOP-11:/mnt/c/c# gcc m.c test.o -o m
root@DESKTOP-11:/mnt/c/c# ./m
0x55effc9f2046
0x55effc9f6010
0x55effc9f6056
-------------------------------------
Nope, same thing. This doesn't inspire much confidence. With values
shown, the actual size IS contained within the _size value, but only as
the last 16 bits of the value.
gcc versions were 10.3.0 and 9.4.0 respectively; the latter is what is
provided by Windows 11.
You also brought up the fact that the size is not known to the compiler
anyway, which means a few things are not possible, like using the size
in a static context.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-06-01 05:17 -0700 |
| Message-ID | <86frtwq2lz.fsf@linuxsc.com> |
| In reply to | #385381 |
bart <bc@freeuk.com> writes:
> On 01/06/2024 02:25, Scott Lurndal wrote:
>
>> bart <bc@freeuk.com> writes:
>>
>>> Little of this seems to work, sorry. You guys keep saying, do this, do
>>> that, no do it that way, go RTFM, but nobody has shown a complete
>>> program that correctly shows the -size symbol to be giving anything
>>> meaningful.
>>>
>>> If I run this: [attempt to reproduce example]
>>
>> $ cat /tmp/m.c
>> #include <stdio.h>
>> #include <stdint.h>
>>
>> extern uint64_t _binary_main_cpp_size;
>> extern uint8_t *_binary_main_cpp_start;
>> extern uint8_t *_binary_main_cpp_end;
>>
>> int main()
>> {
>> printf("%p\n", &_binary_main_cpp_size);
>> printf("%p\n", &_binary_main_cpp_start);
>> printf("%p\n", &_binary_main_cpp_end);
>> return 0;
>> }
>> $ objcopy -I binary -B i386 -O elf64-x86-64 main.cpp /tmp/test.o
>> $ cc -o /tmp/m /tmp/m.c /tmp/test.o
>> $ /tmp/m
>> 0x30e2
>> 0x601034
>> 0x604116
>> $ nm /tmp/m | grep _binary_main
>> 0000000000604116 D _binary_main_cpp_end
>> 00000000000030e2 A _binary_main_cpp_size
>> 0000000000601034 D _binary_main_cpp_start
>> $ wc -c main.cpp
>> 12514 main.cpp
>> $ printf 0x%x\\n 12514
>> 0x30e2
>>
>> The size symbol requires no space in the resulting
>> executable memory image, and it's more convenient than
>> having to do the math (at run time, since the compiler
>> can't know the actual values).
>
> Here's my transcript:
>
> -------------------------------------
> C:\c>copy hello.c main.cpp # create main.cpp, here it's 70 bytes
> 1 file(s) copied.
>
> C:\c>type m.c # exact same code as yours
> #include <stdio.h>
> #include <stdint.h>
>
> extern uint64_t _binary_main_cpp_size;
> extern uint8_t *_binary_main_cpp_start;
> extern uint8_t *_binary_main_cpp_end;
>
> int main()
> {
> printf("%p\n", &_binary_main_cpp_size);
> printf("%p\n", &_binary_main_cpp_start);
> printf("%p\n", &_binary_main_cpp_end);
> return 0;
> }
>
> C:\c>objcopy -I binary -O elf64-x86-64 main.cpp test.o # make test.o
>
> C:\c>gcc m.c test.o -o m.exe # build m executable
>
> C:\c>m # run m.exe
> 00007ff5d5480046 # and the size is ...
> 00007ff715492010
> 00007ff715492056
>
> [similar results under WSL]
For what it's worth I see the same behavior running on linux.
It looks like the culprit is gcc, which apparently relocates
the symbol even though it is marked with an A type. After
running around in circles for a goodly amount of time, it
occurred to me to try compiling using clang, and that worked.
I suppose it's good to know about the &_binary_main_cpp_size
trick, but it's kind of the worst of both worlds: the size
is baked into the executable (or half-baked I might say), but
the value can't be used at compile time. Bleah. If I wanted
to use the objcopy method of inserting raw text into a C
program, I would either do a run-time subtraction to find out
what the size is, or simply add an extra step to the makefile
to extract the size out of the 'nm' output and produce a .h
file with a (named) value that could be used at compile time.
And both of these methods work under gcc as well as clang.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-06-01 15:08 +0000 |
| Message-ID | <2QG6O.11963$qQk3.6582@fx18.iad> |
| In reply to | #385385 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>bart <bc@freeuk.com> writes:
>
>> On 01/06/2024 02:25, Scott Lurndal wrote:
>>
>>> bart <bc@freeuk.com> writes:
>>>
>>>> Little of this seems to work, sorry. You guys keep saying, do this, do
>>>> that, no do it that way, go RTFM, but nobody has shown a complete
>>>> program that correctly shows the -size symbol to be giving anything
>>>> meaningful.
>>>>
>>>> If I run this: [attempt to reproduce example]
>>>
>>> $ cat /tmp/m.c
>>> #include <stdio.h>
>>> #include <stdint.h>
>>>
>>> extern uint64_t _binary_main_cpp_size;
>>> extern uint8_t *_binary_main_cpp_start;
>>> extern uint8_t *_binary_main_cpp_end;
>>>
>>> int main()
>>> {
>>> printf("%p\n", &_binary_main_cpp_size);
>>> printf("%p\n", &_binary_main_cpp_start);
>>> printf("%p\n", &_binary_main_cpp_end);
>>> return 0;
>>> }
>>> $ objcopy -I binary -B i386 -O elf64-x86-64 main.cpp /tmp/test.o
>>> $ cc -o /tmp/m /tmp/m.c /tmp/test.o
>>> $ /tmp/m
>>> 0x30e2
>>> 0x601034
>>> 0x604116
>>> $ nm /tmp/m | grep _binary_main
>>> 0000000000604116 D _binary_main_cpp_end
>>> 00000000000030e2 A _binary_main_cpp_size
>>> 0000000000601034 D _binary_main_cpp_start
>>> $ wc -c main.cpp
>>> 12514 main.cpp
>>> $ printf 0x%x\\n 12514
>>> 0x30e2
>>>
>>> The size symbol requires no space in the resulting
>>> executable memory image, and it's more convenient than
>>> having to do the math (at run time, since the compiler
>>> can't know the actual values).
>>
>> Here's my transcript:
>>
>> -------------------------------------
>> C:\c>copy hello.c main.cpp # create main.cpp, here it's 70 bytes
>> 1 file(s) copied.
>>
>> C:\c>type m.c # exact same code as yours
>> #include <stdio.h>
>> #include <stdint.h>
>>
>> extern uint64_t _binary_main_cpp_size;
>> extern uint8_t *_binary_main_cpp_start;
>> extern uint8_t *_binary_main_cpp_end;
>>
>> int main()
>> {
>> printf("%p\n", &_binary_main_cpp_size);
>> printf("%p\n", &_binary_main_cpp_start);
>> printf("%p\n", &_binary_main_cpp_end);
>> return 0;
>> }
>>
>> C:\c>objcopy -I binary -O elf64-x86-64 main.cpp test.o # make test.o
>>
>> C:\c>gcc m.c test.o -o m.exe # build m executable
>>
>> C:\c>m # run m.exe
>> 00007ff5d5480046 # and the size is ...
>> 00007ff715492010
>> 00007ff715492056
>>
>> [similar results under WSL]
>
>For what it's worth I see the same behavior running on linux.
Which versions? It works fine on my linux system (FC20, GCC 4.8.3)
>It looks like the culprit is gcc, which apparently relocates
>the symbol even though it is marked with an A type.
gcc doesn't do 'relocations'. If you have a problem, it's
likely with binutils (i.e. ld(1)).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-06-01 17:22 -0700 |
| Message-ID | <86bk4kp50e.fsf@linuxsc.com> |
| In reply to | #385389 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> bart <bc@freeuk.com> writes:
>>
>>> On 01/06/2024 02:25, Scott Lurndal wrote:
>>>
>>>> bart <bc@freeuk.com> writes:
>>>>
>>>>> Little of this seems to work, sorry. You guys keep saying, do this, do
>>>>> that, no do it that way, go RTFM, but nobody has shown a complete
>>>>> program that correctly shows the -size symbol to be giving anything
>>>>> meaningful.
>>>>>
>>>>> If I run this: [attempt to reproduce example]
>>>>
>>>> $ cat /tmp/m.c
>>>> #include <stdio.h>
>>>> #include <stdint.h>
>>>>
>>>> extern uint64_t _binary_main_cpp_size;
>>>> extern uint8_t *_binary_main_cpp_start;
>>>> extern uint8_t *_binary_main_cpp_end;
>>>>
>>>> int main()
>>>> {
>>>> printf("%p\n", &_binary_main_cpp_size);
>>>> printf("%p\n", &_binary_main_cpp_start);
>>>> printf("%p\n", &_binary_main_cpp_end);
>>>> return 0;
>>>> }
>>>> $ objcopy -I binary -B i386 -O elf64-x86-64 main.cpp /tmp/test.o
>>>> $ cc -o /tmp/m /tmp/m.c /tmp/test.o
>>>> $ /tmp/m
>>>> 0x30e2
>>>> 0x601034
>>>> 0x604116
>>>> $ nm /tmp/m | grep _binary_main
>>>> 0000000000604116 D _binary_main_cpp_end
>>>> 00000000000030e2 A _binary_main_cpp_size
>>>> 0000000000601034 D _binary_main_cpp_start
>>>> $ wc -c main.cpp
>>>> 12514 main.cpp
>>>> $ printf 0x%x\\n 12514
>>>> 0x30e2
>>>>
>>>> The size symbol requires no space in the resulting
>>>> executable memory image, and it's more convenient than
>>>> having to do the math (at run time, since the compiler
>>>> can't know the actual values).
>>>
>>> Here's my transcript:
>>>
>>> -------------------------------------
>>> C:\c>copy hello.c main.cpp # create main.cpp, here it's 70 bytes
>>> 1 file(s) copied.
>>>
>>> C:\c>type m.c # exact same code as yours
>>> #include <stdio.h>
>>> #include <stdint.h>
>>>
>>> extern uint64_t _binary_main_cpp_size;
>>> extern uint8_t *_binary_main_cpp_start;
>>> extern uint8_t *_binary_main_cpp_end;
>>>
>>> int main()
>>> {
>>> printf("%p\n", &_binary_main_cpp_size);
>>> printf("%p\n", &_binary_main_cpp_start);
>>> printf("%p\n", &_binary_main_cpp_end);
>>> return 0;
>>> }
>>>
>>> C:\c>objcopy -I binary -O elf64-x86-64 main.cpp test.o # make test.o
>>>
>>> C:\c>gcc m.c test.o -o m.exe # build m executable
>>>
>>> C:\c>m # run m.exe
>>> 00007ff5d5480046 # and the size is ...
>>> 00007ff715492010
>>> 00007ff715492056
>>>
>>> [similar results under WSL]
>>
>> For what it's worth I see the same behavior running on linux.
>
> Which versions? It works fine on my linux system (FC20, GCC 4.8.3)
gcc --version gives 'gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0'
>> It looks like the culprit is gcc, which apparently relocates
>> the symbol even though it is marked with an A type.
>
> gcc doesn't do 'relocations'. If you have a problem, it's
> likely with binutils (i.e. ld(1)).
I expect you are right. I run ld directly only rarely, and
certainly am no expert. In my tests I was simply blindly
following the example shown in your posting (with some variations
after my attempts gave the wrong answer, trying to get it to
work). It didn't occur to me to consider ld.
Using clang for the final link step always gave the right answer,
if I remember correctly.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-06-06 14:56 +0300 |
| Subject | objcopy -I binary etc... Was: C23 thoughts and opinions |
| Message-ID | <20240606145633.000061f5@yahoo.com> |
| In reply to | #385398 |
On Sat, 01 Jun 2024 17:22:57 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>
> > Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> >
> >> bart <bc@freeuk.com> writes:
> >>
> >>> On 01/06/2024 02:25, Scott Lurndal wrote:
> >>>
> >>>> bart <bc@freeuk.com> writes:
> >>>>
> >>>>> Little of this seems to work, sorry. You guys keep saying, do
> >>>>> this, do that, no do it that way, go RTFM, but nobody has shown
> >>>>> a complete program that correctly shows the -size symbol to be
> >>>>> giving anything meaningful.
> >>>>>
> >>>>> If I run this: [attempt to reproduce example]
> >>>>
> >>>> $ cat /tmp/m.c
> >>>> #include <stdio.h>
> >>>> #include <stdint.h>
> >>>>
> >>>> extern uint64_t _binary_main_cpp_size;
> >>>> extern uint8_t *_binary_main_cpp_start;
> >>>> extern uint8_t *_binary_main_cpp_end;
> >>>>
> >>>> int main()
> >>>> {
> >>>> printf("%p\n", &_binary_main_cpp_size);
> >>>> printf("%p\n", &_binary_main_cpp_start);
> >>>> printf("%p\n", &_binary_main_cpp_end);
> >>>> return 0;
> >>>> }
> >>>> $ objcopy -I binary -B i386 -O elf64-x86-64 main.cpp /tmp/test.o
> >>>> $ cc -o /tmp/m /tmp/m.c /tmp/test.o
> >>>> $ /tmp/m
> >>>> 0x30e2
> >>>> 0x601034
> >>>> 0x604116
> >>>> $ nm /tmp/m | grep _binary_main
> >>>> 0000000000604116 D _binary_main_cpp_end
> >>>> 00000000000030e2 A _binary_main_cpp_size
> >>>> 0000000000601034 D _binary_main_cpp_start
> >>>> $ wc -c main.cpp
> >>>> 12514 main.cpp
> >>>> $ printf 0x%x\\n 12514
> >>>> 0x30e2
> >>>>
> >>>> The size symbol requires no space in the resulting
> >>>> executable memory image, and it's more convenient than
> >>>> having to do the math (at run time, since the compiler
> >>>> can't know the actual values).
> >>>
> >>> Here's my transcript:
> >>>
> >>> -------------------------------------
> >>> C:\c>copy hello.c main.cpp # create main.cpp, here it's
> >>> 70 bytes 1 file(s) copied.
> >>>
> >>> C:\c>type m.c # exact same code as yours
> >>> #include <stdio.h>
> >>> #include <stdint.h>
> >>>
> >>> extern uint64_t _binary_main_cpp_size;
> >>> extern uint8_t *_binary_main_cpp_start;
> >>> extern uint8_t *_binary_main_cpp_end;
> >>>
> >>> int main()
> >>> {
> >>> printf("%p\n", &_binary_main_cpp_size);
> >>> printf("%p\n", &_binary_main_cpp_start);
> >>> printf("%p\n", &_binary_main_cpp_end);
> >>> return 0;
> >>> }
> >>>
> >>> C:\c>objcopy -I binary -O elf64-x86-64 main.cpp test.o # make
> >>> test.o
> >>> C:\c>gcc m.c test.o -o m.exe # build m executable
> >>>
> >>> C:\c>m # run m.exe
> >>> 00007ff5d5480046 # and the size is ...
> >>> 00007ff715492010
> >>> 00007ff715492056
> >>>
> >>> [similar results under WSL]
> >>
> >> For what it's worth I see the same behavior running on linux.
> >
> > Which versions? It works fine on my linux system (FC20, GCC
> > 4.8.3)
>
> gcc --version gives 'gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0'
>
> >> It looks like the culprit is gcc, which apparently relocates
> >> the symbol even though it is marked with an A type.
> >
> > gcc doesn't do 'relocations'. If you have a problem, it's
> > likely with binutils (i.e. ld(1)).
>
Except that typically on Linux gcc and clang use the same linker.
> I expect you are right. I run ld directly only rarely, and
> certainly am no expert. In my tests I was simply blindly
> following the example shown in your posting (with some variations
> after my attempts gave the wrong answer, trying to get it to
> work). It didn't occur to me to consider ld.
>
> Using clang for the final link step always gave the right answer,
> if I remember correctly.
I reproduced your findings. The difference between gcc and clang is not
in ld, but in ld invocation options.
Specifically, gcc calls ld with -pie, clang calls ld without it.
gcc default behaviour can be overwritten with -no-pie switch.
I suppose that gcc4 has the same default as clang.
[toc] | [prev] | [next] | [standalone]
Page 8 of 28 — ← Prev page 1 … 6 7 [8] 9 10 … 28 Next page →
Back to top | Article view | comp.lang.c
csiph-web