Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #170696 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2023-07-12 07:18 -0700 |
| Last post | 2023-07-23 03:32 -0700 |
| Articles | 20 on this page of 968 — 32 participants |
Back to article view | Back to comp.lang.c
you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-12 07:18 -0700
Re: you think rust may outthrone c? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2023-07-13 01:37 -0400
Re: you think rust may outthrone c? jak <nospam@please.ty> - 2023-07-13 10:16 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-13 04:27 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-13 05:01 -0700
Re: you think rust may outthrone c? rek2 hispagatos <rek2@hispagatos.org.invalid> - 2023-07-13 14:10 +0000
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-13 17:51 +0000
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-13 18:56 +0000
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-07-13 19:39 +0000
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-13 20:30 +0000
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-13 22:29 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-14 00:19 +0100
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 06:43 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-14 11:47 +0100
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 11:04 +0000
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-14 21:01 +0000
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 21:21 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-14 13:52 +0200
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 12:08 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-14 17:10 +0200
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-14 21:32 +0000
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 22:04 +0000
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-14 21:02 +0000
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 21:35 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-15 14:30 +0200
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-07-15 16:36 +0000
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-15 15:49 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-15 16:02 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-16 01:18 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-15 16:25 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-16 11:07 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-16 05:42 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-16 16:17 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-16 07:44 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-16 09:57 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-16 10:34 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-16 10:41 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-16 20:55 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-17 01:54 +0100
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-17 02:43 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-17 03:16 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-17 14:54 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-17 07:08 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-17 16:43 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-17 17:19 +0100
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-21 00:05 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-21 16:52 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-17 17:21 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-17 09:44 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-17 21:24 +0200
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-07-17 15:10 +0000
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-17 18:46 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-17 21:27 +0200
Re: you think rust may outthrone c? jak <nospam@please.ty> - 2023-07-20 20:40 +0200
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-20 19:27 +0000
Re: you think rust may outthrone c? jak <nospam@please.ty> - 2023-07-20 22:16 +0200
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-20 19:17 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-17 16:15 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-17 09:17 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-17 21:41 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-17 23:02 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-17 08:22 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-17 15:01 -0700
Re: you think rust may outthrone c? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-17 15:01 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-18 09:26 +0200
Re: you think rust may outthrone c? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-18 00:33 -0700
Re: you think rust may outthrone c? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-18 00:35 -0700
Re: you think rust may outthrone c? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-18 00:37 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-18 13:05 +0100
Re: you think rust may outthrone c? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-19 17:56 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-18 09:13 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-18 12:18 +0100
Re: you think rust may outthrone c? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-18 01:24 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-17 15:06 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-17 23:11 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-17 15:30 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-18 00:07 +0100
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-18 01:28 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-18 02:20 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-18 02:12 +0000
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-18 03:25 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-18 09:55 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-18 12:29 +0100
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-19 02:29 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-19 09:16 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-19 12:38 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-19 14:24 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-19 14:12 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-19 16:33 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-19 16:37 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-19 16:55 +0000
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-19 19:44 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-18 12:06 +0100
Re: you think rust may outthrone c? Ike Naar <ike@sdf.org> - 2023-07-18 12:16 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-18 14:09 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-18 16:36 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-18 17:59 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-19 09:45 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-19 03:31 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-19 06:01 +0000
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-19 01:19 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-19 03:02 -0700
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-19 04:30 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-19 15:28 +0200
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-19 15:12 -0700
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-19 15:23 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-20 10:44 +0200
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-20 15:37 -0700
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-19 23:01 +0000
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-19 16:43 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-20 10:41 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-21 00:24 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-20 16:58 -0700
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-20 17:30 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-20 17:50 -0700
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-20 22:46 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-21 09:57 +0200
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-21 02:24 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-21 13:33 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-21 02:01 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-20 18:28 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-21 11:21 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-21 03:44 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-21 12:17 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-21 15:05 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-21 14:42 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-21 16:22 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-21 16:40 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-21 18:56 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-21 20:26 +0100
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-21 21:06 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-22 18:34 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-22 20:09 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-21 14:34 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-21 23:03 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-21 15:30 -0700
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-21 21:49 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-22 11:41 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-22 04:15 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-22 15:51 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-22 19:05 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-23 00:22 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-22 16:38 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-23 01:15 +0100
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-07-23 13:45 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-23 15:06 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-23 17:54 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-23 17:56 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-23 11:03 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-23 20:15 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-23 20:18 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-24 09:50 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-24 10:58 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-24 06:02 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-24 14:08 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-24 18:42 +0000
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-05 10:22 -0700
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-05 18:02 +0000
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-05 18:32 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-05 20:00 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-06 01:42 +0000
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-14 04:54 -0700
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-14 18:22 +0000
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-25 19:44 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-25 21:09 -0700
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-26 00:21 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-26 11:17 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-26 03:31 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-26 16:52 -0700
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-27 00:47 +0000
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-26 21:19 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-26 20:21 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-26 21:49 -0700
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-27 02:04 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-27 02:42 -0700
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-27 17:36 +0000
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-27 05:50 +0000
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-27 20:03 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-26 11:04 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-26 03:34 -0700
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-12 10:57 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-12 16:37 -0700
Re: you think rust may outthrone c? Spiros Bousbouras <spibou@gmail.com> - 2023-08-13 08:16 +0000
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-13 15:48 +0000
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-15 13:05 -0700
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-15 14:20 -0700
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-25 20:08 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-24 20:19 +0200
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-21 14:52 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-21 16:14 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-21 12:52 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-22 18:29 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-22 21:56 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-22 16:11 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-23 00:45 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-23 17:24 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-23 17:28 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-23 16:45 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-24 10:04 +0200
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-24 07:43 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-23 22:10 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-23 14:51 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-23 23:12 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-23 15:19 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-24 20:25 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-24 17:22 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-24 09:52 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-25 02:52 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-24 17:37 +0200
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-07-24 16:19 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-24 20:34 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-25 02:42 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-25 10:36 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-25 16:41 +0100
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-07-25 16:22 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-25 17:40 +0100
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-26 02:40 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-26 11:30 +0100
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-26 06:41 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-27 01:06 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-27 01:55 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-26 18:03 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-27 03:17 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-27 11:50 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-27 02:50 +0000
Overflow and undefined behaviour (WAS: you think rust may outthrone c?) Spiros Bousbouras <spibou@gmail.com> - 2023-07-25 16:43 +0000
Re: Overflow and undefined behaviour (WAS: you think rust may outthrone c?) Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-25 19:15 +0200
Re: Overflow and undefined behaviour (WAS: you think rust may outthrone c?) Bart <bc@freeuk.com> - 2023-07-25 18:43 +0100
Re: Overflow and undefined behaviour Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-25 15:03 -0700
Re: Overflow and undefined behaviour Spiros Bousbouras <spibou@gmail.com> - 2023-07-26 04:10 +0000
Re: Overflow and undefined behaviour Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-25 21:51 -0700
Re: Overflow and undefined behaviour Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-26 22:07 +0100
Re: Overflow and undefined behaviour Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-26 21:55 +0100
Re: Overflow and undefined behaviour Bart <bc@freeuk.com> - 2023-07-26 22:26 +0100
Re: Overflow and undefined behaviour Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-26 17:26 -0700
Re: Overflow and undefined behaviour Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-27 01:38 +0100
Re: Overflow and undefined behaviour Phil Carmody <pc+usenet@asdf.org> - 2023-08-13 14:53 +0300
Re: Overflow and undefined behaviour Bart <bc@freeuk.com> - 2023-08-13 13:07 +0100
What's wrong? The phrasing, that's what! (Was: Overflow and undefined behaviour) gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-13 13:16 +0000
Re: Overflow and undefined behaviour Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-13 16:25 +0100
Re: Overflow and undefined behaviour Phil Carmody <pc+usenet@asdf.org> - 2023-08-14 12:10 +0300
Re: Overflow and undefined behaviour Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-14 04:33 -0700
Re: Overflow and undefined behaviour Phil Carmody <pc+usenet@asdf.org> - 2023-08-14 14:56 +0300
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-25 17:34 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-25 20:55 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-28 02:46 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-25 15:53 -0700
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-24 22:33 -0700
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-24 09:45 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-24 14:29 -0700
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-26 07:03 -0700
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-26 07:41 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-26 16:01 +0100
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-07-26 15:21 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-26 19:13 +0100
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-07-26 18:41 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-26 22:07 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-27 13:34 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-27 05:15 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-27 15:14 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-27 06:31 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-27 16:17 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-27 07:53 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-27 20:45 +0100
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-04 00:21 -0700
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-04 18:29 +0000
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-04 11:35 -0700
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-05 06:09 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-27 14:30 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-27 16:48 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-27 17:18 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-27 09:45 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-27 19:18 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-01 18:10 +0200
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-01 15:00 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-01 15:41 +0100
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-01 16:16 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-01 17:50 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-01 17:04 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-01 18:25 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-01 18:26 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-01 19:18 +0200
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-01 17:41 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-01 21:01 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-02 03:41 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-02 12:09 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-02 05:01 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-02 17:04 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-02 09:10 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-02 23:48 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-02 15:25 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-03 11:42 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-04 02:15 -0700
Re: you think rust may outthrone c? Spiros Bousbouras <spibou@gmail.com> - 2023-08-04 14:20 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-04 17:12 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-04 08:20 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-04 18:04 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-04 09:17 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-05 13:39 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-05 05:08 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-08 17:18 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 16:35 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-08 09:04 -0700
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-08 16:41 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-08 18:46 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-08 10:04 -0700
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-08 17:53 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-09 10:41 +0200
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-08 18:55 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-09 00:26 +0200
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-08 16:51 -0700
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-08 20:23 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-09 13:42 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-09 05:32 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-15 13:00 +0200
Re: you think rust may outthrone c? Michael S <already5chosen@yahoo.com> - 2023-08-09 05:35 -0700
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-09 05:48 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-09 14:17 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-15 13:06 +0200
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-09 13:44 +0000
Re: you think rust may outthrone c? doctor@doctor.nl2k.ab.ca (The Doctor) - 2023-08-09 14:00 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-09 15:09 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-09 07:15 -0700
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-09 15:48 +0000
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-09 08:54 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-09 15:18 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-09 16:01 +0100
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-09 15:50 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-09 17:51 +0100
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-09 21:51 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-15 13:16 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-09 09:18 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-10 00:05 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 19:10 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-08 16:24 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-09 14:24 +0200
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-09 17:18 +0000
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-09 17:38 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-15 13:35 +0200
Re: you think rust may outthrone c? Phil Carmody <pc+usenet@asdf.org> - 2023-08-15 17:51 +0300
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-15 17:18 +0200
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-15 16:01 +0000
Re: you think rust may outthrone c? Phil Carmody <pc+usenet@asdf.org> - 2023-08-15 23:11 +0300
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-15 15:48 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-02 23:40 +0200
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-02 17:58 +0200
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-02 19:07 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-02 22:13 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-03 02:07 +0100
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-03 02:34 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-03 11:39 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-03 15:10 +0100
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-03 17:37 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-03 18:56 +0100
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-05 23:11 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-06 00:21 +0100
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-06 00:54 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-06 11:18 +0100
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-06 17:06 +0100
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-06 17:22 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-06 14:40 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-06 23:04 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-06 15:19 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-06 23:33 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-06 17:20 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-07 01:52 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-06 18:12 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-07 10:35 +0100
Re: you think rust may outthrone c? Richard Damon <Richard@Damon-Family.org> - 2023-08-07 07:41 -0400
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-07 04:53 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-07 14:15 +0100
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-07 16:13 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-07 08:40 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-07 17:05 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-07 09:43 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-08 00:51 +0100
Making accountants cross (wa Re: you think rust may outthrone c?) Vir Campestris <vir.campestris@invalid.invalid> - 2023-08-10 15:38 +0100
Re: Making accountants cross (wa Re: you think rust may outthrone c?) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-10 16:26 +0100
Re: Making accountants cross (wa Re: you think rust may outthrone c?) Bart <bc@freeuk.com> - 2023-08-10 16:35 +0100
Re: Making accountants cross (wa Re: you think rust may outthrone c?) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-10 16:31 +0000
Re: Making accountants cross (wa Re: you think rust may outthrone c?) Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-08-10 16:59 +0000
Re: Making accountants cross (wa Re: you think rust may outthrone c?) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-10 11:13 -0700
Re: Making accountants cross (wa Re: you think rust may outthrone c?) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-10 18:26 +0000
Re: Making accountants cross (wa Re: you think rust may outthrone c?) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-10 11:30 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-08 17:39 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-07 18:35 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-07 21:51 +0000
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-07 23:53 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 01:28 +0100
Re: you think rust may outthrone c? Richard Damon <Richard@Damon-Family.org> - 2023-08-07 22:21 -0400
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 12:05 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-08 04:13 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-08 15:04 -0700
Re: you think rust may outthrone c? Richard Damon <Richard@Damon-Family.org> - 2023-08-08 08:22 -0400
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 15:16 +0100
Re: you think rust may outthrone c? Michael S <already5chosen@yahoo.com> - 2023-08-08 09:15 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 18:33 +0100
Re: you think rust may outthrone c? Richard Damon <Richard@Damon-Family.org> - 2023-08-08 21:58 -0400
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-09 11:05 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-09 11:53 +0100
Re: you think rust may outthrone c? Michael S <already5chosen@yahoo.com> - 2023-08-09 05:10 -0700
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-08 13:57 +0000
Re: you think rust may outthrone c? Michael S <already5chosen@yahoo.com> - 2023-08-08 08:55 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 18:23 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-08 15:28 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-07 15:17 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 01:08 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-07 18:31 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-08 00:43 +0100
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-08 06:20 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-08 15:56 +0100
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-08 08:35 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-09 02:44 +0100
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-09 05:53 -0700
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-07 16:20 +0000
Re: you think rust may outthrone c? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-08-07 13:10 -0400
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-07 10:24 -0700
Re: you think rust may outthrone c? Richard Damon <Richard@Damon-Family.org> - 2023-08-07 22:46 -0400
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-07 14:52 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 01:01 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-07 17:59 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 11:34 +0100
Re: you think rust may outthrone c? Richard Damon <Richard@Damon-Family.org> - 2023-08-08 08:34 -0400
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-08 14:51 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 23:19 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-08 22:58 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-09 00:33 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-08 23:50 +0000
Re: you think rust may outthrone c? Michael S <already5chosen@yahoo.com> - 2023-08-09 04:07 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-03 14:08 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-03 17:09 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-02 18:39 -0700
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-03 02:12 +0000
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-02 20:08 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-03 23:42 +0200
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-03 15:44 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-04 07:44 +0200
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-04 07:14 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-04 17:14 +0200
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-04 13:56 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-04 15:25 +0100
Re: you think rust may outthrone c? Richard Damon <Richard@Damon-Family.org> - 2023-08-04 17:05 -0400
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-04 22:32 +0100
Re: you think rust may outthrone c? Richard Damon <Richard@Damon-Family.org> - 2023-08-04 17:46 -0400
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-04 21:47 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-05 00:43 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-05 00:15 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-05 01:33 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-05 02:11 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-05 11:00 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-06 16:50 +0200
Re: you think rust may outthrone c? Richard Damon <Richard@Damon-Family.org> - 2023-08-06 18:40 -0400
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-07 00:31 +0000
Re: you think rust may outthrone c? Richard Damon <Richard@Damon-Family.org> - 2023-08-04 22:44 -0400
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-05 10:46 +0100
Re: you think rust may outthrone c? Richard Damon <Richard@Damon-Family.org> - 2023-08-06 07:53 -0400
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-07 11:53 +0200
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-06 16:43 +0200
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-04 19:50 -0700
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-05 02:58 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-05 14:17 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-05 17:38 +0000
Re: you think rust may outthrone c? Richard Damon <Richard@Damon-Family.org> - 2023-08-06 07:56 -0400
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-06 13:38 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-07 14:12 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-07 16:03 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-07 16:24 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-07 17:54 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-07 14:16 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-07 05:45 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-07 22:17 +0100
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-07 22:19 +0000
Re: you think rust may outthrone c? Richard Damon <Richard@Damon-Family.org> - 2023-08-07 22:40 -0400
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-08 18:07 +0200
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-08 05:53 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 15:31 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-08 18:17 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-08 09:31 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-09 22:27 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-09 18:49 -0700
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-08 16:39 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-04 00:37 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-04 18:07 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-04 10:32 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-04 19:36 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-04 11:53 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-08 12:57 +0200
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-08 12:32 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-08 03:59 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 12:19 +0100
Re: you think rust may outthrone c? Richard Damon <Richard@Damon-Family.org> - 2023-08-08 08:40 -0400
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-08 12:17 +0200
Re: you think rust may outthrone c? Vir Campestris <vir.campestris@invalid.invalid> - 2023-08-04 18:00 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-04 19:25 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-08 13:11 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-08 04:22 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-08 14:45 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-08 06:02 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-08 15:39 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-08 08:36 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-09 02:15 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 12:36 +0100
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-08 14:05 +0000
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-08 15:31 +0100
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-08 14:34 +0000
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-08 16:11 +0100
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-08 15:49 +0000
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-08 21:05 +0100
Re: you think rust may *DE*throne c? Michael S <already5chosen@yahoo.com> - 2023-08-08 09:02 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-08 16:27 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 16:09 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 16:42 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-08 18:38 +0200
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-08 09:47 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 19:14 +0100
Re: you think rust may outthrone c? Michael S <already5chosen@yahoo.com> - 2023-08-08 10:04 -0700
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-08 17:32 +0000
Re: you think rust may *DE*throne c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-08 10:47 -0700
Re: you think rust may *DE*throne c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-09 03:04 +0100
Re: you think rust may *DE*throne c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-08 19:44 -0700
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-09 11:22 +0100
Re: you think rust may *DE*throne c? Richard Harnden <richard.nospam@gmail.com> - 2023-08-09 11:36 +0100
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-09 11:58 +0100
Re: you think rust may *DE*throne c? Richard Harnden <richard.nospam@gmail.com> - 2023-08-09 14:29 +0100
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-09 16:02 +0000
Re: you think rust may *DE*throne c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-09 14:17 -0700
Re: you think rust may *DE*throne c? Dan Purgert <dan@djph.net> - 2023-08-09 11:05 +0000
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-09 13:32 +0100
Re: you think rust may *DE*throne c? Richard Harnden <richard.nospam@gmail.com> - 2023-08-09 14:32 +0100
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-09 15:07 +0100
Re: you think rust may *DE*throne c? Richard Harnden <richard.nospam@gmail.com> - 2023-08-09 15:48 +0100
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-09 16:08 +0100
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-09 15:52 +0000
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-09 18:09 +0100
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-09 16:34 +0000
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-12 10:36 +0200
Re: you think rust may *DE*throne c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-12 02:58 -0700
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-13 08:18 +0200
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-13 07:07 +0000
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-13 07:34 +0000
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-13 08:24 +0000
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-15 14:10 +0200
Re: you think rust may *DE*throne c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-13 00:18 -0700
Re: you think rust may *DE*throne c? Spiros Bousbouras <spibou@gmail.com> - 2023-08-13 08:08 +0000
Re: you think rust may *DE*throne c? Michael S <already5chosen@yahoo.com> - 2023-08-13 03:44 -0700
Re: you think rust may *DE*throne c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-13 06:16 -0700
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-13 15:53 +0000
Re: you think rust may *DE*throne c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-13 08:58 -0700
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-13 17:36 +0100
Re: you think rust may *DE*throne c? Michael S <already5chosen@yahoo.com> - 2023-08-13 03:38 -0700
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-12 12:12 +0100
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-13 09:30 +0200
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-13 16:02 +0000
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-13 17:48 +0100
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-13 18:53 +0100
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-13 20:41 +0000
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-13 20:40 +0000
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-14 04:28 +0000
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-14 15:52 +0000
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-14 16:06 +0000
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-15 14:19 +0200
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-15 14:33 +0000
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-15 17:24 +0200
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-15 15:58 +0000
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-15 15:58 +0000
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-15 15:27 +0000
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-11 08:43 +0200
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-11 11:17 +0100
Re: you think rust may *DE*throne c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-08-11 10:50 +0000
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-11 13:09 +0100
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-11 13:32 +0000
Re: you think rust may *DE*throne c? Michael S <already5chosen@yahoo.com> - 2023-08-11 07:33 -0700
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-11 15:38 +0000
Re: you think rust may *DE*throne c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-08-11 16:45 +0000
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-11 10:20 -0700
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-11 18:35 +0100
Re: you think rust may *DE*throne c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-08-11 20:33 +0000
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-11 22:09 +0100
Re: you think rust may *DE*throne c? Richard Harnden <richard.nospam@gmail.com> - 2023-08-11 22:59 +0100
Re: you think rust may *DE*throne c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-08-11 23:25 +0000
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-12 00:26 +0000
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-15 14:24 +0200
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-11 21:30 +0000
Re: you think rust may *DE*throne c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-11 13:44 -0700
Re: you think rust may *DE*throne c? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-11 14:55 -0700
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-11 21:38 +0000
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-11 22:46 +0100
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-15 14:32 +0200
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-12 12:07 +0100
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-11 15:34 +0100
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-11 15:39 +0000
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-11 17:26 +0100
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-11 16:53 +0000
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-11 18:15 +0100
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-11 18:46 +0100
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-15 14:35 +0200
Re: you think rust may *DE*throne c? Richard Harnden <richard.nospam@gmail.com> - 2023-08-11 19:43 +0100
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-13 09:34 +0200
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-13 16:02 +0000
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-13 17:38 +0100
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-15 14:37 +0200
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-15 14:34 +0000
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-15 16:17 +0100
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-15 17:25 +0200
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-15 16:00 +0000
Re: you think rust may *DE*throne c? Ike Naar <ike@sdf.org> - 2023-08-11 10:05 +0000
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-11 11:48 +0100
Re: you think rust may *DE*throne c? Dan Purgert <dan@djph.net> - 2023-08-09 15:06 +0000
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-09 16:16 +0000
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-10 09:38 +0200
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-10 10:51 +0100
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-09 15:57 +0000
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-10 00:15 +0200
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-10 00:22 +0100
Re: you think rust may *DE*throne c? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-09 17:02 -0700
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-10 14:27 +0000
Re: you think rust may *DE*throne c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-10 00:01 +0100
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-10 00:39 +0100
Re: you think rust may *DE*throne c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-09 17:08 -0700
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-10 00:21 +0000
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-10 02:18 +0100
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-10 02:28 +0000
Re: you think rust may *DE*throne c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-09 22:42 -0700
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-10 14:23 +0000
Re: you think rust may *DE*throne c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-09 19:10 -0700
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-10 14:24 +0000
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-10 14:21 +0000
Re: you think rust may *DE*throne c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-10 03:16 +0100
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-10 14:25 +0000
Re: you think rust may *DE*throne c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-10 16:18 +0100
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-10 15:53 +0000
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-10 16:15 +0000
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-10 16:59 +0000
Re: you think rust may *DE*throne c? Michael S <already5chosen@yahoo.com> - 2023-08-10 10:12 -0700
Re: you think rust may *DE*throne c? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-08-10 17:16 +0000
Re: you think rust may *DE*throne c? Michael S <already5chosen@yahoo.com> - 2023-08-10 10:27 -0700
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-10 17:54 +0000
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-10 18:18 +0000
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-10 18:16 +0000
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-10 14:44 -0700
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-10 14:56 -0700
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-10 23:17 +0100
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-10 16:06 -0700
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-10 16:20 -0700
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-10 16:38 -0700
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-10 16:58 -0700
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-10 18:43 -0700
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-11 01:30 +0100
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-10 17:58 -0700
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-11 07:03 -0700
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-11 07:28 -0700
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-11 07:47 -0700
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-11 08:06 -0700
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-11 16:13 +0100
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-11 08:28 -0700
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-11 08:37 -0700
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-11 08:46 -0700
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-11 08:58 -0700
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-11 09:52 -0700
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-10 18:21 -0700
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-10 23:09 +0100
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-11 01:14 +0000
Re: you think rust may *DE*throne c? Spiros Bousbouras <spibou@gmail.com> - 2023-08-11 05:42 +0000
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-11 06:07 +0000
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-11 13:30 +0000
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-11 19:41 +0000
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-12 08:21 -0700
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-12 11:14 -0700
Re: you think rust may *DE*throne c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-10 17:39 +0100
Re: you think rust may *DE*throne c? Michael S <already5chosen@yahoo.com> - 2023-08-10 09:40 -0700
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-10 17:48 +0100
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-15 14:45 +0200
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-15 13:52 +0100
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-15 14:40 +0000
Re: you think rust may *DE*throne c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-15 06:26 -0700
Re: you think rust may *DE*throne c? David Brown <david.brown@hesbynett.no> - 2023-08-15 15:43 +0200
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-16 10:09 -0700
Re: you think rust may *DE*throne c? fir <profesor.fir@gmail.com> - 2023-08-18 07:36 -0700
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-10 16:33 +0100
Re: you think rust may *DE*throne c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-10 16:57 +0000
Re: you think rust may *DE*throne c? Michael S <already5chosen@yahoo.com> - 2023-08-10 01:10 -0700
Re: you think rust may *DE*throne c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-10 16:08 +0100
Re: you think rust may *DE*throne c? Michael S <already5chosen@yahoo.com> - 2023-08-10 09:49 -0700
Re: you think rust may *DE*throne c? Bart <bc@freeuk.com> - 2023-08-10 18:08 +0100
Re: you think rust may *DE*throne c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-10 21:04 +0100
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-10 20:56 +0000
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-10 14:20 +0000
Re: you think rust may *DE*throne c? Michael S <already5chosen@yahoo.com> - 2023-08-08 10:53 -0700
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-08 18:30 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-09 23:14 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-08 19:07 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-08 15:46 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-09 00:15 +0100
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-08 23:54 +0000
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-08 17:52 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-09 02:22 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-08 19:01 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-08 16:57 -0700
Re: you think rust may *DE*throne c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-08 14:03 +0000
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-27 13:13 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-28 23:35 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-28 19:21 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-29 21:15 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-29 14:45 -0700
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-29 00:05 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-29 11:19 +0100
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-07-29 13:47 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-29 15:10 +0100
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-07-29 16:00 +0000
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-29 15:30 +0000
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-29 14:22 -0700
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-29 14:49 -0700
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-07-27 14:07 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-27 16:03 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-01 19:43 +0200
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-01 18:37 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-01 22:16 +0100
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-01 21:53 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-01 23:28 +0100
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-08-02 01:54 +0000
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-02 11:14 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-02 18:23 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-02 19:02 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-03 11:28 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-03 11:53 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-08-03 11:54 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-08-02 18:12 +0200
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-01 14:45 -0700
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-07-26 15:02 +0000
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-26 17:08 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-21 12:38 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-21 12:29 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-21 09:46 +0200
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-21 02:29 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-22 21:04 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-19 14:38 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-19 07:00 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-19 17:31 +0100
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-19 14:54 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-20 10:55 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-21 03:07 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-19 12:07 +0100
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-19 15:15 +0100
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-19 17:08 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-19 17:30 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-19 19:22 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-19 20:28 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-19 16:27 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-19 17:06 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-19 20:39 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-19 20:21 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-19 15:42 -0700
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-19 23:31 +0000
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-19 18:53 -0700
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-20 01:46 -0700
Re: you think rust may outthrone c? Spiros Bousbouras <spibou@gmail.com> - 2023-07-20 09:51 +0000
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-20 03:36 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-20 12:13 +0100
Re: you think rust may outthrone c? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-20 13:06 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-20 11:28 +0200
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-20 16:44 +0000
Re: you think rust may outthrone c? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-07-21 01:22 -0400
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-21 02:03 -0700
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-22 15:37 -0700
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-20 02:08 +0100
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-22 15:43 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-20 11:07 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-21 02:49 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-21 10:17 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-21 16:30 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-21 12:54 -0700
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-22 15:56 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-19 17:22 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-19 21:01 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-19 20:46 +0100
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-19 20:47 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-19 21:49 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-20 11:42 +0200
Re: you think rust may outthrone c? "minf...@arcor.de" <minforth@arcor.de> - 2023-07-20 05:39 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-20 14:55 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-20 15:03 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-20 18:22 +0200
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-20 15:54 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-21 10:18 +0200
Re: you think rust may outthrone c? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-20 13:04 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-21 10:20 +0200
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-20 20:51 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-20 11:38 +0200
Re: you think rust may outthrone c? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-20 13:03 -0700
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-21 10:24 +0200
Re: you think rust may outthrone c? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-21 13:03 -0700
Re: you think rust may outthrone c? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-23 16:17 -0700
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-07-21 14:35 +0000
Re: you think rust may outthrone c? scott@slp53.sl.home (Scott Lurndal) - 2023-07-18 14:34 +0000
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-18 08:04 -0700
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-17 21:27 -0700
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-18 12:10 +0100
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-18 16:43 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-18 14:59 +0100
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-17 17:44 -0700
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-18 00:14 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-18 10:13 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-17 16:10 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-17 16:13 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-17 16:16 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-17 16:29 -0700
Yeah, C is harder than many programming languages. Your point? (Was: you think rust may outthrone c?) gazelle@shell.xmission.com (Kenny McCormack) - 2023-07-14 11:24 +0000
Re: Yeah, C is harder than many programming languages. Your point? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 11:30 +0000
Re: Yeah, C is harder than many programming languages. Your point? fir <profesor.fir@gmail.com> - 2023-07-14 05:20 -0700
Re: Yeah, C is harder than many programming languages. Your point? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 12:29 +0000
Re: Yeah, C is harder than many programming languages. Your point? fir <profesor.fir@gmail.com> - 2023-07-14 05:46 -0700
Re: Yeah, C is harder than many programming languages. Your point? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 13:01 +0000
Re: Yeah, C is harder than many programming languages. Your point? fir <profesor.fir@gmail.com> - 2023-07-14 06:07 -0700
Re: Yeah, C is harder than many programming languages. Your point? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 13:26 +0000
Why not? (Was: Yeah, C is harder than many programming languages. Your point?) gazelle@shell.xmission.com (Kenny McCormack) - 2023-07-14 13:32 +0000
Re: Why not? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 13:43 +0000
Re: Why not? (killfiles) gazelle@shell.xmission.com (Kenny McCormack) - 2023-07-14 14:10 +0000
Re: Why not? (killfiles) kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 14:28 +0000
Re: Why not? (killfiles) gazelle@shell.xmission.com (Kenny McCormack) - 2023-07-14 18:46 +0000
Re: Yeah, C is harder than many programming languages. Your point? fir <profesor.fir@gmail.com> - 2023-07-14 06:52 -0700
Re: Yeah, C is harder than many programming languages. Your point? fir <profesor.fir@gmail.com> - 2023-07-15 02:21 -0700
Re: Yeah, C is harder than many programming languages. Your point? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-07-14 09:14 -0400
Posting for our own amusement (Was: Yeah, C is harder than many programming languages. Your point?) gazelle@shell.xmission.com (Kenny McCormack) - 2023-07-14 13:29 +0000
Re: Posting for our own amusement (Was: Yeah, C is harder than many programming languages. Your point?) "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-07-14 07:26 -0700
Re: Posting for our own amusement (Was: Yeah, C is harder than many programming languages. Your point?) gazelle@shell.xmission.com (Kenny McCormack) - 2023-07-14 14:39 +0000
Re: Posting for our own amusement (Was: Yeah, C is harder than many programming languages. Your point?) David Brown <david.brown@hesbynett.no> - 2023-07-14 17:30 +0200
Re: Posting for our own amusement (Was: Yeah, C is harder than many programming languages. Your point?) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-14 20:53 +0000
Re: Yeah, C is harder than many programming languages. Your point? fir <profesor.fir@gmail.com> - 2023-07-14 06:30 -0700
Re: Yeah, C is harder than many programming languages. Your point? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 13:30 +0000
Re: Yeah, C is harder than many programming languages. Your point? gazelle@shell.xmission.com (Kenny McCormack) - 2023-07-14 12:29 +0000
Re: Yeah, C is harder than many programming languages. Your point? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 12:46 +0000
Re: Yeah, C is harder than many programming languages. Your point? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-14 20:46 +0000
Re: Yeah, C is harder than many programming languages. Your point? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 21:49 +0000
Re: you think rust may outthrone c? Po Lu <luangruo@yahoo.com> - 2023-07-14 20:52 +0800
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 13:16 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-14 17:34 +0200
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 16:20 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-14 19:11 +0200
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 17:26 +0000
Re: you think rust may outthrone c? Paul N <gw7rib@aol.com> - 2023-07-15 04:42 -0700
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-15 12:29 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-15 18:40 +0200
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-20 19:05 -0700
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-14 21:25 +0000
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 22:30 +0000
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-14 15:48 -0700
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 22:56 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-15 14:41 +0200
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-15 12:55 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-15 18:46 +0200
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-15 17:28 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-15 20:20 +0200
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-15 18:42 +0000
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-22 06:46 -0700
Re: you think rust may outthrone c? Po Lu <luangruo@yahoo.com> - 2023-07-15 14:12 +0800
Re: you think rust may outthrone c? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-15 01:05 -0700
Re: you think rust may outthrone c? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-20 18:54 -0700
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-15 08:59 +0000
Re: you think rust may outthrone c? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-07-17 02:26 -0400
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-14 20:43 +0000
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 21:58 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-14 09:32 +0200
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-14 07:58 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-14 12:56 +0200
OT Re: you think rust may outthrone c? jak <nospam@please.ty> - 2023-07-14 10:20 +0200
Re: you think rust may outthrone c? Po Lu <luangruo@yahoo.com> - 2023-07-14 20:48 +0800
Re: you think rust may outthrone c? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-07-17 18:33 +0300
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-17 20:47 +0100
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-17 21:14 +0100
Re: you think rust may outthrone c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-17 21:47 +0100
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-17 18:26 +0200
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-17 17:00 +0000
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-17 20:03 +0200
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-17 20:28 +0000
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-19 18:06 +0200
Re: you think rust may outthrone c? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-17 11:42 -0700
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-17 19:18 +0000
Re: you think rust may outthrone c? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-17 12:20 -0700
Re: you think rust may outthrone c? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-07-17 20:26 +0000
Re: you think rust may outthrone c? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-18 01:06 -0700
Re: you think rust may outthrone c? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2023-07-18 06:37 -0400
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-19 18:07 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-19 09:17 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-20 11:06 +0200
Re: you think rust may outthrone c? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2023-07-19 19:16 -0400
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-20 11:07 +0200
Re: you think rust may outthrone c? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2023-07-20 08:49 -0400
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-20 16:25 +0200
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-20 19:48 +0200
Re: you think rust may outthrone c? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2023-07-21 02:06 -0400
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-21 09:32 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-21 06:06 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-21 06:13 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 14:57 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 07:10 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 16:29 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 07:33 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 16:35 +0200
Re: you think rust may outthrone c? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2023-07-22 01:30 -0400
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 15:00 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-22 14:53 +0100
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 07:22 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 16:32 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 07:42 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 17:01 +0200
Re: you think rust may outthrone c? jak <nospam@please.ty> - 2023-07-22 17:45 +0200
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 18:22 +0200
Re: you think rust may outthrone c? jak <nospam@please.ty> - 2023-07-22 19:00 +0200
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 19:06 +0200
Re: you think rust may outthrone c? jak <nospam@please.ty> - 2023-07-22 19:34 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 14:15 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 14:20 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 14:25 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 14:33 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-23 03:23 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-23 03:28 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-22 16:48 +0100
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 18:24 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-22 19:02 +0100
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 20:06 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 14:07 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-23 03:29 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-23 00:52 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-23 02:03 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-23 02:18 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-23 13:44 +0200
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-23 13:43 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-23 05:03 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-23 05:07 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-23 05:14 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-23 05:54 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-23 05:31 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-23 05:42 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-23 15:16 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-23 06:39 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-23 15:49 +0200
Re: you think rust may outthrone c? Bart <bc@freeuk.com> - 2023-07-23 14:56 +0100
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-23 16:11 +0200
Re: you think rust may outthrone c? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-23 14:34 +0000
Re: you think rust may outthrone c? David Brown <david.brown@hesbynett.no> - 2023-07-23 18:43 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 07:19 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 16:34 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 07:48 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 07:58 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 08:00 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 17:01 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 08:09 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 16:59 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 08:02 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 17:07 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 08:18 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 17:42 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 08:51 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 18:26 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 08:42 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 09:20 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 18:27 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 14:06 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-23 03:30 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-23 00:58 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-23 01:06 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-23 15:16 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-23 06:40 -0700
Re: you think rust may outthrone c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-22 08:49 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 08:57 -0700
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-22 09:01 -0700
Re: you think rust may outthrone c? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-22 18:30 +0200
Re: you think rust may outthrone c? fir <profesor.fir@gmail.com> - 2023-07-23 03:32 -0700
Page 15 of 49 — ← Prev page 1 … 13 14 [15] 16 17 … 49 Next page →
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-01 18:26 +0000 |
| Message-ID | <20230801104525.199@kylheku.com> |
| In reply to | #171507 |
On 2023-08-01, Bart <bc@freeuk.com> wrote: > On 01/08/2023 18:04, Kaz Kylheku wrote: > > On 2023-08-01, Bart <bc@freeuk.com> wrote: > All this is beating about the bush. Either gcc is a program intended to > be used directly from a command line or it's not. Mostly, it isn't. > You shouldn't need DIY workarounds just to get it to do its basic job, "make prog" isn't a DIY workaround; it's an IEEE standard workaround. > or use alternates like make which have their own problems. "make" and "cc" are part of the same standard environment. Unix has had make since the 1970's and used it for most of the C compiling. It's part and parcel of one system. > I mean, why doesn't gcc just implement your 'gcc -o $1 $1.c' suggestion? Someone in this thread remarked how even Clang and Zig cc have to imitate the behavior in order to drop in. So that's the reason gcc cannot just implement the suggestion. Just like clang has to be a drop-in for gcc, new gcc has to be a drop-in for old gcc. If the gcc command changed the default name `a.out` to something else, it would break all build systems which happen to rely on that behavior. In the first place, gcc itself took on that convention in order to be a drop-in for Unix cc. Stallman wasn't crazy about Unix! He really wanted a Lisp machine. But Unix was the proprietary software that people were using, that had to be replaced with free software, in his view, and replacing requires playing the compatibility game. So, for instance, Bash had all the dumb whitespace and escaping issues as the Bourne shell. GNU went with shit-for-shit compatibility with Unix; but at least they tried to make the tools internally more robust to bad inputs, and extended them with useful features. So, there is no way something like "gcc foo.c" producing ./foo could be merged. A remote possibility would be that gcc can be installed under an alias like gccp (gcc, make program). Where if gcc sees that it is invoked under that name, it auto-configures the -o option. gccp would likely be rejected as something that can just be a shell script wrapper that you can develop as a separate project. GCC is FOSS, so you can contribute that, if it bothers you. However, it's a difficult project to get into. I developed a useful (IMHO) extension to GCC's preprocessor in April 2022 and posted that to the GCC mailing list. My patch included documentation and test cases; all the homework was done. I never received a reply. I pinged several times in the ensuing months, then gave up on it. If you disagree with the design of the gcc command line, a productive way to do something about it would be to develop a wrapper, say one called "wcc". If enough users share your views, they will widely install wcc, and people will start building their stuff through it. It could just be a single file shell script. "wcc" could examine its own name and look for the real compiler accordingly, so that if it were installed as "wcc-arm-gnu-linux", it will massage the arguments and hand them off to "gcc-arm-gnu-linux". -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-01 19:18 +0200 |
| Message-ID | <uabeq1$3nigh$1@dont-email.me> |
| In reply to | #171497 |
On 01/08/2023 16:41, Bart wrote: > > On 01/08/2023 14:00, David Brown wrote: > > On 27/07/2023 18:18, Bart wrote: > >> It either won't work, or will result in programs that are not as > >> efficient as expected, because that tightly crafted struct now takes > >> up 16 bytes rather than 8 (and on Win64 is passed by reference rather > >> than by value): > > > Efficiency (or lack thereof) is not an issue. I would expect that > > changing to 64-bit int will make some code more efficient (on 64-bit > > platforms), and some code less efficient. Whether it works or not is > > the crucial issue. > > > > (I still would like to hear examples of reasonably likely situations > > where changing "int" to 64-bit would stop code from working correctly. > > OK, let's try it. I took one of my generated C files which had these two > typedefs at the start: > >    typedef int               i32; >    typedef unsigned int      u32; > > I changed them to: > >    typedef long long         i32; >    typedef unsigned long long u32; > > Then I recompiled the 40Kloc file (it was an interpreter) and tried to > run a script; it crashed. I can't say I was surprised: there are plenty > of unions where the relations between the elements have to be exact. > So we have an example of one single program that has trouble when the size-specific 32-bit type is changed to 64 bits. No one doubted that some programs would have trouble. And I think people using a type named "i32" would do so with a much stronger assumption about the type's size than when using "int". I am still waiting for a justification that /half/ the C programs in existence would have trouble when /int/ is changed to 64 bits (no one suggests changing int32_t). And I am still waiting for examples of what you think (or know) is likely to go wrong. > (At first I though it had worked, but I'd forgotten gcc's moronic habit > of naming output files as a.exe, so I was running prog.exe instead, an > existing working version.) > If only the tool came with instructions, you might have had a way to learn after only a decade or so of use. > > >> The main Win64 ABI reference doesn't assign type names to the > >> 1-2-4-8-byte sizes that are passed in GP registers, but where it does, > >> then C's 'int' is a minor part of it: > >> > >> > https://learn.microsoft.com/en-us/cpp/build/x64-software-conventions?view=msvc-170 > > > > > That says that C "int" is 32-bit for the Win64 ABI.  (Calling > > conventions are only part of an ABI.) > > It also says that a 32-bit type is called "long" and "INT32" as well as > "int". > It says that C "long" and C "int" are both 32 bits - it does not say they are the same type in C (they are not - even if the sizes are the same). > I doubt that purpose of this chart is to define what "int" is in C, but > what is clear is that it expects it to be 32 bits. It doesn't say what > version of C it has in mind. It also doesn't mention `long long` for 64 > bits, nor any of the `stdint.h` types. > MS has always been famously poor at this kind of thing, and their ABI is the least well defined of any platform I have seen. > > > > Other languages start from scratch, and pick names they like based on > > the style of the language. > > And they like i32 etc. They DON'T like int32_t otherwise they'd all be > using them! As I said - languages use a style that suits the language. "int32_t" might seem very out of place in Zig, just as "int32" might seem inconsistent with many of the other types in C. And if you look at other languages, you will see type names such as "Int64.int", "INTEGER_64", "BINARY-DOUBLE SIGNED", "range -2**31 .. 2**31 - 1", "BigInt", all according to what suits the language. > C users have to like it or lump it; they are not allowed to > use typedefs. Of course they are /allowed/ to use typedefs. But silly little "typedef int32_t int32;" typedefs are not recommended by any serious programmer without a good reason (such as compatibility with existing code). > > > The use of a "_t" suffix for types has been traditional in C and *nix > > long before C99. It seems an obvious and consistent choice to make when > > the types were standardised in C99. > Obviously not in the Linux kernel. The Linux kernel is written in C - it does not define the language. > > Other languages don't have the same history, and use type names that > > match the style of those languages - sometimes longer, sometimes > > shorter, sometimes imported (as in C), sometimes built-in, sometimes > > with particular capitalisation, sometimes with implicit fixed sizes, > > sometimes explicit sizes, sometimes sizes that vary with the platform or > > target. > > > > You seem to have this belief that /only/ C uses the style "int32_t", and > > every other language uses "int32" or "i32". That's just nonsense. > > I gave a list of about 10 different languages that use variations of > `int32`, `i32`, `int` (when it is a fixed 32-bit type), but none that > have anything like that funny _t suffix, and I think none where those > types are unknown to the language unless you specifically import some > module. Stop cherry picking. <https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(basic_instructions)#Integers> Lots of languages require a module import, or equivalent, to access size-specific types. This applies especially to higher level languages that don't have much use for such types. > > So which languages other than C and C++ use `int32_t`? > The ones I know of are related to C (such as Objective C). The _t suffix in C is primarily historical. I don't think it would be likely to be useful in newer languages, without the history of C. Different languages have different styles for this kind of thing. I am not (and never have) argued that "int32_t" and similar is superior to "int32". But it is definitely superior (IMHO) to minimalist names like "i32". I am merely arguing that it is not worse - it really is not the kind of horror story you seem to imagine, and there is no evidence to suggest that there exists any kind of widespread dislike for the name, either amongst C programmers or other programmers. (There is plenty of dislike for the implementation-dependent nature of the standard integer types in C, though often when people insist they want fixed size types, they don't actually need them.) > What would you think of C allowing people to write `char_t` and `int_t` > as well as `char` and `int`, just for consistency; do you think that > suffix brings anything to the table? > > And if not, what does in bring in the case of `int32_t`? It's evident > the `_t` only existes to avoid clashing with existing uses of `int32` (I > guess there was no problem with existing uses of `int32_t`!) > That is not "evident" at all. The names are only available if <stdint.h> is included, and therefore clashes with existing names is not an issue. Indeed, the C99 rationale describes that the names were picked to match existing usage. > > > > Equally, you seem to believe that C99 picked this style of naming to be > > awkward, or to annoy people who don't type well, or just to annoy you > > personally. > > Not me personally. It just seems a thing with C that, terrified of > making new keywords that look good and are easy to type but that might > clash with user identifiers, they introduce capitalisation, leading and > embedded underscores, and weird suffixes to make a new keyword so ugly > that nobody would have chosen it! > Other people view this as a professional decision to maintain compatibility and minimise the risk of conflicts between existing code bases and newer tools. Thus almost all keywords added to C have the style _Keyword - precisely because words of this style were reserved for this purpose and should not be found as user identifiers. Note that the <stdint.h> types are /not/ keywords, and that clearly newer C keywords and identifiers cannot be as "ugly" as you claim because they /were/ chosen. > > You also think nobody (except a few people in comp.lang.c) > > likes them, or even uses them. The reality, is, of course, that it was > > a considered decision based on a balance of many factors, and C > > programmers the world over are entirely happy with them. > > Did they have a choice? Yes. > > >> As I said, you will not be convinced, or will say it's a one-off. (Why > >> won't you be convinced? Is it that inconceivable that someone might > >> prefer a snappier, possibly more euphonious set of types for their > >> coding?) > >> > > > > I'd find your arguments a lot more convincing if you made an attempt to > > answer the question, or give justification for your opinions. We all > > know of a number of good reasons why size-specific typenames other than > > those in <stdint.h> are sometimes used in C programming. > > I can't win because for every example I can find, you will bring up the > possibility that it might be linked to the availability of stdint.h or > to make it independent of stdint.h. > You could "win" by trying to answer the question - or at least, by trying to understand it. > What would an example look like that would satisfy you that someone is > creating a snappier typedef alias for purely aesthetic, ergonomic or > other reasons than the ones you listed? How can you tell from the bare > typedef what the reason is? > You are the one that has claimed people (other than you) find the <stdint.h> names so ugly and long-winded that they use typedefs to avoid them. All I want is for some justification or evidence to support such a claim. Use of names such as "int32" or "i32" for other reasons (such as pre-C99 historical reasons) is not relevant. Alternatively, simply accept that while it may be the case that some people find "int32_t" ugly, pretty much no one is particularly bothered, and programmers don't go out of their way to avoid the type name in their C coding when they want a size-specific type. > > > I listed the > > main ones (as far as I see them). You have made claims that people use > > different typenames (in C programming) because the <stdint.h> names are > > ugly or long-winded. I have asked you to back up those claims. > > They ARE long-winded, although not as much as 'unsigned long long int`, > and they ARE ugly. > > I doubt that my views are that unique. For example: > > "A lot of good programmers do that and the reason given is that types in > stdint.h have ugly long names like uint32_t. "_t" thing rubs a lot of > people the wrong way so I am not surprised they change it to something > more pleasant. I like using uint64, int32 etc. but the convention where > it's u64, i32, f32, f64 is something I would get behind." > > (https://news.ycombinator.com/item?id=13061837, last comment) > Finally! A link that shows you are not unique in the world! > Note they talk about a 'convention', and 'a lot of good programmers do > that'. > "They", in this context, being "some guy on the internet", with all the authority that implies. But again, the top post is pointing out that defining your own fixed-size types is unnecessary when <stdint.h> exists. I think you will see a lot more support in saying "unsigned long long int" is long-winded (I'd use uint64_t instead) than claiming "uint64_t" is so much "uglier" than "uint64" that people use typedefs specifically to avoid it. You'll also see a lot of support for macros like PRI32i being ugly, but that is more an issue with printf-style formatting. (C23, you'll be pleased to hear, lets you use "%w32i" and "%w64u" for formatting int32_t and uint64_t values.) > >> BTW 1% is also the UK's contribution to global warming, where it is > >> considered a big deal. > >> > > > > So now you are comparing using "u64" to saving the planet. > > Actually I've just measured it: using the uint64_t instead of u64 etc > made the output 6.5% bigger. > You are right up there with Flash Gordon, saviour of the universe! > > >> In my generated code, casts involving these types are used VERY > >> extensively. For example, every `0` constant is written as `(i64)0`. > > > First off, that is usually a silly idea. > > Integer constants in the source language are 64 bits and need to be so > in the C. So, how would /you/ do it? Remember that 0L and 0LL (and 0UL > and 0ULL) do not have precisely defined widths on their types. > Why do you think you need a precisely defined width here? > And in what way would that be superior to just using a cast? > > >
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-01 17:41 +0000 |
| Message-ID | <ftbyM.419745$GMN3.375538@fx16.iad> |
| In reply to | #171506 |
David Brown <david.brown@hesbynett.no> writes: >On 01/08/2023 16:41, Bart wrote: >> >> On 01/08/2023 14:00, David Brown wrote: >> > On 27/07/2023 18:18, Bart wrote: >> >> It either won't work, or will result in programs that are not as >> >> efficient as expected, because that tightly crafted struct now takes >> >> up 16 bytes rather than 8 (and on Win64 is passed by reference rather >> >> than by value): >> >> > Efficiency (or lack thereof) is not an issue. I would expect that >> > changing to 64-bit int will make some code more efficient (on 64-bit >> > platforms), and some code less efficient. Whether it works or not is >> > the crucial issue. >> > >> > (I still would like to hear examples of reasonably likely situations >> > where changing "int" to 64-bit would stop code from working correctly. >> >> OK, let's try it. I took one of my generated C files which had these two >> typedefs at the start: >> >>    typedef int               i32; >>    typedef unsigned int      u32; >> >> I changed them to: >> >>    typedef long long         i32; >>    typedef unsigned long long u32; >> >> Then I recompiled the 40Kloc file (it was an interpreter) and tried to >> run a script; it crashed. I can't say I was surprised: there are plenty >> of unions where the relations between the elements have to be exact. >> > >So we have an example of one single program that has trouble when the >size-specific 32-bit type is changed to 64 bits. Moreover it was using type-punning, where all bets are off anyway.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-01 21:01 +0100 |
| Message-ID | <uabobj$3oias$1@dont-email.me> |
| In reply to | #171506 |
On 01/08/2023 18:18, David Brown wrote:
> On 01/08/2023 16:41, Bart wrote:
> If only the tool came with instructions, you might have had a way to
> learn after only a decade or so of use.
I don't use gcc that often. Most command line tools have sensible UIs,
I'd forgotten that gcc was so dumb.
Let's face it, if gcc had not had that quirk, would there have been a
million programmers clamouring for its introduction? I don't think so!
While do people feel the need to defend every stupid feature? Just admit
it was a bad idea which is still being perpetuated decades later.
> Stop cherry picking.
>
>
<https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(basic_instructions)#Integers>
That chart confirms what I said. It's only C, C++ and OK, Objective C
that use that form.
From the chart, C#, Java, Rust, Go, D, Swift, even F#, Scala and Raku,
use simple forms with single, tidy keywords and fixed sizes.
The chart leaves out Zig, Julia and Odin which I think were part of my
list.
That leaves some ancient languages like COBOL to support your claim.
My remarks were to do with languages that supported fixed-width integer
types, which are expected to be lower-level. I wouldn't have put COBOL
in that group ...
> Lots of languages require a module import, or equivalent, to access
> size-specific types. This applies especially to higher level languages
> that don't have much use for such types.
... or ones like Haskell. (I don't know which ones need the fundamental
types to be specifically requested, but I guess you do.)
> I am not (and never have) argued that "int32_t" and similar is superior
> to "int32". But it is definitely superior (IMHO) to minimalist names
> like "i32".
I do something which may be controversial: I allow both 'int32' and
'i32'! That allows for differing styles and preferences. It also makes
porting fragments of code either way a little easier.
Before you say that you shouldn't allow too much freedom, remember that
C allows 'int', 'signed int', 'int signed', 'signed', 'int32_t', and,
sometimes, 'long' (and 'signed long', 'long signed') for the same
machine type.
(It's a good thing we're not enumerating the variations of 'uint64_t'!)
> I am merely arguing that it is not worse - it really is not
> the kind of horror story you seem to imagine, and there is no evidence
> to suggest that there exists any kind of widespread dislike for the
> name, either amongst C programmers or other programmers.
That most languages have made tidier, snappier choices says quite a lot.
> That is not "evident" at all. The names are only available if
> <stdint.h> is included, and therefore clashes with existing names is not
> an issue. Indeed, the C99 rationale describes that the names were
> picked to match existing usage.
So, why did existing usage employ that '_t'?
> You could "win" by trying to answer the question - or at least, by
> trying to understand it.
Nobody can win because this is a matter of opinion. However, I don't
believe I know your actual opinion, as you seem happy to go along with
whatever ungainly syntax that C has decreed, and will defend that
against my view.
No number of contemporary languages that have made more pleasing choices
will convince you. In fact you have to dredge up examples from ancient
history to show that sometimes other languages have terrible syntax too!
> You are the one that has claimed people (other than you) find the
> <stdint.h> names so ugly and long-winded that they use typedefs to avoid
> them. All I want is for some justification or evidence to support such
> a claim.
In what form?
Use of names such as "int32" or "i32" for other reasons (such
> as pre-C99 historical reasons) is not relevant.
>
> Alternatively, simply accept that while it may be the case that some
> people find "int32_t" ugly, pretty much no one is particularly bothered,
Most people are happy to go along with `int32_t` like you are. Many
might have been happier with `int32` or `i32`. Some will go so far as to
define their own set of more pleasing and ergonomic types, and if they
know what's good for them, will keep that quiet.
A smaller number may be more vocal about it.
The tiny number who go on to create new languages will show how much
they love the C99 types by instead choosing something better!
> "They", in this context, being "some guy on the internet", with all the
> authority that implies.
The link I wanted was from Reddit proposing that everyone should get
behind using 'i8-i64' typedefs in C, but I couldn't locate it. I
remember it had quite a few upvotes.
> You'll also see a lot of support for macros like PRI32i being ugly, but
> that is more an issue with printf-style formatting. (C23, you'll be
> pleased to hear, lets you use "%w32i" and "%w64u" for formatting int32_t
> and uint64_t values.)
Nice. In my everyday language since 1981, I've had to use nothing at
all; the compiler already knows the the type of the expression it's
printing! I know, it's magic.
And in my C compiler since 2017, I can use "%?" format for any numeric type.
>> Actually I've just measured it: using the uint64_t instead of u64 etc
>> made the output 6.5% bigger.
>>
>
> You are right up there with Flash Gordon, saviour of the universe!
So, how big a percentage will make you take notice? This 6% reduction is
a no-brainer which can be achieved with no effort.
But sure, your attitude is typical. Take potential enhancements of 1 or
2% in a hundred different places, it all adds up. But each one on its
own seems pointless.
>> >> extensively. For example, every `0` constant is written as `(i64)0`.
>>
>> > First off, that is usually a silly idea.
>>
>> Integer constants in the source language are 64 bits and need to be so
>> in the C. So, how would /you/ do it? Remember that 0L and 0LL (and 0UL
>> and 0ULL) do not have precisely defined widths on their types.
>>
>
> Why do you think you need a precisely defined width here?
Because 1234 in the generated C is a 32-bit int type, but it represents
a 64-bit int type in the original source. It's unwise to leave it as the
wrong type.
In most cases it won't make a difference, as it will be coerced to the
right type thanks to neighbouring values, or as required for a function
call. Most expressions such as 1 << 33 will be reduced before they get
transpiled, but not all, so in those cases, 32-bit overflow can occur.
And suppose the generated C code looks like this first line:
printf("%lld\n", -335);
printf("%lld\n", (long long int)-335);
That first line outputs the wrong value. The second with the cast gets
it right.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-02 03:41 -0700 |
| Message-ID | <d124c512-5586-444e-9252-72e601502eaen@googlegroups.com> |
| In reply to | #171514 |
On Tuesday, 1 August 2023 at 21:02:11 UTC+1, Bart wrote: > > Before you say that you shouldn't allow too much freedom, remember that > C allows 'int', 'signed int', 'int signed', 'signed', 'int32_t', and, > sometimes, 'long' (and 'signed long', 'long signed') for the same > machine type. > Yes. Fundamentally we have simple reality. 8 bit, 16 bit, 32 bit or 64 bit integers, signed or unsigned. But C has made a vastly complicated pig's ear of it. You can add "size_t" to list of types which are often 32 bit. Then there's exotica such as int_fast32 _t. Which is often what you really want, but you seldom see it in real code.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-02 12:09 +0100 |
| Message-ID | <uaddgc$1lf7$1@dont-email.me> |
| In reply to | #171522 |
On 02/08/2023 11:41, Malcolm McLean wrote:
> On Tuesday, 1 August 2023 at 21:02:11 UTC+1, Bart wrote:
>>
>> Before you say that you shouldn't allow too much freedom, remember that
>> C allows 'int', 'signed int', 'int signed', 'signed', 'int32_t', and,
>> sometimes, 'long' (and 'signed long', 'long signed') for the same
>> machine type.
>>
> Yes. Fundamentally we have simple reality. 8 bit, 16 bit, 32 bit or
64 bit
> integers, signed or unsigned. But C has made a vastly complicated
> pig's ear of it. You can add "size_t" to list of types which are
often 32 bit.
> Then there's exotica such as int_fast32 _t. Which is often what you
really
> want, but you seldom see it in real code.
Every time I try to even count the possibilities, I get a different
result. My latest attempt gives 35 C types for those 8 machine types:
11 classic C types
8 u/intN_t
8 u/intfastN_t (I don't know exactly where N goes; I don't care!)
8 u/intleastN_t
The 11 is due to the superfluous 'long' which has the same size as
either `int' or 'long long', and the third variety of 'char'.
Here, as far as I know, all 35 are technically distinct, incompatible
types, except that in reality, 'int32_t' may be defined on top of 'int',
for example. This comes up if you try and use _Generic.
I haven't counted the different combinations of those types which need
multiple tokens to specify. For example, 'unsigned long long [int]' I
/think/ can be written in 15 different ways.
Plus I haven't included the plethora of auxiliary types:
intptr_t
uintptr_t
size_t
ssize_t
clock_t
time_t
offset_t
....
I always won't get into the details of how you print any of these myriad
types, or create a literal (sorry, constant) value suitable to
initialise any of those.
It's a complete joke. Yet, people here will seriously defend it.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-02 05:01 -0700 |
| Message-ID | <d7fcd0d6-c5a5-4229-87d5-98f3129c9572n@googlegroups.com> |
| In reply to | #171523 |
On Wednesday, 2 August 2023 at 12:09:16 UTC+1, Bart wrote: > On 02/08/2023 11:41, Malcolm McLean wrote: > > On Tuesday, 1 August 2023 at 21:02:11 UTC+1, Bart wrote: > >> > >> Before you say that you shouldn't allow too much freedom, remember that > >> C allows 'int', 'signed int', 'int signed', 'signed', 'int32_t', and, > >> sometimes, 'long' (and 'signed long', 'long signed') for the same > >> machine type. > >> > > Yes. Fundamentally we have simple reality. 8 bit, 16 bit, 32 bit or > 64 bit > > integers, signed or unsigned. But C has made a vastly complicated > > pig's ear of it. You can add "size_t" to list of types which are > often 32 bit. > > Then there's exotica such as int_fast32 _t. Which is often what you > really > > want, but you seldom see it in real code. > Every time I try to even count the possibilities, I get a different > result. My latest attempt gives 35 C types for those 8 machine types: > > 11 classic C types > 8 u/intN_t > 8 u/intfastN_t (I don't know exactly where N goes; I don't care!) > 8 u/intleastN_t > > The 11 is due to the superfluous 'long' which has the same size as > either `int' or 'long long', and the third variety of 'char'. > > Here, as far as I know, all 35 are technically distinct, incompatible > types, except that in reality, 'int32_t' may be defined on top of 'int', > for example. This comes up if you try and use _Generic. > > I haven't counted the different combinations of those types which need > multiple tokens to specify. For example, 'unsigned long long [int]' I > /think/ can be written in 15 different ways. > > Plus I haven't included the plethora of auxiliary types: > > intptr_t > uintptr_t > size_t > ssize_t > clock_t > time_t > offset_t > .... > > > I always won't get into the details of how you print any of these myriad > types, or create a literal (sorry, constant) value suitable to > initialise any of those. > > It's a complete joke. Yet, people here will seriously defend it. > I don't use any of them in the Baby X resource compiler. Audio samples are saved as "short", UTF-16 values as "unsigned short". If short isn't 16 bits, it might or might not work, but the chances it will work are good. If I used int16_t, it would break if short isn't 16 bits. And it would break if stdint.h isn't available. So that was an easy decision to make.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-08-02 17:04 +0100 |
| Message-ID | <87wmydv39y.fsf@bsb.me.uk> |
| In reply to | #171524 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Wednesday, 2 August 2023 at 12:09:16 UTC+1, Bart wrote: >> On 02/08/2023 11:41, Malcolm McLean wrote: >> > Then there's exotica such as int_fast32 _t. Which is often what you >> > really want, but you seldom see it in real code. > I don't use any of them in the Baby X resource compiler. Audio samples > are saved as "short", UTF-16 values as "unsigned short". If short > isn't 16 bits, it might or might not work, but the chances it will > work are good. If I used int16_t, it would break if short isn't 16 > bits. int16_t "breaks" if there is no such type, but I think such a type can exist even if short is not 16 bits. > And it would break if stdint.h isn't available. So that was an easy > decision to make. That rules out the type you probably want -- one of the types you say is often what is really wanted (int_least16_t). No wonder they are rarely seen in "real code" if people won't use them even after nearly a quarter of a century. Are you really limiting yourself to writing C90? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-02 09:10 -0700 |
| Message-ID | <c707dddd-c94e-47bf-9ae6-a8537d245ac1n@googlegroups.com> |
| In reply to | #171532 |
On Wednesday, 2 August 2023 at 17:05:14 UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.ar...@gmail.com> writes: > > > On Wednesday, 2 August 2023 at 12:09:16 UTC+1, Bart wrote: > >> On 02/08/2023 11:41, Malcolm McLean wrote: > > >> > Then there's exotica such as int_fast32 _t. Which is often what you > >> > really want, but you seldom see it in real code. > > I don't use any of them in the Baby X resource compiler. Audio samples > > are saved as "short", UTF-16 values as "unsigned short". If short > > isn't 16 bits, it might or might not work, but the chances it will > > work are good. If I used int16_t, it would break if short isn't 16 > > bits. > int16_t "breaks" if there is no such type, but I think such a type can > exist even if short is not 16 bits. > CHAR_BIT would have to be sixteen. > > And it would break if stdint.h isn't available. So that was an easy > > decision to make. > That rules out the type you probably want -- one of the types you say is > often what is really wanted (int_least16_t). No wonder they are rarely > seen in "real code" if people won't use them even after nearly a quarter > of a century. Are you really limiting yourself to writing C90? > It's best to restrict yourself to the conservative subset of C unless there is really a pressing reason to do otherwise. The Baby X resource compiler is designed for use with Baby X, but it might also find a niche in the toolchains of people writing for small embedded systems. Which might come with old or restricted C compilers.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-02 23:48 +0200 |
| Message-ID | <uaeivj$9urb$1@dont-email.me> |
| In reply to | #171533 |
On 02/08/2023 18:10, Malcolm McLean wrote: > On Wednesday, 2 August 2023 at 17:05:14 UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.ar...@gmail.com> writes: >> >>> On Wednesday, 2 August 2023 at 12:09:16 UTC+1, Bart wrote: >>>> On 02/08/2023 11:41, Malcolm McLean wrote: >> >>>>> Then there's exotica such as int_fast32 _t. Which is often what you >>>>> really want, but you seldom see it in real code. >>> I don't use any of them in the Baby X resource compiler. Audio samples >>> are saved as "short", UTF-16 values as "unsigned short". If short >>> isn't 16 bits, it might or might not work, but the chances it will >>> work are good. If I used int16_t, it would break if short isn't 16 >>> bits. >> int16_t "breaks" if there is no such type, but I think such a type can >> exist even if short is not 16 bits. >> > CHAR_BIT would have to be sixteen. No, compilers can have extended integer types. >>> And it would break if stdint.h isn't available. So that was an easy >>> decision to make. >> That rules out the type you probably want -- one of the types you say is >> often what is really wanted (int_least16_t). No wonder they are rarely >> seen in "real code" if people won't use them even after nearly a quarter >> of a century. Are you really limiting yourself to writing C90? >> > It's best to restrict yourself to the conservative subset of C unless there is > really a pressing reason to do otherwise. Utter drivel. It's best to use the C version, and subset thereof, that is suitable for writing good, clean code that gives efficient results and is likely to work fine for all platforms for which the code is realistically going to be of interest. That pretty much /never/ means C90. All you do by choosing C90 is give worse quality source code, poorer efficiency in the generated code, and home-made half-arsed solutions for problems that were solved 25 years ago. > The Baby X resource compiler > is designed for use with Baby X, but it might also find a niche in the > toolchains of people writing for small embedded systems. Which > might come with old or restricted C compilers. > It will /never/ happen. So don't worry about it. And if you were /really/ interested in obscure and outdated embedded tools (and some of these are still in use), you might have tried to learn a little about them - or ask someone who knows. They'd have explained the difference between compilers for code running on the target devices, and compilers for code running on host systems.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-02 15:25 -0700 |
| Message-ID | <27a833dc-67b7-4195-a3f5-8d8c60ad3d2fn@googlegroups.com> |
| In reply to | #171554 |
On Wednesday, 2 August 2023 at 22:48:49 UTC+1, David Brown wrote: > On 02/08/2023 18:10, Malcolm McLean wrote: > > On Wednesday, 2 August 2023 at 17:05:14 UTC+1, Ben Bacarisse wrote: > >> Malcolm McLean <malcolm.ar...@gmail.com> writes: > >> > >>> On Wednesday, 2 August 2023 at 12:09:16 UTC+1, Bart wrote: > >>>> On 02/08/2023 11:41, Malcolm McLean wrote: > >> > >>>>> Then there's exotica such as int_fast32 _t. Which is often what you > >>>>> really want, but you seldom see it in real code. > >>> I don't use any of them in the Baby X resource compiler. Audio samples > >>> are saved as "short", UTF-16 values as "unsigned short". If short > >>> isn't 16 bits, it might or might not work, but the chances it will > >>> work are good. If I used int16_t, it would break if short isn't 16 > >>> bits. > >> int16_t "breaks" if there is no such type, but I think such a type can > >> exist even if short is not 16 bits. > >> > > CHAR_BIT would have to be sixteen. > No, compilers can have extended integer types. > >>> And it would break if stdint.h isn't available. So that was an easy > >>> decision to make. > >> That rules out the type you probably want -- one of the types you say is > >> often what is really wanted (int_least16_t). No wonder they are rarely > >> seen in "real code" if people won't use them even after nearly a quarter > >> of a century. Are you really limiting yourself to writing C90? > >> > > It's best to restrict yourself to the conservative subset of C unless there is > > really a pressing reason to do otherwise. > Utter drivel. > > It's best to use the C version, and subset thereof, that is suitable for > writing good, clean code that gives efficient results and is likely to > work fine for all platforms for which the code is realistically going to > be of interest. That pretty much /never/ means C90. All you do by > choosing C90 is give worse quality source code, poorer efficiency in the > generated code, and home-made half-arsed solutions for problems that > were solved 25 years ago. > Efficiency in the resource compiler itself hardly matters. I tested the string tag on a 100,000 word novel, and it came back instantly. The string also compiled and printed out. Efficiency in the output code matters, but the vast majority of it is static data. > > The Baby X resource compiler > > is designed for use with Baby X, but it might also find a niche in the > > toolchains of people writing for small embedded systems. Which > > might come with old or restricted C compilers. > > > It will /never/ happen. So don't worry about it. > > And if you were /really/ interested in obscure and outdated embedded > tools (and some of these are still in use), you might have tried to > learn a little about them - or ask someone who knows. They'd have > explained the difference between compilers for code running on the > target devices, and compilers for code running on host systems. > The Baby X resource compiler, as the name implies, is primarily intended for use with Baby X. Baby X uses int to represent integral values, double to represent real values, unsigned char to represent arbitrary binary data, and char * to represent strings. There's no advantage in using other types, except that now I'm adding audio, the PCM data will be represented by a short. However I took the decision to separate the resource compiler from Baby X so it could be used as an independent program by non-Baby X users. Who those would be I don't know. The big platforms come with monolithic buold systems which include resource compilers, and for various reasons it's not easy to avoid the use of the resource compiler. So I'm guessing small embedded systems. But I can't exactly take a job doing embedded programming just to get more experience for building the resource compiler. The output files from the Baby X resource compiler should compile under pretty much any C compiler out there, however. The Baby X resource compiler itself should also compile cleanly and easily under any hosted system. That's also an important goal.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-03 11:42 +0200 |
| Message-ID | <uafsqe$mtv7$1@dont-email.me> |
| In reply to | #171557 |
On 03/08/2023 00:25, Malcolm McLean wrote: > On Wednesday, 2 August 2023 at 22:48:49 UTC+1, David Brown wrote: >> On 02/08/2023 18:10, Malcolm McLean wrote: >>> On Wednesday, 2 August 2023 at 17:05:14 UTC+1, Ben Bacarisse wrote: >>>> Malcolm McLean <malcolm.ar...@gmail.com> writes: >>>> >>>>> On Wednesday, 2 August 2023 at 12:09:16 UTC+1, Bart wrote: >>>>>> On 02/08/2023 11:41, Malcolm McLean wrote: >>>> >>>>>>> Then there's exotica such as int_fast32 _t. Which is often what you >>>>>>> really want, but you seldom see it in real code. >>>>> I don't use any of them in the Baby X resource compiler. Audio samples >>>>> are saved as "short", UTF-16 values as "unsigned short". If short >>>>> isn't 16 bits, it might or might not work, but the chances it will >>>>> work are good. If I used int16_t, it would break if short isn't 16 >>>>> bits. >>>> int16_t "breaks" if there is no such type, but I think such a type can >>>> exist even if short is not 16 bits. >>>> >>> CHAR_BIT would have to be sixteen. >> No, compilers can have extended integer types. >>>>> And it would break if stdint.h isn't available. So that was an easy >>>>> decision to make. >>>> That rules out the type you probably want -- one of the types you say is >>>> often what is really wanted (int_least16_t). No wonder they are rarely >>>> seen in "real code" if people won't use them even after nearly a quarter >>>> of a century. Are you really limiting yourself to writing C90? >>>> >>> It's best to restrict yourself to the conservative subset of C unless there is >>> really a pressing reason to do otherwise. >> Utter drivel. >> >> It's best to use the C version, and subset thereof, that is suitable for >> writing good, clean code that gives efficient results and is likely to >> work fine for all platforms for which the code is realistically going to >> be of interest. That pretty much /never/ means C90. All you do by >> choosing C90 is give worse quality source code, poorer efficiency in the >> generated code, and home-made half-arsed solutions for problems that >> were solved 25 years ago. >> > Efficiency in the resource compiler itself hardly matters. I tested the string > tag on a 100,000 word novel, and it came back instantly. The string also > compiled and printed out. Efficiency in the output code matters, but the vast > majority of it is static data. Quality of source code /always/ matters, unless this is a small throw-away program. >>> The Baby X resource compiler >>> is designed for use with Baby X, but it might also find a niche in the >>> toolchains of people writing for small embedded systems. Which >>> might come with old or restricted C compilers. >>> >> It will /never/ happen. So don't worry about it. >> >> And if you were /really/ interested in obscure and outdated embedded >> tools (and some of these are still in use), you might have tried to >> learn a little about them - or ask someone who knows. They'd have >> explained the difference between compilers for code running on the >> target devices, and compilers for code running on host systems. >> > The Baby X resource compiler, as the name implies, is primarily intended > for use with Baby X. Baby X uses int to represent integral values, > double to represent real values, unsigned char to represent arbitrary > binary data, and char * to represent strings. There's no advantage in > using other types, except that now I'm adding audio, the PCM data will > be represented by a short. > None of this will ever be of the slightest use on a platform that does not have a good C99 compiler. > However I took the decision to separate the resource compiler from Baby X > so it could be used as an independent program by non-Baby X users. > Who those would be I don't know. The big platforms come with monolithic > buold systems which include resource compilers, and for various reasons > it's not easy to avoid the use of the resource compiler. So I'm guessing > small embedded systems. But I can't exactly take a job doing embedded > programming just to get more experience for building the resource > compiler. The output files from the Baby X resource compiler should > compile under pretty much any C compiler out there, however. > Don't base important design decisions on random guesses about things you are completely ignorant about. (Ignorance itself is not a problem - none of us know about all kinds of programming situations. It's basing decisions on ignorance that is the problem.) If you are running a shoe shop, you keep all your stock in pairs. You don't keep them in singles just in case one customer is missing a leg. > The Baby X resource compiler itself should also compile cleanly and easily > under any hosted system. That's also an important goal. > That is a completely pointless attitude. First, is there any indication that anyone has actually used the program? Does anyone who wants to use it, want to compile it? When I am looking for software, if I find a possible option and see it is written in ANSI C90, I assume it is some ancient and outdated tool. It /might/ still be useful, but I start with a big negative bias. (I am also biased against fad languages or obscure ones.) In reality, people are only ever going to use a "resource compiler" on two platforms - modern Linux, and modern Windows. And practically everyone who wants to use it would want a binary, not the source code (though having the source code available is also good). ".exe" format is more important to users than ANSI C format.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-04 02:15 -0700 |
| Message-ID | <a1194b2c-6fca-4067-8db0-315b4c4a0ec9n@googlegroups.com> |
| In reply to | #171565 |
On Thursday, 3 August 2023 at 10:42:53 UTC+1, David Brown wrote: > On 03/08/2023 00:25, Malcolm McLean wrote: > > On Wednesday, 2 August 2023 at 22:48:49 UTC+1, David Brown wrote: > >> On 02/08/2023 18:10, Malcolm McLean wrote: > >>> On Wednesday, 2 August 2023 at 17:05:14 UTC+1, Ben Bacarisse wrote: > >>>> Malcolm McLean <malcolm.ar...@gmail.com> writes: > >>>> > >>>>> On Wednesday, 2 August 2023 at 12:09:16 UTC+1, Bart wrote: > >>>>>> On 02/08/2023 11:41, Malcolm McLean wrote: > >>>> > >>>>>>> Then there's exotica such as int_fast32 _t. Which is often what you > >>>>>>> really want, but you seldom see it in real code. > >>>>> I don't use any of them in the Baby X resource compiler. Audio samples > >>>>> are saved as "short", UTF-16 values as "unsigned short". If short > >>>>> isn't 16 bits, it might or might not work, but the chances it will > >>>>> work are good. If I used int16_t, it would break if short isn't 16 > >>>>> bits. > >>>> int16_t "breaks" if there is no such type, but I think such a type can > >>>> exist even if short is not 16 bits. > >>>> > >>> CHAR_BIT would have to be sixteen. > >> No, compilers can have extended integer types. > >>>>> And it would break if stdint.h isn't available. So that was an easy > >>>>> decision to make. > >>>> That rules out the type you probably want -- one of the types you say is > >>>> often what is really wanted (int_least16_t). No wonder they are rarely > >>>> seen in "real code" if people won't use them even after nearly a quarter > >>>> of a century. Are you really limiting yourself to writing C90? > >>>> > >>> It's best to restrict yourself to the conservative subset of C unless there is > >>> really a pressing reason to do otherwise. > >> Utter drivel. > >> > >> It's best to use the C version, and subset thereof, that is suitable for > >> writing good, clean code that gives efficient results and is likely to > >> work fine for all platforms for which the code is realistically going to > >> be of interest. That pretty much /never/ means C90. All you do by > >> choosing C90 is give worse quality source code, poorer efficiency in the > >> generated code, and home-made half-arsed solutions for problems that > >> were solved 25 years ago. > >> > > Efficiency in the resource compiler itself hardly matters. I tested the string > > tag on a 100,000 word novel, and it came back instantly. The string also > > compiled and printed out. Efficiency in the output code matters, but the vast > > majority of it is static data. > Quality of source code /always/ matters, unless this is a small > throw-away program. > Quality matters. Efficiency often doesn't. For example I just encoded a function to "make comment". This takes a string, checks if it already has enclosing comment tags, if not adds them, then changes every internal closing comment tag into "^/" instead of "*/" (what can you do?). It duplicates the string twice. Of course it would be possible to add four bytes when loading the raw comment data, and never duplicate the string at all. But that would complicate the program condiderably, an dunless the user wants a comment several gigabytes long, on a modern machine it will make not difference at all to execution time. > >>> The Baby X resource compiler > >>> is designed for use with Baby X, but it might also find a niche in the > >>> toolchains of people writing for small embedded systems. Which > >>> might come with old or restricted C compilers. > >>> > >> It will /never/ happen. So don't worry about it. > >> > >> And if you were /really/ interested in obscure and outdated embedded > >> tools (and some of these are still in use), you might have tried to > >> learn a little about them - or ask someone who knows. They'd have > >> explained the difference between compilers for code running on the > >> target devices, and compilers for code running on host systems. > >> > > The Baby X resource compiler, as the name implies, is primarily intended > > for use with Baby X. Baby X uses int to represent integral values, > > double to represent real values, unsigned char to represent arbitrary > > binary data, and char * to represent strings. There's no advantage in > > using other types, except that now I'm adding audio, the PCM data will > > be represented by a short. > > > None of this will ever be of the slightest use on a platform that does > not have a good C99 compiler. > There's a value in cutting down the number of types the Baby X API uses. So we don't want some functions which take an integer taking :int", and others "size_t" and others "uint32_t" unless of course there's a pressing need for it. Which there is in a case of audio samples. Traditionally these are 16 bit, so I will use "short" for audio samples when audio is integrated into Baby X. But that's the only case where there is a pressing need for the API to take an integer type other than "int". (The other exception is BBX_RGBA which represents 24-bit color values, that's typedefed so the underlying type is opaque). > > > However I took the decision to separate the resource compiler from Baby X > > so it could be used as an independent program by non-Baby X users. > > Who those would be I don't know. The big platforms come with monolithic > > buold systems which include resource compilers, and for various reasons > > it's not easy to avoid the use of the resource compiler. So I'm guessing > > small embedded systems. But I can't exactly take a job doing embedded > > programming just to get more experience for building the resource > > compiler. The output files from the Baby X resource compiler should > > compile under pretty much any C compiler out there, however. > > > Don't base important design decisions on random guesses about things you > are completely ignorant about. (Ignorance itself is not a problem - > none of us know about all kinds of programming situations. It's basing > decisions on ignorance that is the problem.) > > If you are running a shoe shop, you keep all your stock in pairs. You > don't keep them in singles just in case one customer is missing a leg. > The Baby X resource compiler was developed was an anciliary program to Baby X. Just as Windows compilers come with a "resource compiler" which allow you to package images and other binaries, there's a need for a program which does a similar thing for Baby X. However in the event, the resource compiler is more popular than Baby X itself. It can be used by non-Baby X programmers. But who those would be and why they would wanrt it is a good question. > > > The Baby X resource compiler itself should also compile cleanly and easily > > under any hosted system. That's also an important goal. > > > That is a completely pointless attitude. > > First, is there any indication that anyone has actually used the > program? Does anyone who wants to use it, want to compile it? When I > am looking for software, if I find a possible option and see it is > written in ANSI C90, I assume it is some ancient and outdated tool. It > /might/ still be useful, but I start with a big negative bias. (I am > also biased against fad languages or obscure ones.) > There's regular traffic. Not huge. But obviously some people are interested. The problem is that you don't get much feedback. Whether these people are just aking the "loadimage" function for their own use, (which I don't mind), or using the resource compiler itself, I don't know, because they don't tell me. > > In reality, people are only ever going to use a "resource compiler" on > two platforms - modern Linux, and modern Windows. And practically > everyone who wants to use it would want a binary, not the source code > (though having the source code available is also good). ".exe" format > is more important to users than ANSI C format. > The users will be C programmers. But I took your advice and made a Windows executable available. One download so far.
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2023-08-04 14:20 +0000 |
| Message-ID | <X=vUTZgAAVQwBn6et@bongo-ra.co> |
| In reply to | #171565 |
On Thu, 3 Aug 2023 11:42:36 +0200 David Brown <david.brown@hesbynett.no> wrote: > When I > am looking for software, if I find a possible option and see it is > written in ANSI C90, I assume it is some ancient and outdated tool. It > /might/ still be useful, but I start with a big negative bias. That's a strange attitude. If it is written in "old" C then likely it was written a long time ago but it certainly doesn't follow that it is outdated. The venerable less pager is very much standard on Unix systems and it doesn't even use function prototypes (at least it didn't a few revisions ago , I haven't looked at the source code of the latest versions). I can think of a few more likely examples but I haven't looked at their source. Basically , if it works then hardly anyone will make it a priority to modify it for a newer version of C. -- Virtue, I discovered, in one way in which a human being may attempt to diminish and insult others. "Captive of Gor"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-04 17:12 +0200 |
| Message-ID | <uaj4gk$1alq7$1@dont-email.me> |
| In reply to | #171611 |
On 04/08/2023 16:20, Spiros Bousbouras wrote: > On Thu, 3 Aug 2023 11:42:36 +0200 > David Brown <david.brown@hesbynett.no> wrote: >> When I >> am looking for software, if I find a possible option and see it is >> written in ANSI C90, I assume it is some ancient and outdated tool. It >> /might/ still be useful, but I start with a big negative bias. > > That's a strange attitude. If it is written in "old" C then likely it > was written a long time ago but it certainly doesn't follow that it is > outdated. True, of course. For some things, old software is just as good as new software - if the task hasn't changed, the software does not need to change. But for other kinds of software you want to be sure that it is relatively modern, or at least well maintained. That might be for supporting newer formats (in the case of a "resource compiler"), or perhaps it is software for which security is a concern. The software might also be written for older and weaker compilers - using "tricks" that were popular before, but are undefined behaviour in C and can fail with modern compilers. Being in an ancient C dialect does not guarantee that it is outdated, but it is a pointer in that direction. I would also have no interest in a "resource compiler" that generated C files that did not use <stdint.h> or <stdbool.h> types when appropriate, but perpetuated the inconvenience of home-made types.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-04 08:20 -0700 |
| Message-ID | <cbe7d004-e90b-41d7-9a34-c711ef9c3949n@googlegroups.com> |
| In reply to | #171614 |
On Friday, 4 August 2023 at 16:12:39 UTC+1, David Brown wrote: > On 04/08/2023 16:20, Spiros Bousbouras wrote: > > On Thu, 3 Aug 2023 11:42:36 +0200 > > David Brown <david...@hesbynett.no> wrote: > >> When I > >> am looking for software, if I find a possible option and see it is > >> written in ANSI C90, I assume it is some ancient and outdated tool. It > >> /might/ still be useful, but I start with a big negative bias. > > > > That's a strange attitude. If it is written in "old" C then likely it > > was written a long time ago but it certainly doesn't follow that it is > > outdated. > True, of course. For some things, old software is just as good as new > software - if the task hasn't changed, the software does not need to > change. But for other kinds of software you want to be sure that it is > relatively modern, or at least well maintained. That might be for > supporting newer formats (in the case of a "resource compiler"), or > perhaps it is software for which security is a concern. The software > might also be written for older and weaker compilers - using "tricks" > that were popular before, but are undefined behaviour in C and can fail > with modern compilers. Being in an ancient C dialect does not guarantee > that it is outdated, but it is a pointer in that direction. > > I would also have no interest in a "resource compiler" that generated C > files that did not use <stdint.h> or <stdbool.h> types when appropriate, > but perpetuated the inconvenience of home-made types. > It doesn't output homemade types like "u8" for a char. But it doesn't use <stdint.h> or <stdbool.h> types either. It outputs the basic C types. That's because it was orignally designed for use with Baby X, which doesn't use <stdint.h" or <stdbool.h> types in its API interface. But I could add a flag to the resource compiler to output <stdint.h> known width types if people think that that's important.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-04 18:04 +0200 |
| Message-ID | <uaj7iv$1b5h7$1@dont-email.me> |
| In reply to | #171616 |
On 04/08/2023 17:20, Malcolm McLean wrote: > On Friday, 4 August 2023 at 16:12:39 UTC+1, David Brown wrote: >> On 04/08/2023 16:20, Spiros Bousbouras wrote: >>> On Thu, 3 Aug 2023 11:42:36 +0200 >>> David Brown <david...@hesbynett.no> wrote: >>>> When I >>>> am looking for software, if I find a possible option and see it is >>>> written in ANSI C90, I assume it is some ancient and outdated tool. It >>>> /might/ still be useful, but I start with a big negative bias. >>> >>> That's a strange attitude. If it is written in "old" C then likely it >>> was written a long time ago but it certainly doesn't follow that it is >>> outdated. >> True, of course. For some things, old software is just as good as new >> software - if the task hasn't changed, the software does not need to >> change. But for other kinds of software you want to be sure that it is >> relatively modern, or at least well maintained. That might be for >> supporting newer formats (in the case of a "resource compiler"), or >> perhaps it is software for which security is a concern. The software >> might also be written for older and weaker compilers - using "tricks" >> that were popular before, but are undefined behaviour in C and can fail >> with modern compilers. Being in an ancient C dialect does not guarantee >> that it is outdated, but it is a pointer in that direction. >> >> I would also have no interest in a "resource compiler" that generated C >> files that did not use <stdint.h> or <stdbool.h> types when appropriate, >> but perpetuated the inconvenience of home-made types. >> > It doesn't output homemade types like "u8" for a char. But it doesn't use > <stdint.h> or <stdbool.h> types either. It outputs the basic C types. That would be useless. Few people doing embedded work have any interest in something that turns resources (such as files to be embedded) into arrays of "short" or "unsigned long". Use "int16_t", "uint32_t", or whatever matches the resource type. This can be done in a dozen lines of Python scripting, and I get exactly what I need. I do so regularly for embedded bitmaps, or static files for an embedded webserver, and that kind of thing. > > That's because it was orignally designed for use with Baby X, which > doesn't use <stdint.h" or <stdbool.h> types in its API interface. > But I could add a flag to the resource compiler to output <stdint.h> > known width types if people think that that's important. > I think it is. But I doubt if it will be a big hit with embedded programmers anyway.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-04 09:17 -0700 |
| Message-ID | <2caab55a-f70e-457f-a4d2-ee912c27b681n@googlegroups.com> |
| In reply to | #171618 |
On Friday, 4 August 2023 at 17:05:05 UTC+1, David Brown wrote: > On 04/08/2023 17:20, Malcolm McLean wrote: > > On Friday, 4 August 2023 at 16:12:39 UTC+1, David Brown wrote: > >> On 04/08/2023 16:20, Spiros Bousbouras wrote: > >>> On Thu, 3 Aug 2023 11:42:36 +0200 > >>> David Brown <david...@hesbynett.no> wrote: > >>>> When I > >>>> am looking for software, if I find a possible option and see it is > >>>> written in ANSI C90, I assume it is some ancient and outdated tool. It > >>>> /might/ still be useful, but I start with a big negative bias. > >>> > >>> That's a strange attitude. If it is written in "old" C then likely it > >>> was written a long time ago but it certainly doesn't follow that it is > >>> outdated. > >> True, of course. For some things, old software is just as good as new > >> software - if the task hasn't changed, the software does not need to > >> change. But for other kinds of software you want to be sure that it is > >> relatively modern, or at least well maintained. That might be for > >> supporting newer formats (in the case of a "resource compiler"), or > >> perhaps it is software for which security is a concern. The software > >> might also be written for older and weaker compilers - using "tricks" > >> that were popular before, but are undefined behaviour in C and can fail > >> with modern compilers. Being in an ancient C dialect does not guarantee > >> that it is outdated, but it is a pointer in that direction. > >> > >> I would also have no interest in a "resource compiler" that generated C > >> files that did not use <stdint.h> or <stdbool.h> types when appropriate, > >> but perpetuated the inconvenience of home-made types. > >> > > It doesn't output homemade types like "u8" for a char. But it doesn't use > > <stdint.h> or <stdbool.h> types either. It outputs the basic C types. > That would be useless. Few people doing embedded work have any interest > in something that turns resources (such as files to be embedded) into > arrays of "short" or "unsigned long". Use "int16_t", "uint32_t", or > whatever matches the resource type. > > This can be done in a dozen lines of Python scripting, and I get exactly > what I need. I do so regularly for embedded bitmaps, or static files > for an embedded webserver, and that kind of thing. > Yes, pretty much every C programmer has written a scratch program to read in a binary and output C source. I can't find a tool that allows you to get away from that, except the Baby X resource compiler. Whether that is bad thing, meaning there's no demand for such a tool, or a good thing, meaning it has a niche no-one else has thought of, I don't know. > > > > That's because it was orignally designed for use with Baby X, which > > doesn't use <stdint.h" or <stdbool.h> types in its API interface. > > But I could add a flag to the resource compiler to output <stdint.h> > > known width types if people think that that's important. > > > I think it is. But I doubt if it will be a big hit with embedded > programmers anyway. > There's no reason for any of the data to be fixed size that I can think of. But what do I know.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-05 13:39 +0200 |
| Message-ID | <ualceb$1nnq7$1@dont-email.me> |
| In reply to | #171619 |
On 04/08/2023 18:17, Malcolm McLean wrote: > On Friday, 4 August 2023 at 17:05:05 UTC+1, David Brown wrote: >> On 04/08/2023 17:20, Malcolm McLean wrote: >>> On Friday, 4 August 2023 at 16:12:39 UTC+1, David Brown wrote: >>>> On 04/08/2023 16:20, Spiros Bousbouras wrote: >>>>> On Thu, 3 Aug 2023 11:42:36 +0200 >>>>> David Brown <david...@hesbynett.no> wrote: >>>>>> When I >>>>>> am looking for software, if I find a possible option and see it is >>>>>> written in ANSI C90, I assume it is some ancient and outdated tool. It >>>>>> /might/ still be useful, but I start with a big negative bias. >>>>> >>>>> That's a strange attitude. If it is written in "old" C then likely it >>>>> was written a long time ago but it certainly doesn't follow that it is >>>>> outdated. >>>> True, of course. For some things, old software is just as good as new >>>> software - if the task hasn't changed, the software does not need to >>>> change. But for other kinds of software you want to be sure that it is >>>> relatively modern, or at least well maintained. That might be for >>>> supporting newer formats (in the case of a "resource compiler"), or >>>> perhaps it is software for which security is a concern. The software >>>> might also be written for older and weaker compilers - using "tricks" >>>> that were popular before, but are undefined behaviour in C and can fail >>>> with modern compilers. Being in an ancient C dialect does not guarantee >>>> that it is outdated, but it is a pointer in that direction. >>>> >>>> I would also have no interest in a "resource compiler" that generated C >>>> files that did not use <stdint.h> or <stdbool.h> types when appropriate, >>>> but perpetuated the inconvenience of home-made types. >>>> >>> It doesn't output homemade types like "u8" for a char. But it doesn't use >>> <stdint.h> or <stdbool.h> types either. It outputs the basic C types. >> That would be useless. Few people doing embedded work have any interest >> in something that turns resources (such as files to be embedded) into >> arrays of "short" or "unsigned long". Use "int16_t", "uint32_t", or >> whatever matches the resource type. >> >> This can be done in a dozen lines of Python scripting, and I get exactly >> what I need. I do so regularly for embedded bitmaps, or static files >> for an embedded webserver, and that kind of thing. >> > Yes, pretty much every C programmer has written a scratch program > to read in a binary and output C source. I can't find a tool that allows you > to get away from that, except the Baby X resource compiler. Whether that > is bad thing, meaning there's no demand for such a tool, or a good thing, > meaning it has a niche no-one else has thought of, I don't know. I think most cases need nothing more than converting a single file into a const array of uint8_t (or unsigned char if you prefer). Anything other than that, and I would not expect a pre-written tool to support what you want because you are likely to have particular needs at the time. When I have embedded fonts, image sequences, directory structures, etc., they have always been targeting a particular format for the application - general purpose or third-party conversion tools would be of no use at all. Some graphics libraries come with "resource compilers" generating results in the format needed for the library. So if your "Baby X" has its own graphics format (or audio format), then a "resource compiler" turning standard formats into this internal format would make sense. But I fail to see how useful it would be for those not using "Baby X". I also can't imagine why anyone would want to put strings in an xml file instead of just putting them in the source code directly - it gives you no advantages. (If it organised strings and formats for internationalisation and translation, that would be a different matter.) So as I see it, "resource compiling" is either trivial, library-specific (in which case a resource compiler could be a useful program), or too specialised to be supportable by a general program. And C23 will cover the trivial case with "#embed". Of course, it will take some time for people to move to C23. >>> >>> That's because it was orignally designed for use with Baby X, which >>> doesn't use <stdint.h" or <stdbool.h> types in its API interface. >>> But I could add a flag to the resource compiler to output <stdint.h> >>> known width types if people think that that's important. >>> >> I think it is. But I doubt if it will be a big hit with embedded >> programmers anyway. >> > There's no reason for any of the data to be fixed size that I can think of. > But what do I know. > Embedded programmers like fixed sizes, even when they are not strictly necessary. I think it is critical to be very clear that the types you use are big enough to support the data and ranges you want. And in embedded systems, you never want to waste space without reason - so you want to be sure things are not bigger than they have to be. The ideal type choices are therefore "uint_least16_t" and similar "least" types from <stdint.h>. However, since the "least" types match the fixed size types in almost every case (and programming for targets that don't support 8-bit and 16-bit types directly is niche and dedicated work), the norm is to use "uint16_t" and similar fixed-size types.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-05 05:08 -0700 |
| Message-ID | <1aceef78-a719-424e-9234-63bc7531105cn@googlegroups.com> |
| In reply to | #171678 |
On Saturday, 5 August 2023 at 12:40:10 UTC+1, David Brown wrote: > On 04/08/2023 18:17, Malcolm McLean wrote: > > On Friday, 4 August 2023 at 17:05:05 UTC+1, David Brown wrote: > >> On 04/08/2023 17:20, Malcolm McLean wrote: > >>> On Friday, 4 August 2023 at 16:12:39 UTC+1, David Brown wrote: > >>>> On 04/08/2023 16:20, Spiros Bousbouras wrote: > >>>>> On Thu, 3 Aug 2023 11:42:36 +0200 > >>>>> David Brown <david...@hesbynett.no> wrote: > >>>>>> When I > >>>>>> am looking for software, if I find a possible option and see it is > >>>>>> written in ANSI C90, I assume it is some ancient and outdated tool. It > >>>>>> /might/ still be useful, but I start with a big negative bias. > >>>>> > >>>>> That's a strange attitude. If it is written in "old" C then likely it > >>>>> was written a long time ago but it certainly doesn't follow that it is > >>>>> outdated. > >>>> True, of course. For some things, old software is just as good as new > >>>> software - if the task hasn't changed, the software does not need to > >>>> change. But for other kinds of software you want to be sure that it is > >>>> relatively modern, or at least well maintained. That might be for > >>>> supporting newer formats (in the case of a "resource compiler"), or > >>>> perhaps it is software for which security is a concern. The software > >>>> might also be written for older and weaker compilers - using "tricks" > >>>> that were popular before, but are undefined behaviour in C and can fail > >>>> with modern compilers. Being in an ancient C dialect does not guarantee > >>>> that it is outdated, but it is a pointer in that direction. > >>>> > >>>> I would also have no interest in a "resource compiler" that generated C > >>>> files that did not use <stdint.h> or <stdbool.h> types when appropriate, > >>>> but perpetuated the inconvenience of home-made types. > >>>> > >>> It doesn't output homemade types like "u8" for a char. But it doesn't use > >>> <stdint.h> or <stdbool.h> types either. It outputs the basic C types. > >> That would be useless. Few people doing embedded work have any interest > >> in something that turns resources (such as files to be embedded) into > >> arrays of "short" or "unsigned long". Use "int16_t", "uint32_t", or > >> whatever matches the resource type. > >> > >> This can be done in a dozen lines of Python scripting, and I get exactly > >> what I need. I do so regularly for embedded bitmaps, or static files > >> for an embedded webserver, and that kind of thing. > >> > > Yes, pretty much every C programmer has written a scratch program > > to read in a binary and output C source. I can't find a tool that allows you > > to get away from that, except the Baby X resource compiler. Whether that > > is bad thing, meaning there's no demand for such a tool, or a good thing, > > meaning it has a niche no-one else has thought of, I don't know. > I think most cases need nothing more than converting a single file into > a const array of uint8_t (or unsigned char if you prefer). Anything > other than that, and I would not expect a pre-written tool to support > what you want because you are likely to have particular needs at the > time. When I have embedded fonts, image sequences, directory > structures, etc., they have always been targeting a particular format > for the application - general purpose or third-party conversion tools > would be of no use at all. > This is the problem of course. The Baby X API expects data in a certain format. So all the API functions which operate on images take a 32 bit RGBA buffer as an "unsigned char *", and the dimensions as two ints. But another API might use an opaque "IMAGE" structure. Or another system might have 16 bit r5g5b5a1 images. Of course I could put in a flexible format specifier. But it would rapidly turn into a scripting laugage in its onw right. In which case you might as well use Python. > > Some graphics libraries come with "resource compilers" generating > results in the format needed for the library. So if your "Baby X" has > its own graphics format (or audio format), then a "resource compiler" > turning standard formats into this internal format would make sense. > But I fail to see how useful it would be for those not using "Baby X". > Reality is that the resouce compiler is more popular than Baby X. But exactly how people are using it, I don't know > > I also can't imagine why anyone would want to put strings in an xml file > instead of just putting them in the source code directly - it gives you > no advantages. (If it organised strings and formats for > internationalisation and translation, that would be a different matter.) > There is an "international" tag so you can do this <international name = "hello"> <string language = "english">Hello</string> <string language = "french">Bonjour</string> <utf8 language = "chinese"> [utf8 here] </utf8> </international> Then it creates a C-callable function which is passed the languafe and returns thr right string. > > So as I see it, "resource compiling" is either trivial, library-specific > (in which case a resource compiler could be a useful program), or too > specialised to be supportable by a general program. > > And C23 will cover the trivial case with "#embed". Of course, it will > take some time for people to move to C23. > Yes. Whilst of course there is a <binary> tag to allow for the trivial case, that isn't the strength of the Baby X resource compiler. The strength is the ability to transform data from complex input formats to simple output formats. > > >>> > >>> That's because it was orignally designed for use with Baby X, which > >>> doesn't use <stdint.h" or <stdbool.h> types in its API interface. > >>> But I could add a flag to the resource compiler to output <stdint.h> > >>> known width types if people think that that's important. > >>> > >> I think it is. But I doubt if it will be a big hit with embedded > >> programmers anyway. > >> > > There's no reason for any of the data to be fixed size that I can think of. > > But what do I know. > > > Embedded programmers like fixed sizes, even when they are not strictly > necessary. I think it is critical to be very clear that the types you > use are big enough to support the data and ranges you want. And in > embedded systems, you never want to waste space without reason - so you > want to be sure things are not bigger than they have to be. The ideal > type choices are therefore "uint_least16_t" and similar "least" types > from <stdint.h>. However, since the "least" types match the fixed size > types in almost every case (and programming for targets that don't > support 8-bit and 16-bit types directly is niche and dedicated work), > the norm is to use "uint16_t" and similar fixed-size types. > I might add a flag for stdint.h types. Whilst it's fairly trivial in algorithmic terms, it complicates the output code quite a bit, and will make it harder for somone coming new to the program to modify.
[toc] | [prev] | [next] | [standalone]
Page 15 of 49 — ← Prev page 1 … 13 14 [15] 16 17 … 49 Next page →
Back to top | Article view | comp.lang.c
csiph-web