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 20 of 49 — ← Prev page 1 … 18 19 [20] 21 22 … 49 Next page →
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2023-08-10 16:59 +0000 |
| Subject | Re: Making accountants cross (wa Re: you think rust may outthrone c?) |
| Message-ID | <ub350r$cvgb$1@dont-email.me> |
| In reply to | #172027 |
On Thu, 10 Aug 2023 16:31:31 +0000, Kaz Kylheku wrote:
> On 2023-08-10, Vir Campestris <vir.campestris@invalid.invalid> wrote:
>> On 07/08/2023 17:05, Ben Bacarisse wrote:
>>> Hmm... With statically allocated strings, or using malloc and therefore
>>> requiring free call not shown?
>>>
>>> I would rather do this: anywhere a type is defined, I'd define a FMT_xxx
>>> macro:
>>>
>>> typedef float salary_t;
>>> #define FMT_SALARY "f"
>>>
>>> typedef unsigned long int payrollid_t;
>>> #define FMT_PAYROLLID "lu"
>>>
>>> so that one can write
>>>
>>> printf("Hello %s your salary is %" FMT_SALLARY
>>> ", your payrollid %" FMT_PAYROLLID "\n",
>>> employee.name, employee.salary, employee.payrollid);
>>>
>>> -- Ben.
>>
>> Ben, if you put floating points in money accountants get upset.
>>
>> Three employees are paid $100.00, so it adds up to $300.
>>
>> Deduct $20 from each, and it's $240.
>>
>> Use floating point and sooner or later it won't add up.
>
> Use floating-point *naively* and the truncation errors will accumulate
> to the point of making at least a one cent difference, screwing up the
> accounting.
>
> Use floating-point intelligently and that won't happen.
>
>> You can't have a third of a cent.
>
> That is neither here nor there.
>
> You can't have a third of a cent in accounting, because accounting is
> decimal based, at least with US dollars and similar currencies,
> where you don't have beasties like sixths of a dollar.
Actually, many currencies (including the US Dollar) allow for measurements
in the thousandths of a dollar, and such calculations are common in both
stock brokerage pricing (a broker may charge, say, 5 mils per share on
bulk trades, earning $5.00 for every 1000 shares bought/sold) and property
tax calculation.
> "Third of a cent" is a financial quantity nobody works with, in any
> representation of dollars.
Except for those who work with money as a commodity, stock brokers,
municipal property tax assessors, and a wide variety of others. Consider,
at this moment, I see that 1 Japanese Yen will buy 0.0069 US Dollars.
How inconvenient would it be if programmers just took the position that
there are no fractions of a US dollar lower than 1 cent, and that 1 Yen,
therefore, purchases $0.00 USD?
> And even if they did, floating point
> could handle it just fine, if everyone agreed that around 15
> digits of precision is good enough.
For very small and very large sums of money, most banking systems
will stay /very/ far away from floatingpoint in any form. Better
to do (expensive) fixed-precision math and get exact answers than
to do (cheaper) floatingpoint math and get the final /financial/
answer wrong. That's how banks fail, and programmers get rich
from rounding errors (watch the movie "Office Space").
[snip]
--
Lew Pitcher
A retired programmer/analyst/architect for a large Canadian bank
"In Skills We Trust"
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-08-10 11:13 -0700 |
| Subject | Re: Making accountants cross (wa Re: you think rust may outthrone c?) |
| Message-ID | <ub39cl$ev2j$4@dont-email.me> |
| In reply to | #172033 |
On 8/10/2023 9:59 AM, Lew Pitcher wrote:
> On Thu, 10 Aug 2023 16:31:31 +0000, Kaz Kylheku wrote:
>
>> On 2023-08-10, Vir Campestris <vir.campestris@invalid.invalid> wrote:
>>> On 07/08/2023 17:05, Ben Bacarisse wrote:
>>>> Hmm... With statically allocated strings, or using malloc and therefore
>>>> requiring free call not shown?
>>>>
>>>> I would rather do this: anywhere a type is defined, I'd define a FMT_xxx
>>>> macro:
>>>>
>>>> typedef float salary_t;
>>>> #define FMT_SALARY "f"
>>>>
>>>> typedef unsigned long int payrollid_t;
>>>> #define FMT_PAYROLLID "lu"
>>>>
>>>> so that one can write
>>>>
>>>> printf("Hello %s your salary is %" FMT_SALLARY
>>>> ", your payrollid %" FMT_PAYROLLID "\n",
>>>> employee.name, employee.salary, employee.payrollid);
>>>>
>>>> -- Ben.
>>>
>>> Ben, if you put floating points in money accountants get upset.
>>>
>>> Three employees are paid $100.00, so it adds up to $300.
>>>
>>> Deduct $20 from each, and it's $240.
>>>
>>> Use floating point and sooner or later it won't add up.
>>
>> Use floating-point *naively* and the truncation errors will accumulate
>> to the point of making at least a one cent difference, screwing up the
>> accounting.
>>
>> Use floating-point intelligently and that won't happen.
>>
>>> You can't have a third of a cent.
>>
>> That is neither here nor there.
>>
>> You can't have a third of a cent in accounting, because accounting is
>> decimal based, at least with US dollars and similar currencies,
>> where you don't have beasties like sixths of a dollar.
>
> Actually, many currencies (including the US Dollar) allow for measurements
> in the thousandths of a dollar, and such calculations are common in both
> stock brokerage pricing (a broker may charge, say, 5 mils per share on
> bulk trades, earning $5.00 for every 1000 shares bought/sold) and property
> tax calculation.
>
>> "Third of a cent" is a financial quantity nobody works with, in any
>> representation of dollars.
>
> Except for those who work with money as a commodity, stock brokers,
> municipal property tax assessors, and a wide variety of others. Consider,
> at this moment, I see that 1 Japanese Yen will buy 0.0069 US Dollars.
> How inconvenient would it be if programmers just took the position that
> there are no fractions of a US dollar lower than 1 cent, and that 1 Yen,
> therefore, purchases $0.00 USD?
>
>> And even if they did, floating point
>> could handle it just fine, if everyone agreed that around 15
>> digits of precision is good enough.
>
> For very small and very large sums of money, most banking systems
> will stay /very/ far away from floatingpoint in any form. Better
> to do (expensive) fixed-precision math and get exact answers than
> to do (cheaper) floatingpoint math and get the final /financial/
> answer wrong. That's how banks fail, and programmers get rich
> from rounding errors (watch the movie "Office Space").
Or SuperMan 3... ;^)
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-10 18:26 +0000 |
| Subject | Re: Making accountants cross (wa Re: you think rust may outthrone c?) |
| Message-ID | <20230810111828.872@kylheku.com> |
| In reply to | #172033 |
On 2023-08-10, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
> On Thu, 10 Aug 2023 16:31:31 +0000, Kaz Kylheku wrote:
>
>> On 2023-08-10, Vir Campestris <vir.campestris@invalid.invalid> wrote:
>>> On 07/08/2023 17:05, Ben Bacarisse wrote:
>>>> Hmm... With statically allocated strings, or using malloc and therefore
>>>> requiring free call not shown?
>>>>
>>>> I would rather do this: anywhere a type is defined, I'd define a FMT_xxx
>>>> macro:
>>>>
>>>> typedef float salary_t;
>>>> #define FMT_SALARY "f"
>>>>
>>>> typedef unsigned long int payrollid_t;
>>>> #define FMT_PAYROLLID "lu"
>>>>
>>>> so that one can write
>>>>
>>>> printf("Hello %s your salary is %" FMT_SALLARY
>>>> ", your payrollid %" FMT_PAYROLLID "\n",
>>>> employee.name, employee.salary, employee.payrollid);
>>>>
>>>> -- Ben.
>>>
>>> Ben, if you put floating points in money accountants get upset.
>>>
>>> Three employees are paid $100.00, so it adds up to $300.
>>>
>>> Deduct $20 from each, and it's $240.
>>>
>>> Use floating point and sooner or later it won't add up.
>>
>> Use floating-point *naively* and the truncation errors will accumulate
>> to the point of making at least a one cent difference, screwing up the
>> accounting.
>>
>> Use floating-point intelligently and that won't happen.
>>
>>> You can't have a third of a cent.
>>
>> That is neither here nor there.
>>
>> You can't have a third of a cent in accounting, because accounting is
>> decimal based, at least with US dollars and similar currencies,
>> where you don't have beasties like sixths of a dollar.
>
> Actually, many currencies (including the US Dollar) allow for measurements
> in the thousandths of a dollar, and such calculations are common in both
> stock brokerage pricing (a broker may charge, say, 5 mils per share on
> bulk trades, earning $5.00 for every 1000 shares bought/sold) and property
> tax calculation.
>
>> "Third of a cent" is a financial quantity nobody works with, in any
>> representation of dollars.
>
> Except for those who work with money as a commodity, stock brokers,
> municipal property tax assessors, and a wide variety of others. Consider,
> at this moment, I see that 1 Japanese Yen will buy 0.0069 US Dollars.
> How inconvenient would it be if programmers just took the position that
> there are no fractions of a US dollar lower than 1 cent, and that 1 Yen,
> therefore, purchases $0.00 USD?
BUt that isn't 1/3; it is 69/10000, representing a decimal value that
has been truncated to 4 digits.
It has two significant figures in it. IEEE double has 13 more
to approximate it.
.0069 in IEEE double is actually 0.00689999999999999988, if
we render it to 18 digits.
>> And even if they did, floating point
>> could handle it just fine, if everyone agreed that around 15
>> digits of precision is good enough.
>
> For very small and very large sums of money, most banking systems
> will stay /very/ far away from floatingpoint in any form.
For very small? Can you elaborate on it. IEEE double can go to 1E-308,
right, and beyond that with subnormals.
> Better
> to do (expensive) fixed-precision math and get exact answers than
> to do (cheaper) floatingpoint math and get the final /financial/
Better to know what you're doing so you can make either one
sit up and beg, and avoid rolling over.
> answer wrong. That's how banks fail, and programmers get rich
> from rounding errors (watch the movie "Office Space").
Proof by comedy movie, okay.
Companies fail by taking away the red stapler from the reclusive nerd.
--
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 | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-08-10 11:30 -0700 |
| Subject | Re: Making accountants cross (wa Re: you think rust may outthrone c?) |
| Message-ID | <ub3acf$ev2j$6@dont-email.me> |
| In reply to | #172043 |
On 8/10/2023 11:26 AM, Kaz Kylheku wrote: > On 2023-08-10, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote: [...] > Proof by comedy movie, okay. > > Companies fail by taking away the red stapler from the reclusive nerd. Indeed! Can be dangerous. Highly unstable person: https://youtu.be/pQMuSotWCEs?t=44 Ouch! ;^o
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-08 17:39 +0200 |
| Message-ID | <uatnjo$3f3pb$1@dont-email.me> |
| In reply to | #171770 |
On 07/08/2023 17:40, Malcolm McLean wrote:
> On Monday, 7 August 2023 at 16:13:16 UTC+1, Ben Bacarisse wrote:
>> Bart <b...@freeuk.com> writes:
>>
>>> On 07/08/2023 12:41, Richard Damon wrote:
>>>> On 8/7/23 5:35 AM, Bart wrote:
>>
>>>>> Do you not see the problem of a hex format, which is already confusing
>>>>> because it is hex, representing the same value in different ways?
>>>>>
>>>>> In decimal, pi is always going to involve the digits 314159... with
>>>>> the decimal position depending on the exponent.
>>>>>
>>>>> With %A format (I've made 0x and p lower case for clarity; another
>>>>> issue), I can get either:
>>>>>
>>>>> 0xC.90FDAA22168Cp-2
>>>>>
>>>>> or:
>>>>>
>>>>> 0x1.921FB5p+1
>>>>>
>>>>> That's perfectly alright!
>>>>
>>>> Yes, it just like you can represent 0.5 as 5/10, 1/2, or even 2/4ths.
>>>
>>> We're not talking about fractions or rationals.
>> That's exactly what we are talking about. What do you think
>> 0x1.921FB5p+1 is if not a rational number?
>>
>> Floating point numbers are rationals, but since they are usually
>> represented internally in binary, they are hard to represent exactly in
>> base 10. The %a format is there to solve that problem. Humans don't
>> read the output except in rare cases. I used to when I was working with
>> interval arithmetic, but that was for debugging.
>>> The problem with the hex-binary form of C is that the representation of the
>>> significant figures varies according to exponent.
>> No necessarily. An implementation can choose to be consistent. In
>> fact, it would take some effort not to be consistent in this regard.
>> Different implementation may choose different representations of the
>> same number, but for a single implementation I would expect the digits
>> to be the same regardless of the exponent.
>>>> Your problem with the Hex representation is that you don't understand
>>>> what its purpose is. IT isn't to allow you to compare two numbers, but
>>>> to EXACTLY (and faiy efficiently) represent a floating point number.
>>>
>>> Why is not possible to do that if the exponent represents hex digits
>>> rather than binary ones?
>> That's a confused remark. Representing the exponent in hex digits makes
>> no difference. Different implementations could still choose different
>> ways to write the same number. Your suggestion is, I think, to write
>> the convert the binary exponent into a power of 16. That could be done
>> even if the resulting exponent is written in decimal, but I think you
>> advocate for both: writing the binary exponent as a poser of 16 and to
>> represent that power in hex digits.
>>
>> But I agree with the underlying point of your remark -- I don't think
>> there is any reason why your alternative representation could not be
>> exact and fairly efficient on most hardware.
>>> For example, I want to call the printf() function from the C runtime via an
>>> FFI; what format code do I use: is it %d, %ld or %lld?
>>>
>>> But those 'l' modifiers are in terms of C types, which are meaningless in
>>> my language;
>> That is not C's fault; they are intended for C's types, not yours.
>>> (Try and print int64_t, it will be either %ld or %lld!)
>> You should print an int64_t using the PRId64 macro or by converting it
>> to long long and using %lld. After so many years here how can you still
>> be having trouble knowing how to print a value from your language?
>>
> The advantage of C is that it is very flexible.
> What you can do is this.
>
> /*
> questionformat - a printf-style format string with %? escapes for unknown
> formats.
> ... - the unknown types, in pairs giving type and size.
> types: QFMT_REAL, QFMT_SIGNEDINTEGER, QFMT_UNSIGNEDINTEGER.
> sizes - sizeof() value of type
>
> e.g
> char *fmt = formatstring("Hello %s your salary is %?, ycur payrollid %?\n"
> QFMT_REAL, sizeof(salary_t),
> QFMT_UNSIGNEDINTEGER, sizeof(payrollid_t));
> printf(fmt, employee.name, employee.salary, employee.payrollid);
> */
> char *getformatstring(const char *questionformat, ....)
>
>
Surely a smarter way (if you want this kind of thing) would be to
combine _Generic and variadic macros, so that you can write:
Print("Hello ", employee.name, " your salary is ", employee.salary);
Or perhaps you could just have your variadic macro convert all
parameters to a common 64-bit union type (combining uint64_t, double and
const void*) before passing it on to your alternative printf-style
function. There are many possibilities that would not be as clumsy as this.
They might involve some ugly macros in the implementation, but you only
need to make these once, and it's the appearance in user code that matters.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-07 18:35 +0100 |
| Message-ID | <uara1m$2uq73$1@dont-email.me> |
| In reply to | #171768 |
On 07/08/2023 16:13, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 07/08/2023 12:41, Richard Damon wrote:
>>> On 8/7/23 5:35 AM, Bart wrote:
>
>>>> Do you not see the problem of a hex format, which is already confusing
>>>> because it is hex, representing the same value in different ways?
>>>>
>>>> In decimal, pi is always going to involve the digits 314159... with
>>>> the decimal position depending on the exponent.
>>>>
>>>> With %A format (I've made 0x and p lower case for clarity; another
>>>> issue), I can get either:
>>>>
>>>> 0xC.90FDAA22168Cp-2
>>>>
>>>> or:
>>>>
>>>> 0x1.921FB5p+1
>>>>
>>>> That's perfectly alright!
>>>
>>> Yes, it just like you can represent 0.5 as 5/10, 1/2, or even 2/4ths.
>>
>> We're not talking about fractions or rationals.
>
> That's exactly what we are talking about. What do you think
> 0x1.921FB5p+1 is if not a rational number?
Well, it's not what *I* am talking about.
A rational number may be expressed as a ratio A/B, where both A and B
can be scaled by the same arbitrary factor, for the same value number.
A floating point number expressed in decimal may also be considered a
ratio, but it is always A/(10**e). You can scale A and B by the same
factor, but it must be a power of 10, so the digits of A don't change.
With C's hex-binary format, the ratio is A/(2**e). You can scale A and B
by a power of 2, but that can have the effect of changing the
significant digits of A when it is expressed as hex.
Why can no one grasp this simple fact? I've pointed it out enough times.
>> Why is not possible to do that if the exponent represents hex digits
>> rather than binary ones?
>
> That's a confused remark. Representing the exponent in hex digits makes
> no difference. Different implementations could still choose different
> ways to write the same number. Your suggestion is, I think, to write
> the convert the binary exponent into a power of 16. That could be done
> even if the resulting exponent is written in decimal, but I think you
> advocate for both: writing the binary exponent as a poser of 16 and to
> represent that power in hex digits.
Well, writing the exponent as decimal rather than hex is not a
deal-breaker. I'm not too bothered with that. When I supported bases 2
thru 16, writing a float constant in ternary like this:
3x2.2012e7 # decimal exponent, means 3x2.2012 * 3**7
would look odd using digits other than 0,1,2, so I chose to use the same
base throughout (then the example becomes 3x2.2012e21). ('e' for
exponent works up to base 13.)
If only hex is involved, I'm happy to stick with a decimal exponent,
though it *will* be confusing, either way, and extra care is needed.
But with C's hex format, there are /three/ bases involved. The important
thing is that for base N, then
xxxxPyy
means xxxx * N**yy, and adding +/-d to yy shifts the 'decimal' point
within or around xxxx by d places, without changing xxxx.
> But I agree with the underlying point of your remark -- I don't think
> there is any reason why your alternative representation could not be
> exact and fairly efficient on most hardware.
My God, someone agrees with me for a change!
>> For example, I want to call the printf() function from the C runtime
via an
>> FFI; what format code do I use: is it %d, %ld or %lld?
>>
>> But those 'l' modifiers are in terms of C types, which are
meaningless in
>> my language;
>
> That is not C's fault; they are intended for C's types, not yours.
They're bad idea for C as well, especially now with dozens of integer types.
Imagine printing an expression with terms mixing half a dozen types,
siged and unsigned, classic and C99, wide and narrow; how on earth do
you figure out the final type? How do you maintain the format as the
expression changes, or the types involved?
You will probably suggest casting everything to long long int then using
"%ll", but this was my idea from a few days ago to just use 64 bits
everywhere, anyway.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-07 21:51 +0000 |
| Message-ID | <20230807125815.939@kylheku.com> |
| In reply to | #171779 |
On 2023-08-07, Bart <bc@freeuk.com> wrote: > >> For example, I want to call the printf() function from the C runtime > via an > >> FFI; what format code do I use: is it %d, %ld or %lld? > >> > >> But those 'l' modifiers are in terms of C types, which are > meaningless in > >> my language; > > > > That is not C's fault; they are intended for C's types, not yours. > > They're bad idea for C as well, especially now with dozens of integer types. > > Imagine printing an expression with terms mixing half a dozen types, > siged and unsigned, classic and C99, wide and narrow; how on earth do > you figure out the final type? How do you maintain the format as the > expression changes, or the types involved? > > You will probably suggest casting everything to long long int then using > "%ll", but this was my idea from a few days ago to just use 64 bits > everywhere, anyway. Since C99, we have a bunch of ugly, but usable "PRI" macros. E.g PRIu32 expands to the equivalent of "u" but but for uint32_t. Instead of "alpha %u omega" you have "alpha %" PRIu32 " omega". These macros also provide a way to detect whether these types are present. #ifdef PRIu32 .. // we have uint32_t #endif These are not directly usable from an FFI, unless the FFI processes the header file and stores the strings somewhere, making them available in that language. In any halfway modern language with FFI, you should be able to solve the problem easily. The FFI knows the sizes of all the types like int, long and long long and can match those to the derived types like int32 and uint64, and select the appropriate conversion specifier letter; e.g. if the type maps to "int", then "d" and so on. The reason we need the "PRI" macros in C is that we don't have a compile-time calculation ability to produce the contents of a string literal, and we usually need a format string as a literal. -- 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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-08-07 23:53 +0100 |
| Message-ID | <87il9qihwa.fsf@bsb.me.uk> |
| In reply to | #171782 |
Kaz Kylheku <864-117-4973@kylheku.com> writes: > Since C99, we have a bunch of ugly, but usable "PRI" macros. E.g PRIu32 > expands to the equivalent of "u" but but for uint32_t. > > Instead of "alpha %u omega" you have "alpha %" PRIu32 " omega". > > These macros also provide a way to detect whether these types > are present. Minor point... For that purpose, it can be more convenient to use the _MIN or _MAX macros like INT32_MAX from <stdint.h> since the PRI_ macros are defined only in <inttypes.h>. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-08 01:28 +0100 |
| Message-ID | <uas273$32k64$1@dont-email.me> |
| In reply to | #171782 |
On 07/08/2023 22:51, Kaz Kylheku wrote:
> On 2023-08-07, Bart <bc@freeuk.com> wrote:
>>>> For example, I want to call the printf() function from the C runtime
>> via an
>>>> FFI; what format code do I use: is it %d, %ld or %lld?
>>>>
>>>> But those 'l' modifiers are in terms of C types, which are
>> meaningless in
>>>> my language;
>>>
>>> That is not C's fault; they are intended for C's types, not yours.
>>
>> They're bad idea for C as well, especially now with dozens of
integer types.
>>
>> Imagine printing an expression with terms mixing half a dozen types,
>> siged and unsigned, classic and C99, wide and narrow; how on earth do
>> you figure out the final type? How do you maintain the format as the
>> expression changes, or the types involved?
>>
>> You will probably suggest casting everything to long long int then using
>> "%ll", but this was my idea from a few days ago to just use 64 bits
>> everywhere, anyway.
>
> Since C99, we have a bunch of ugly, but usable "PRI" macros. E.g PRIu32
> expands to the equivalent of "u" but but for uint32_t.
If only it was that simple. You are printing the expression:
printf("...", cond ? a+b*c : d+e);
and need a format code to replace '...'.
a, b, c, d, e have mixed types from the collection {long, int, time_t,
char, uint32_t, uint8_t, T} in some combination that you have to go and
look up. (T is some opaque typedef.)
So the format should be simple to determine, right? Work out the result
type of each branch of that ?:, work out the dominant type, and use that
format code.
But hang on, isn't the compiler much better at that then we are? It can
also keep track of changes to the expressions and to the types of those
variables, it even knows what type time_t and T are, and can update the
format at 100 printf sites across the program.
My view is that C's print-format system is not fit for purpose. The
formatting is OK, it is needing to specify types that is the problem.
> In any halfway modern language with FFI, you should be able to solve the
> problem easily. The FFI knows the sizes of all the types like int, long
> and long long and can match those to the derived types like int32 and
> uint64, and select the appropriate conversion specifier letter; e.g. if
> the type maps to "int", then "d" and so on.
>
> The reason we need the "PRI" macros in C is that we don't have
> a compile-time calculation ability to produce the contents of
> a string literal, and we usually need a format string as a literal.
It gets tricky when using sprintf say from another language, which is
then transpiled to actual C.
Then you might get into trouble using %lld for a type you've defined in
the C on top of int64_t. (On Linux64, int64_t in turn might be defined
on top of 'long', which needs a %ld format.)
(Actually there are more problems to do with the 'char*' type of the
format string, when strings in the source language use a type more akin
to 'unsigned char*'. Lots of fun and games can be had with that in
trying to shut up the compiler.)
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-08-07 22:21 -0400 |
| Message-ID | <2FhAM.351580$xMqa.250758@fx12.iad> |
| In reply to | #171793 |
On 8/7/23 8:28 PM, Bart wrote:
> On 07/08/2023 22:51, Kaz Kylheku wrote:
> > On 2023-08-07, Bart <bc@freeuk.com> wrote:
> >>>> For example, I want to call the printf() function from the C runtime
> >> via an
> >>>> FFI; what format code do I use: is it %d, %ld or %lld?
> >>>>
> >>>> But those 'l' modifiers are in terms of C types, which are
> >> meaningless in
> >>>> my language;
> >>>
> >>> That is not C's fault; they are intended for C's types, not yours.
> >>
> >> They're bad idea for C as well, especially now with dozens of
> integer types.
> >>
> >> Imagine printing an expression with terms mixing half a dozen types,
> >> siged and unsigned, classic and C99, wide and narrow; how on earth do
> >> you figure out the final type? How do you maintain the format as the
> >> expression changes, or the types involved?
> >>
> >> You will probably suggest casting everything to long long int then
> using
> >> "%ll", but this was my idea from a few days ago to just use 64 bits
> >> everywhere, anyway.
> >
> > Since C99, we have a bunch of ugly, but usable "PRI" macros. E.g PRIu32
> > expands to the equivalent of "u" but but for uint32_t.
>
> If only it was that simple. You are printing the expression:
>
> printf("...", cond ? a+b*c : d+e);
>
> and need a format code to replace '...'.
>
> a, b, c, d, e have mixed types from the collection {long, int, time_t,
> char, uint32_t, uint8_t, T} in some combination that you have to go and
> look up. (T is some opaque typedef.)
>
> So the format should be simple to determine, right? Work out the result
> type of each branch of that ?:, work out the dominant type, and use that
> format code.
>
> But hang on, isn't the compiler much better at that then we are? It can
> also keep track of changes to the expressions and to the types of those
> variables, it even knows what type time_t and T are, and can update the
> format at 100 printf sites across the program.
>
> My view is that C's print-format system is not fit for purpose. The
> formatting is OK, it is needing to specify types that is the problem.
which is EXACTLY the arguement that got us the C++ stream << operator.
If you want to do that in C, you can, just define a generic "print"
function that defines version for each fundamental type, and call that.
You don't seem to understand that C is based on the assumption that the
programmer actually knows what he is doing, not hiding behind a mass of
abstractions.
>
>
> > In any halfway modern language with FFI, you should be able to solve the
> > problem easily. The FFI knows the sizes of all the types like int, long
> > and long long and can match those to the derived types like int32 and
> > uint64, and select the appropriate conversion specifier letter; e.g. if
> > the type maps to "int", then "d" and so on.
> >
> > The reason we need the "PRI" macros in C is that we don't have
> > a compile-time calculation ability to produce the contents of
> > a string literal, and we usually need a format string as a literal.
>
> It gets tricky when using sprintf say from another language, which is
> then transpiled to actual C.
And why doesn't that other language implement a better print
functionality itself?
>
> Then you might get into trouble using %lld for a type you've defined in
> the C on top of int64_t. (On Linux64, int64_t in turn might be defined
> on top of 'long', which needs a %ld format.)
>
> (Actually there are more problems to do with the 'char*' type of the
> format string, when strings in the source language use a type more akin
> to 'unsigned char*'. Lots of fun and games can be had with that in
> trying to shut up the compiler.)
Again, you seem to be expecting that the C language will fix the
problems that you created yourself in how you (partially) defined your
language.
You are using C as a "portable assembler", but you don't actually seem
to want to understand the assembly language and are complaining because
the machine doesn't implement the fancy instructions you want to use.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-08 12:05 +0100 |
| Message-ID | <uat7ht$3camf$1@dont-email.me> |
| In reply to | #171797 |
On 08/08/2023 03:21, Richard Damon wrote:
> On 8/7/23 8:28 PM, Bart wrote:
>> My view is that C's print-format system is not fit for purpose. The
>> formatting is OK, it is needing to specify types that is the problem.
>
> which is EXACTLY the arguement that got us the C++ stream << operator.
That feature is so bad it makes using printf preferable! Is it really
that hard to just be able to write 'print x' ?
> If you want to do that in C, you can, just define a generic "print"
> function that defines version for each fundamental type, and call that.
>
> You don't seem to understand that C is based on the assumption that the
> programmer actually knows what he is doing, not hiding behind a mass of
> abstractions.
You don't get my point. The programmer might not know for sure the type
of a complex expression, and certainly does not want to keep updating
dozens of printf formats across the codebase as global declarations change.
Right now I don't know how to print a clock() result for example, and to
keep inventing special formats like %zu is crass.
*I* can just write:
println a, b, c
So can a dozen other languages (even from the 1960s!). I can change the
types of a, b, c, and it still works. I can print c, b, a and it still
works.
I can even just do 'print clock()'!
In C YOU CAN'T DO THAT. You need to dig up the types of each expression
and apply the right format. In this VERY simple case, it MIGHT be:
printf("%lld " PRId64 " %s", a, b, c);
But now you have an extra maintenance headache.
(In all cases, printing gets untidy when you need to do necessary
formatting, but only C incorporates types into the formatting.)
>> It gets tricky when using sprintf say from another language, which is
>> then transpiled to actual C.
>
> And why doesn't that other language implement a better print
> functionality itself?
It does, but ultimately it needs to do I/O, and I've been using C's
printf for that since the mid-90s, because it was simpler than using
WinAPI. I've since forgotten how do it with WinAPI.
For that purpose, I only need to use %c and %s. (For floats, I use
sprintf with %e %f %g, do any formatting, then use printf with %s if I
need output.)
So most of the time it is not an issue (other than, if using C
transpilation, there is still the problem of C's char* type not existing
in my language, nor any other).
Sometimes however, during bootstrapping or developing a new compiler, it
might not yet support the 1000 lines of code needed to implement my
Print routines, or there are codegen bugs, or I'm trying to keep test
code absolutely minimal, then I will use printf.
Or I might use it from my dynamic scripting language. I just use %ll
since everything is 64 bits. Or I can test that other matter:
printf("%A", pi) # interpreted code
shows:
0X1.921FB5P+1
> You are using C as a "portable assembler", but you don't actually seem
> to want to understand the assembly language and are complaining because
> the machine doesn't implement the fancy instructions you want to use.
Exactly. C *IS* used extensively as a portable assembler, as an
intermediate or target language, and there you don't want its UBs,
foibles and quirky type system to get in the way, because source
language and final targets are better defined than in C.
This is an important use-case which should not be forgotten.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-08 04:13 -0700 |
| Message-ID | <f5f9e15b-25aa-493c-869e-1cb12d64bf15n@googlegroups.com> |
| In reply to | #171810 |
On Tuesday, 8 August 2023 at 12:05:48 UTC+1, Bart wrote:
> On 08/08/2023 03:21, Richard Damon wrote:
> > On 8/7/23 8:28 PM, Bart wrote:
> >> My view is that C's print-format system is not fit for purpose. The
> >> formatting is OK, it is needing to specify types that is the problem.
> >
> > which is EXACTLY the arguement that got us the C++ stream << operator.
> That feature is so bad it makes using printf preferable! Is it really
> that hard to just be able to write 'print x' ?
> > If you want to do that in C, you can, just define a generic "print"
> > function that defines version for each fundamental type, and call that.
> >
> > You don't seem to understand that C is based on the assumption that the
> > programmer actually knows what he is doing, not hiding behind a mass of
> > abstractions.
> You don't get my point. The programmer might not know for sure the type
> of a complex expression, and certainly does not want to keep updating
> dozens of printf formats across the codebase as global declarations change.
>
> Right now I don't know how to print a clock() result for example, and to
> keep inventing special formats like %zu is crass.
>
> *I* can just write:
>
> println a, b, c
>
> So can a dozen other languages (even from the 1960s!). I can change the
> types of a, b, c, and it still works. I can print c, b, a and it still
> works.
>
> I can even just do 'print clock()'!
>
> In C YOU CAN'T DO THAT. You need to dig up the types of each expression
> and apply the right format. In this VERY simple case, it MIGHT be:
>
> printf("%lld " PRId64 " %s", a, b, c);
>
> But now you have an extra maintenance headache.
>
> (In all cases, printing gets untidy when you need to do necessary
> formatting, but only C incorporates types into the formatting.)
> >> It gets tricky when using sprintf say from another language, which is
> >> then transpiled to actual C.
> >
> > And why doesn't that other language implement a better print
> > functionality itself?
> It does, but ultimately it needs to do I/O, and I've been using C's
> printf for that since the mid-90s, because it was simpler than using
> WinAPI. I've since forgotten how do it with WinAPI.
>
> For that purpose, I only need to use %c and %s. (For floats, I use
> sprintf with %e %f %g, do any formatting, then use printf with %s if I
> need output.)
>
Virtually any integer which represents a value rather than a collection of bits
can be represented exactly by a double.
So
printf("%g\n", (double) x);
should do what you want, regardless of the type of x.
>
> > You are using C as a "portable assembler", but you don't actually seem
> > to want to understand the assembly language and are complaining because
> > the machine doesn't implement the fancy instructions you want to use.
> Exactly. C *IS* used extensively as a portable assembler, as an
> intermediate or target language, and there you don't want its UBs,
> foibles and quirky type system to get in the way, because source
> language and final targets are better defined than in C.
>
> This is an important use-case which should not be forgotten.
>
Yes, C is an important target language for compilers. I'm putting the finishing
touches to an automatic C-generating program myself.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-08 15:04 -0700 |
| Message-ID | <87r0odqjg7.fsf@nosuchdomain.example.com> |
| In reply to | #171812 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> Virtually any integer which represents a value rather than a collection of bits
> can be represented exactly by a double.
> So
> printf("%g\n", (double) x);
> should do what you want, regardless of the type of x.
If x is 1000001, the output is "1e+06". I don't consider that
acceptable. Nor do I want to have to stop and think whether the values
I'm printing *might* be too big to be stored in a double without losing
information.
If I don't know the type of x, I might use:
printf("%jd\n", (intmax_t)x);
or
printf("%ju\n", (uintmax_t)x);
(Or I might use [unsigned] long long if I happen to know the value fits
in 64 bits.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-08-08 08:22 -0400 |
| Message-ID | <qsqAM.133251$f7Ub.122358@fx47.iad> |
| In reply to | #171810 |
On 8/8/23 7:05 AM, Bart wrote:
> On 08/08/2023 03:21, Richard Damon wrote:
> > On 8/7/23 8:28 PM, Bart wrote:
> >> My view is that C's print-format system is not fit for purpose. The
> >> formatting is OK, it is needing to specify types that is the problem.
> >
> > which is EXACTLY the arguement that got us the C++ stream << operator.
> That feature is so bad it makes using printf preferable! Is it really
> that hard to just be able to write 'print x' ?
>
> > If you want to do that in C, you can, just define a generic "print"
> > function that defines version for each fundamental type, and call that.
> >
> > You don't seem to understand that C is based on the assumption that the
> > programmer actually knows what he is doing, not hiding behind a mass of
> > abstractions.
>
> You don't get my point. The programmer might not know for sure the type
> of a complex expression, and certainly does not want to keep updating
> dozens of printf formats across the codebase as global declarations change.
Then they are using the wrong tool.
C is designed to be used when you know, at least in general, what you
are working with.
>
> Right now I don't know how to print a clock() result for example, and to
> keep inventing special formats like %zu is crass.
>
> *I* can just write:
>
> println a, b, c
So, why don't you?
is the problem that you don't know how to translate that into C?
>
> So can a dozen other languages (even from the 1960s!). I can change the
> types of a, b, c, and it still works. I can print c, b, a and it still
> works.
>
> I can even just do 'print clock()'!
>
> In C YOU CAN'T DO THAT. You need to dig up the types of each expression
> and apply the right format. In this VERY simple case, it MIGHT be:
Because C is a lower lever, and targeted to be more efficiet, than those
other languages.
>
> printf("%lld " PRId64 " %s", a, b, c);
>
> But now you have an extra maintenance headache.
>
> (In all cases, printing gets untidy when you need to do necessary
> formatting, but only C incorporates types into the formatting.)
>
>
> >> It gets tricky when using sprintf say from another language, which is
> >> then transpiled to actual C.
> >
> > And why doesn't that other language implement a better print
> > functionality itself?
>
> It does, but ultimately it needs to do I/O, and I've been using C's
> printf for that since the mid-90s, because it was simpler than using
> WinAPI. I've since forgotten how do it with WinAPI.
So, your problem is that you aren't willing to do the work yourself.
>
> For that purpose, I only need to use %c and %s. (For floats, I use
> sprintf with %e %f %g, do any formatting, then use printf with %s if I
> need output.)
>
> So most of the time it is not an issue (other than, if using C
> transpilation, there is still the problem of C's char* type not existing
> in my language, nor any other).
So again, the problem is you are using the wrong tool or your language
is incomplete.
>
> Sometimes however, during bootstrapping or developing a new compiler, it
> might not yet support the 1000 lines of code needed to implement my
> Print routines, or there are codegen bugs, or I'm trying to keep test
> code absolutely minimal, then I will use printf.
>
> Or I might use it from my dynamic scripting language. I just use %ll
> since everything is 64 bits. Or I can test that other matter:
>
> printf("%A", pi) # interpreted code
>
> shows:
>
> 0X1.921FB5P+1
>
> > You are using C as a "portable assembler", but you don't actually seem
> > to want to understand the assembly language and are complaining because
> > the machine doesn't implement the fancy instructions you want to use.
>
> Exactly. C *IS* used extensively as a portable assembler, as an
> intermediate or target language, and there you don't want its UBs,
> foibles and quirky type system to get in the way, because source
> language and final targets are better defined than in C.
>
> This is an important use-case which should not be forgotten.
But to use C as a portable assembler, you need to use it as an
assembler, and that means understanding the nature of the "assembly
language".
All your problems seem to resolve to not wanting to put in the work to
understand the langauge and follow the rules of the assembly language.
You don't get to complain that a given machine doesn't implement your
favorate instruction directly in the assembly language.
And "portable" in that name has its limits. Because machine language
itself isn't actually "portable", and C's goal was to focus on being
able to both write efficient code when you knew the ability of the
machine, and fairly portable code when you didn't worry about being
maximally efficient, means you need to understand the rules of the language.
You CAN'T just "use" types you don't understand.
Also, with things like the printf family, sometimes the "portable" way
is somewhat ugly, and involves casting the final type to something you
know holds the value. You COULD just cast all integral values to "long
long" and use long long formats and not worry about the types. (or even
intmax_t)
After all, "printf" isn't a fast function by itself.
IF you are concerned about efficient outputing of valuse, you build a
family of generic "print" functions that use the right version for the
type given, and let the complier figure it out. Just means you can't put
everything in one statement. (but this is intermediary code, so doesn't
really need to be totally readable).
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-08 15:16 +0100 |
| Message-ID | <uatimv$3e73n$1@dont-email.me> |
| In reply to | #171816 |
On 08/08/2023 13:22, Richard Damon wrote:
> On 8/8/23 7:05 AM, Bart wrote:
>> On 08/08/2023 03:21, Richard Damon wrote:
>> > On 8/7/23 8:28 PM, Bart wrote:
>> >> My view is that C's print-format system is not fit for purpose. The
>> >> formatting is OK, it is needing to specify types that is the
problem.
>> >
>> > which is EXACTLY the arguement that got us the C++ stream <<
operator.
>> That feature is so bad it makes using printf preferable! Is it really
>> that hard to just be able to write 'print x' ?
>>
>> > If you want to do that in C, you can, just define a generic "print"
>> > function that defines version for each fundamental type, and call
>> that.
>> >
>> > You don't seem to understand that C is based on the assumption that
>> the
>> > programmer actually knows what he is doing, not hiding behind a
>> mass of
>> > abstractions.
>>
>> You don't get my point. The programmer might not know for sure the
>> type of a complex expression, and certainly does not want to keep
>> updating dozens of printf formats across the codebase as global
>> declarations change.
>
> Then they are using the wrong tool.
What tool did you have in mind? Do you mean that an IDE will tell you
the types of the expressions, or write the format codes for you?
That strikes me as the same argument that you can use CDECL to get round
abstruse C type specs. If the tool can do it, why doesn't the compiler?
Or the language.
> C is designed to be used when you know, at least in general, what you
> are working with.
>
>>
>> Right now I don't know how to print a clock() result for example, and
>> to keep inventing special formats like %zu is crass.
>>
>> *I* can just write:
>>
>> println a, b, c
>
> So, why don't you?
I do. It's lovely. The question is, why are a million users of C denied
that?
> is the problem that you don't know how to translate that into C?
>
>>
>> So can a dozen other languages (even from the 1960s!). I can change
>> the types of a, b, c, and it still works. I can print c, b, a and it
>> still works.
>>
>> I can even just do 'print clock()'!
>>
>> In C YOU CAN'T DO THAT. You need to dig up the types of each
>> expression and apply the right format. In this VERY simple case, it
>> MIGHT be:
>
> Because C is a lower level, and targeted to be more efficiet, than those
> other languages.
Sorry, but that is rubbish. My 'M' language is also low level, but
somehow manages to have a proper print. And it's not dead slow either:
A loop which prints the numbers up to 10 million (redirected to a file
to remove display overheads), takes 1.8 seconds in my language, and 3.2
seconds using gcc 13.2 -O3. bcc/tcc take 2.4 seconds.
(My library is faster, despite the int->text code being unoptimised,
because of buffering. But then maybe gcc's printf is also buffered
internally. Which one is cheating more? I know mine won in this case!)
>>
>> printf("%lld " PRId64 " %s", a, b, c);
>>
>> But now you have an extra maintenance headache.
>>
>> (In all cases, printing gets untidy when you need to do necessary
>> formatting, but only C incorporates types into the formatting.)
>>
>>
>> >> It gets tricky when using sprintf say from another language,
which is
>> >> then transpiled to actual C.
>> >
>> > And why doesn't that other language implement a better print
>> > functionality itself?
>>
>> It does, but ultimately it needs to do I/O, and I've been using C's
>> printf for that since the mid-90s, because it was simpler than using
>> WinAPI. I've since forgotten how do it with WinAPI.
>
> So, your problem is that you aren't willing to do the work yourself.
What problem is this? I've been implementing 'proper' PRINT in languages
since as far back as 1981.
At some point, nearly 20 years later, I switched from OS to C functions
for low-level I/O, for consoles or files. For Printing to printers,
images, windows and strings, I still handled that.
> So again, the problem is you are using the wrong tool or your language
> is incomplete.
The problem is that you don't have a clue what the problem is.
There is no tool, and no feature in my language (other than turning it
into C), that will fix the problem that C's 'char*' is so unique.
Usually you can ignore that if using C's library purely via a binary
interface, but if generating C code, you will see issues. The solutions
are ugly and ungainly.
Try it and see!
> But to use C as a portable assembler, you need to use it as an
> assembler, and that means understanding the nature of the "assembly
> language".
An assembly language which has a million more rules, special cases and
UBs than any real assembler!
In x64 assembly, I can write a floating point value to a 64-bit memory
location, and read it back as an integer, with no issues:
movq [fred], xmm0
mov rax, [fred]
C makes that undefined - maybe.
> IF you are concerned about efficient outputing of valuse, you build a
> family of generic "print" functions that use the right version for the
> type given, and let the complier figure it out. Just means you can't put
> everything in one statement. (but this is intermediary code, so doesn't
> really need to be totally readable).
This is exactly what I do behind the scenes of my language. And another
reason why I sometimes use 'printf', since it produces long sequences of
function calls which obscure minimal test code.
The advantage of printf also is that it is outside my language, so its
implementation code doesn't intrude.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2023-08-08 09:15 -0700 |
| Message-ID | <45c8abb5-ed2a-4cc6-93db-85e205801896n@googlegroups.com> |
| In reply to | #171828 |
On Tuesday, August 8, 2023 at 5:16:14 PM UTC+3, Bart wrote:
> On 08/08/2023 13:22, Richard Damon wrote:
> > On 8/8/23 7:05 AM, Bart wrote:
> >> On 08/08/2023 03:21, Richard Damon wrote:
> >> > On 8/7/23 8:28 PM, Bart wrote:
> >> >> My view is that C's print-format system is not fit for purpose. The
> >> >> formatting is OK, it is needing to specify types that is the
> problem.
> >> >
> >> > which is EXACTLY the arguement that got us the C++ stream <<
> operator.
> >> That feature is so bad it makes using printf preferable! Is it really
> >> that hard to just be able to write 'print x' ?
> >>
> >> > If you want to do that in C, you can, just define a generic "print"
> >> > function that defines version for each fundamental type, and call
> >> that.
> >> >
> >> > You don't seem to understand that C is based on the assumption that
> >> the
> >> > programmer actually knows what he is doing, not hiding behind a
> >> mass of
> >> > abstractions.
> >>
> >> You don't get my point. The programmer might not know for sure the
> >> type of a complex expression, and certainly does not want to keep
> >> updating dozens of printf formats across the codebase as global
> >> declarations change.
> >
> > Then they are using the wrong tool.
> What tool did you have in mind? Do you mean that an IDE will tell you
> the types of the expressions, or write the format codes for you?
>
> That strikes me as the same argument that you can use CDECL to get round
> abstruse C type specs. If the tool can do it, why doesn't the compiler?
> Or the language.
> > C is designed to be used when you know, at least in general, what you
> > are working with.
> >
> >>
> >> Right now I don't know how to print a clock() result for example, and
> >> to keep inventing special formats like %zu is crass.
> >>
> >> *I* can just write:
> >>
> >> println a, b, c
> >
> > So, why don't you?
> I do. It's lovely. The question is, why are a million users of C denied
> that?
> > is the problem that you don't know how to translate that into C?
> >
> >>
> >> So can a dozen other languages (even from the 1960s!). I can change
> >> the types of a, b, c, and it still works. I can print c, b, a and it
> >> still works.
> >>
> >> I can even just do 'print clock()'!
> >>
> >> In C YOU CAN'T DO THAT. You need to dig up the types of each
> >> expression and apply the right format. In this VERY simple case, it
> >> MIGHT be:
> >
> > Because C is a lower level, and targeted to be more efficiet, than those
> > other languages.
>
> Sorry, but that is rubbish. My 'M' language is also low level, but
> somehow manages to have a proper print. And it's not dead slow either:
>
> A loop which prints the numbers up to 10 million (redirected to a file
> to remove display overheads), takes 1.8 seconds in my language, and 3.2
> seconds using gcc 13.2 -O3. bcc/tcc take 2.4 seconds.
>
> (My library is faster, despite the int->text code being unoptimised,
> because of buffering. But then maybe gcc's printf is also buffered
> internally. Which one is cheating more? I know mine won in this case!)
Sounds like gcc under mingw64/msys64.
It uses old Microsoft's DLLs (from Visulat Studio 2013 or something like that)
for C RTL. For many tasks it's o.k. but for few others slow or problematic
in a different ways.
So, you can't blame 'C' or gcc for this particular slowness.
You can't even blame Microsoft, because C RTL supplied with their less
ancient compilers prints integers much faster.
And you can't blame mingw64 maintainers because they are mostly
volunteering.
> >>
> >> printf("%lld " PRId64 " %s", a, b, c);
> >>
> >> But now you have an extra maintenance headache.
> >>
> >> (In all cases, printing gets untidy when you need to do necessary
> >> formatting, but only C incorporates types into the formatting.)
> >>
> >>
> >> >> It gets tricky when using sprintf say from another language,
> which is
> >> >> then transpiled to actual C.
> >> >
> >> > And why doesn't that other language implement a better print
> >> > functionality itself?
> >>
> >> It does, but ultimately it needs to do I/O, and I've been using C's
> >> printf for that since the mid-90s, because it was simpler than using
> >> WinAPI. I've since forgotten how do it with WinAPI.
> >
> > So, your problem is that you aren't willing to do the work yourself.
> What problem is this? I've been implementing 'proper' PRINT in languages
> since as far back as 1981.
>
> At some point, nearly 20 years later, I switched from OS to C functions
> for low-level I/O, for consoles or files. For Printing to printers,
> images, windows and strings, I still handled that.
> > So again, the problem is you are using the wrong tool or your language
> > is incomplete.
> The problem is that you don't have a clue what the problem is.
>
> There is no tool, and no feature in my language (other than turning it
> into C), that will fix the problem that C's 'char*' is so unique.
>
> Usually you can ignore that if using C's library purely via a binary
> interface, but if generating C code, you will see issues. The solutions
> are ugly and ungainly.
>
> Try it and see!
> > But to use C as a portable assembler, you need to use it as an
> > assembler, and that means understanding the nature of the "assembly
> > language".
> An assembly language which has a million more rules, special cases and
> UBs than any real assembler!
>
> In x64 assembly, I can write a floating point value to a 64-bit memory
> location, and read it back as an integer, with no issues:
>
> movq [fred], xmm0
> mov rax, [fred]
>
> C makes that undefined - maybe.
> > IF you are concerned about efficient outputing of valuse, you build a
> > family of generic "print" functions that use the right version for the
> > type given, and let the complier figure it out. Just means you can't put
> > everything in one statement. (but this is intermediary code, so doesn't
> > really need to be totally readable).
> This is exactly what I do behind the scenes of my language. And another
> reason why I sometimes use 'printf', since it produces long sequences of
> function calls which obscure minimal test code.
>
> The advantage of printf also is that it is outside my language, so its
> implementation code doesn't intrude.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-08 18:33 +0100 |
| Message-ID | <uatu9r$3g26b$2@dont-email.me> |
| In reply to | #171855 |
On 08/08/2023 17:15, Michael S wrote: > On Tuesday, August 8, 2023 at 5:16:14 PM UTC+3, Bart wrote: >> Sorry, but that is rubbish. My 'M' language is also low level, but >> somehow manages to have a proper print. And it's not dead slow either: >> >> A loop which prints the numbers up to 10 million (redirected to a file >> to remove display overheads), takes 1.8 seconds in my language, and 3.2 >> seconds using gcc 13.2 -O3. bcc/tcc take 2.4 seconds. >> >> (My library is faster, despite the int->text code being unoptimised, >> because of buffering. But then maybe gcc's printf is also buffered >> internally. Which one is cheating more? I know mine won in this case!) > > Sounds like gcc under mingw64/msys64. > It uses old Microsoft's DLLs (from Visulat Studio 2013 or something like that) > for C RTL. For many tasks it's o.k. but for few others slow or problematic > in a different ways. > So, you can't blame 'C' or gcc for this particular slowness. > You can't even blame Microsoft, because C RTL supplied with their less > ancient compilers prints integers much faster. > And you can't blame mingw64 maintainers because they are mostly > volunteering. I tried the same program under WSL. That was a very fast terminal update, but I'm redirecting the output to a file. That got down after a few runs to 2.8 seconds. (Or 2.84 real + 0.7 user; on Windows elapsed time was 3.2 seconds.) The point is that Richard Damon was blaming the crudeness of printf on C being a lower level language; that has nothing to do with it. A large part is binary to text conversion that needs doing in any language, and the same for sending that text to the output. You can have a lower-level language, and have a Print X feature where the compiler knows the type of X.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-08-08 21:58 -0400 |
| Message-ID | <rpCAM.87315$ftCb.76427@fx34.iad> |
| In reply to | #171828 |
On 8/8/23 10:16 AM, Bart wrote:
> On 08/08/2023 13:22, Richard Damon wrote:
> > On 8/8/23 7:05 AM, Bart wrote:
> >> On 08/08/2023 03:21, Richard Damon wrote:
> >> > On 8/7/23 8:28 PM, Bart wrote:
> >> >> My view is that C's print-format system is not fit for purpose. The
> >> >> formatting is OK, it is needing to specify types that is the
> problem.
> >> >
> >> > which is EXACTLY the arguement that got us the C++ stream <<
> operator.
> >> That feature is so bad it makes using printf preferable! Is it really
> >> that hard to just be able to write 'print x' ?
> >>
> >> > If you want to do that in C, you can, just define a generic "print"
> >> > function that defines version for each fundamental type, and call
> >> that.
> >> >
> >> > You don't seem to understand that C is based on the assumption that
> >> the
> >> > programmer actually knows what he is doing, not hiding behind a
> >> mass of
> >> > abstractions.
> >>
> >> You don't get my point. The programmer might not know for sure the
> >> type of a complex expression, and certainly does not want to keep
> >> updating dozens of printf formats across the codebase as global
> >> declarations change.
> >
> > Then they are using the wrong tool.
>
> What tool did you have in mind? Do you mean that an IDE will tell you
> the types of the expressions, or write the format codes for you?
IF you actually want to output expressions that you don't know the type,
you need something that supports that. Maybe C++, maybe Python, maybe
something else like that.
It seems you have one tool in your box, so everything is a nail.
>
> That strikes me as the same argument that you can use CDECL to get round
> abstruse C type specs. If the tool can do it, why doesn't the compiler?
> Or the language.
Except the issue you are describing isn't handled by CDECL. That
generally needs the fully expressed type, and you complaint seems to be
a type that has been hidden via typedefs and the like.
So CDECL doesn't do what you want.
>
> > C is designed to be used when you know, at least in general, what you
> > are working with.
> >
> >>
> >> Right now I don't know how to print a clock() result for example, and
> >> to keep inventing special formats like %zu is crass.
> >>
> >> *I* can just write:
> >>
> >> println a, b, c
> >
> > So, why don't you?
>
> I do. It's lovely. The question is, why are a million users of C denied
> that?
Because that isn't C. If you want basic, you know where to find it.
Note, "println" like that can't do a lot of things that printf can do
when properly used, so it becomes the problem of just using the right tool.
>
> > is the problem that you don't know how to translate that into C?
> >
> >>
> >> So can a dozen other languages (even from the 1960s!). I can change
> >> the types of a, b, c, and it still works. I can print c, b, a and it
> >> still works.
> >>
> >> I can even just do 'print clock()'!
> >>
> >> In C YOU CAN'T DO THAT. You need to dig up the types of each
> >> expression and apply the right format. In this VERY simple case, it
> >> MIGHT be:
> >
> > Because C is a lower level, and targeted to be more efficiet, than those
> > other languages.
>
> Sorry, but that is rubbish. My 'M' language is also low level, but
> somehow manages to have a proper print. And it's not dead slow either:
And I bet it only runs on x86 processors?
>
> A loop which prints the numbers up to 10 million (redirected to a file
> to remove display overheads), takes 1.8 seconds in my language, and 3.2
> seconds using gcc 13.2 -O3. bcc/tcc take 2.4 seconds.
>
> (My library is faster, despite the int->text code being unoptimised,
> because of buffering. But then maybe gcc's printf is also buffered
> internally. Which one is cheating more? I know mine won in this case!)
Maybe you used the wrong C library to do that.
Also, since you have shown that you format routines don't meet the full
functionality of C's, that will give it an advantage.
>
>
> >>
> >> printf("%lld " PRId64 " %s", a, b, c);
> >>
> >> But now you have an extra maintenance headache.
> >>
> >> (In all cases, printing gets untidy when you need to do necessary
> >> formatting, but only C incorporates types into the formatting.)
> >>
> >>
> >> >> It gets tricky when using sprintf say from another language,
> which is
> >> >> then transpiled to actual C.
> >> >
> >> > And why doesn't that other language implement a better print
> >> > functionality itself?
> >>
> >> It does, but ultimately it needs to do I/O, and I've been using C's
> >> printf for that since the mid-90s, because it was simpler than using
> >> WinAPI. I've since forgotten how do it with WinAPI.
> >
> > So, your problem is that you aren't willing to do the work yourself.
>
> What problem is this? I've been implementing 'proper' PRINT in languages
> since as far back as 1981.
Then why are you complaining that the C printf doesn't meet your
requireents?
>
> At some point, nearly 20 years later, I switched from OS to C functions
> for low-level I/O, for consoles or files. For Printing to printers,
> images, windows and strings, I still handled that.
So?
You added a layer of abstraction, so maybe you programs can run on more
targets.
>
> > So again, the problem is you are using the wrong tool or your language
> > is incomplete.
>
> The problem is that you don't have a clue what the problem is.
No, I fully understand it.
>
> There is no tool, and no feature in my language (other than turning it
> into C), that will fix the problem that C's 'char*' is so unique.
Why is C's char* being unique a problem?
It still sounds like the problem is you don't understand what C is
doing, so you are misusing it.
>
> Usually you can ignore that if using C's library purely via a binary
> interface, but if generating C code, you will see issues. The solutions
> are ugly and ungainly.
But "intermediary" output is almost always "ugly", that is part of the
nature of machine generated code. If you "compilation" is any good, no
one needs to look at it.
>
> Try it and see!
>
> > But to use C as a portable assembler, you need to use it as an
> > assembler, and that means understanding the nature of the "assembly
> > language".
>
> An assembly language which has a million more rules, special cases and
> UBs than any real assembler!
Your thinking about the wrong machine. Remember, in C, the machine you
need to be thinking about is the "abstract machine" defined by the standard.
>
> In x64 assembly, I can write a floating point value to a 64-bit memory
> location, and read it back as an integer, with no issues:
>
> movq [fred], xmm0
> mov rax, [fred]
>
> C makes that undefined - maybe.
So?
>
> > IF you are concerned about efficient outputing of valuse, you build a
> > family of generic "print" functions that use the right version for the
> > type given, and let the complier figure it out. Just means you can't put
> > everything in one statement. (but this is intermediary code, so doesn't
> > really need to be totally readable).
>
> This is exactly what I do behind the scenes of my language. And another
> reason why I sometimes use 'printf', since it produces long sequences of
> function calls which obscure minimal test code.
>
> The advantage of printf also is that it is outside my language, so its
> implementation code doesn't intrude.
>
And if the doesn't meet your requirements, don't use it.
One big aspect of printf, is you need to know the "type" of each
arguement you give it. If you do, it works well, if you don't you just
can't use it.
You seem to think this is a bug instead of its design decision.
Try to explain how you would change C so that printf could be more
forgiving on the type given to it without totally changing how the
language works.
Remember, "printf" isn't something special in the language, and you can
write your own equivalent function, which would need to be able to work
just the same.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-09 11:05 +0100 |
| Message-ID | <uavods$3t1r3$1@dont-email.me> |
| In reply to | #171902 |
On 09/08/2023 02:58, Richard Damon wrote:
> On 8/8/23 10:16 AM, Bart wrote:
>> > Then they are using the wrong tool.
>>
>> What tool did you have in mind? Do you mean that an IDE will tell you
>> the types of the expressions, or write the format codes for you?
>
> IF you actually want to output expressions that you don't know the type,
> you need something that supports that. Maybe C++, maybe Python, maybe
> something else like that.
>
> It seems you have one tool in your box, so everything is a nail.
So, by 'tool' you mean a different language?
>> I do. It's lovely. The question is, why are a million users of C
>> denied that?
> Because that isn't C. If you want basic, you know where to find it.
So, the answer isn't a different language? I'm confused!
What tool did you have in mind if I wanted to print stuff easily in C?
>
> Note, "println" like that can't do a lot of things that printf can do
> when properly used, so it becomes the problem of just using the right
tool.
99% of the print statements I write (not 99% of the ones that are
permanent parts of source code) are temporary debug statements. Their
formatting needs are minimal.
In my syntax, I would most commonly write 'println =a,=b' where the '='
adds a label to the output, which might look like:
A=100 B=100
>> Sorry, but that is rubbish. My 'M' language is also low level, but
>> somehow manages to have a proper print. And it's not dead slow either:
>
> And I bet it only runs on x86 processors?
The very first version ran on Z80 8-bit processors. The current one
generates native code for x64 for Windows.
I can run my programs also on ARM devices and/or on Linux but it needs
to use intermediate C code (which is where all the problems of C come
into play).
My first compiler though was for a language that wasn't mine; it
generated native code for the 36-bit PDP10 processor. I can't remember
the Print facilities of that language, except that it wouldn't have used
format codes!
>>
>> A loop which prints the numbers up to 10 million (redirected to a file
>> to remove display overheads), takes 1.8 seconds in my language, and
>> 3.2 seconds using gcc 13.2 -O3. bcc/tcc take 2.4 seconds.
>>
>> (My library is faster, despite the int->text code being unoptimised,
>> because of buffering. But then maybe gcc's printf is also buffered
>> internally. Which one is cheating more? I know mine won in this case!)
>
> Maybe you used the wrong C library to do that.
So tell me how to get gcc 10.3 /or/ gcc 13.2 faster, as I don't know
how. I mean, that is not my problem.
> Also, since you have shown that you format routines don't meet the full
> functionality of C's, that will give it an advantage.
What functionality are you thinking of? I can do nearly everything that
printf can, and when it can't, I can just call printf.
>> There is no tool, and no feature in my language (other than turning it
>> into C), that will fix the problem that C's 'char*' is so unique.
>
> Why is C's char* being unique a problem?
Because in language X, strings and string literals are sequences of
unsigned bytes. If transpiling to C, how do you represent string
literals of X for example?
Writing "ABC" will create a term that in C has type char*, not unsigned
char*, which can cause problems used with string objects that are
declared as unsigned char*.
If you cast every string literal as (unsigned char*)"ABC", then it will
cause problems in calling C functions like puts(), which take a char*
parameter.
If you declare, in the generated C, your own version of puts that takes
unsigned char*, then a compiler like gcc will complain that it is an
incorrect prototype for a standard function.
This is about where I'm at. But further, there will be innumerable other
functions in myriad libraries that take char* arguments.
> It still sounds like the problem is you don't understand what C is
> doing, so you are misusing it.
The problem is C's bizarre plain 'char' type, which like some quantum
particle, although it necessarily has to be signed or unsigned, you're
not allowed to assume either one or the other in any program. So there
are three classes of char types.
> Your thinking about the wrong machine. Remember, in C, the machine you
> need to be thinking about is the "abstract machine" defined by the
> standard.
I have my own model in mind of the machine I want to write for. It more
or less identical to the actual physical machines most of us use.
But C doesn't allow that because /its/ model has to be a single one that
has to work on every conceivable architecture past, present and future,
including the DeathStation 9000.
Which is not that practical of course that's why there is so much UB and
so much that is vaguely defined. (stdint.h is a bolted-on concession,
but that works poorly.)
That is of no interest to those of us with language X which we want to
run on machine Y, but do not support direcly so need to go through C.
> One big aspect of printf, is you need to know the "type" of each
> arguement you give it. If you do, it works well, if you don't you just
> can't use it.
>
> You seem to think this is a bug instead of its design decision.
It's designed that way so it's not a bug, but it's just poor:
int i=1234;
printf("i = %s", i);
Or even printf("%s").
Crash.
Sure, a few decades on, /some/ compilers will detect that mismatch (even
though they're not supposed to know the workings of library routines),
but that's just a poor sticking plaster fix.
My simple C compiler can't detect it. (It does have the %? format which
adapts to the actual type used in the argument, but that won't work
anywhere else.)
> Try to explain how you would change C so that printf could be more
> forgiving on the type given to it without totally changing how the
> language works.
As I said, I played with "%?" format (and also "%=?") so that you can write:
void* a=&a;
double b=34.5;
char* c="Bart";
uint64_t d=-1;
printf("%=? %=? %=? %=?\n", a, b, c, d);
Output is:
A=000000000080FF18 B=34.500000 C=Bart D=18446744073709551615
It doesn't solve all the problems in all cases, and sometimes you need
to use a proper format (eg, you might want hex output for 'd'), but it
covers most of my casual uses of printf.
At least it's something; what have /you/ done alone those lines?
And you can do this:
printf("%=? %=? %=? %=?\n", d, b, c, a);
Reverse the item order, but you don't need to edit the format string.
Output now is:
D=18446744073709551615 B=34.500000 C=Bart A=000000000080FF18
That is amazing, I can do what most languages from the 1970s were
capable of!
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-09 11:53 +0100 |
| Message-ID | <uavr6v$3tbeo$1@dont-email.me> |
| In reply to | #171918 |
On 09/08/2023 11:05, Bart wrote:
> And you can do this:
>
> printf("%=? %=? %=? %=?\n", d, b, c, a);
>
> Reverse the item order, but you don't need to edit the format string.
> Output now is:
>
> D=18446744073709551615 B=34.500000 C=Bart A=000000000080FF18
Oops, I forgot to reverse b and c. But it still applies the correct
formats and labels. Make that mistake with normal printf and ... boom!
Actually I can try it, using this line with b and c in the wrong order:
printf("D=%llu C=%s B=%f A=%p\n", d, b, c, a);
With bcc, tcc and gcc, it compiles OK, but crashes.
Isn't gcc supposed to warn about this? Maybe there's some option to do
it, but I don't know what it is. Lot's of people will not know.
The weird thing is that with online gcc/Clang, it compiles and runs and
produces:
D=18446744073709551615 C=Bart B=34.500000 A=0x7ffd33e16bf0
C and B are shown correctly, even though they're in the wrong order! How
is that possible? Switching them has no effect.
It seems to rearrange the inner arguments to match the format codes.
(I think I know what's going on: the online compilers run on Linux,
presumably on x64, with a different ABI.
When it looks for the arg matching "%s", it's picking up the value of c,
the next argument from a GP register, since b is in a floating point
register, and vice versa.
That doesn't happen on Win64 ABI as register assignments are different.)
Here is the full program:
#include <stdio.h>
#include <stdint.h>
int main(void) {
void* a=&a;
double b=34.5;
char* c="Bart";
uint64_t d=-1;
printf("D=%llu C=%s B=%f A=%p\n", d, b, c, a);
}
[toc] | [prev] | [next] | [standalone]
Page 20 of 49 — ← Prev page 1 … 18 19 [20] 21 22 … 49 Next page →
Back to top | Article view | comp.lang.c
csiph-web