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 11 of 49 — ← Prev page 1 … 9 10 [11] 12 13 … 49 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-07-23 22:10 +0100 |
| Message-ID | <87o7k2l4ge.fsf@bsb.me.uk> |
| In reply to | #171165 |
David Brown <david.brown@hesbynett.no> writes: > On 22/07/2023 22:56, Ben Bacarisse wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> On 21/07/2023 17:14, Bart wrote:> >> >>>> C requires reduction of constant-expressions for compile-time >>>> expressions, and within conditional expressions of the preprocessor. >>> >>> Yes. >>> >>>> So the mechanism for doing that is already there; it is not optional. >>> >>> When you have a "constant expression" that is used wherever a "constant" >>> (what some people inaccurately call "integer literal") can be used, the >>> compiler must evaluate the expression at compile time. Apart from that, it >>> is all optional. >>> >>> Thus for "int x = 1 + 2;", the "1 + 2" must be evaluated at compile time >>> for a file-scope or static variable, but can be evaluated at run time if it >>> is a local variable. >> Objects with static storage duration are "initialized only once, prior >> to program startup". In any sane implementation, the calculation will >> be done by the compiler. But in principle the calculation and >> initialisation could be done by executable code that runs before main. >> > > Of course - compilers can do anything that gives the same observable > behaviour. The norm is that C toolchains put initialised static duration > data into a single section of the executable, with the initial values as a > binary section. Depending on the platform, either the initial data section > is loaded then made writeable, or is copied to writeable ram on startup. > But there is no requirement that it be done this way - merely a requirement > that it /could/ be done this way. (Unlike in C++, where statically > allocated data can have non-constant initialisation calculated at run-time > before main starts.) > >> <cut> >>>> In my languages and compilers, signed integer overflow has never been >>>> undefined. It's a choice. >>>> >>> A bad choice. Seriously. I mean, what kind of screwed up idea of numbers >>> do you have to have to think it's a good idea that adding two positive >>> numbers can give you a negative number? >> Two's complement numbers form a commutative ring. What's wrong with >> that? > > Nothing - but equally, it has no benefit. It gives nothing particularly > useful. There's nothing wrong with it but relies on a screwed up idea of numbers? > Now, if you were to redefine your multiplication and have your n-bit > numbers set up as a GF(2 ** n) finite field, you'd have some new useful > properties. It gives nothing particularly useful, but is the essential basis for something you describe as having new useful properties? > You'd be able to divide any integers, except for division by > 0, without any fractions. But would it be useful, other than for people > working on error correction algorithms? No, I don't believe so. That's because the special division operator is of narrow use. That's why it's not widely available in hardware. But the operations that make two's complement numbers into a ring are widely available in hardware. > Similarly, I don't believe defining the behaviour of signed integer > arithmetic overflow actually helps anyone (other than occasional very niche > situations when you really do want modulo behaviour). I think it can make reasoning about the programs easier. > When you overflow > integer arithmetic, you get the wrong answer for pretty much every > situation. I am at a loss as to why a predictable wrong answer is an > improvement over an unpredictable wrong answer - surely the aim of the game > is to avoid wrong answers in the first place. Yes, but you get the right answers by thinking clearly and understanding what the parts of a program do. I think that easier with plain two's complement arithmetic. From a practical point of view, where almost no one reasons about code any more and everyone replies on testing, you want well-defined semantics where overflow is trapped at run-time. >> Making some arithmetic operations undefined results is a >> structure with no simple mathematical description. > > Agreed. But it lets you have useful rules, leading to simplification for > both the compiler and the programmer. Knowing that as long as the > programmer hasn't made a mistake earlier in their code, "n + 1 > n" and > similar rules always holds true can be useful. Interesting. Can you give an example where this rule helps a programmer (and plain two's complement would not)? > Of course, that means the programmer is responsible for ensuring that "n" > is not INT_MAX at that point in the code, and may have to take steps to > make sure of that. But they must do so anyway, regardless of how integer > overflow is or is not defined, because the any definition would almost > certainly be wrong. Yes, none of that is specific to undefined overflow. > So you lose nothing, and gain something, by having the behaviour > undefined. You example might help me see the gain. > Even better, IMHO - when something is undefined behaviour, a compiler or > debugging tool can consider it an error. That means you can use tools to > help catch bugs in your code - static analysis of potential overflows, or > run-time error handling. But if the behaviour is defined in some way, then > it is not an error - the compiler has to assume that you intentionally > wrapped your integers. > > I for one would rather have help getting my programs correct, than a > language that blindly accepted all my mistakes. Tools should be to targeted at programmers. If there is a tool for C that can detect signed arithmetic overflow, there should be one that can detect wrapping in two's complement arithmetic. Maybe no one implements such things, but that's not the fault of the language semantics. > There are some rare occasions where modulo behaviour is useful. There are > also occasions where saturation would be more helpful, or some kind of NaN > behaviour similar to floating point arithmetic. There is no reason to > consider wrapping as somehow "correct" overflow behaviour. Indeed. I don't consider it as somehow "correct". >>> Two's complement wrapping is a side-effect of efficient ALU hardware >>> implementation, nothing more. It's not something you want in a >>> language. >> I'd make the opposite argument. Making overflow undefined in C was a >> consequence of hardware that behaved that way, nothing more. It has >> found a niche in modern optimising compilers, but that's a side effect. > > It is certainly possible that C originally made overflow UB because > different hardware worked in different ways in the early days of C. But I > think that if that had been the sole motivation and people thought two's > complement wrapping would be useful, it would have made more sense to make > overflow behaviour implementation defined rather than explicitly > undefined. That would require documenting all the possible behaviours. I might have been left as undefined because no one was confident that they could list all the real-world choices that mattered. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-07-23 14:51 -0700 |
| Message-ID | <7a6a83e2-2d84-46b9-8132-a0441e243981n@googlegroups.com> |
| In reply to | #171185 |
On Sunday, 23 July 2023 at 22:10:25 UTC+1, Ben Bacarisse wrote:
> David Brown <david...@hesbynett.no> writes:
>
> > Agreed. But it lets you have useful rules, leading to simplification for
> > both the compiler and the programmer. Knowing that as long as the
> > programmer hasn't made a mistake earlier in their code, "n + 1 > n" and
> > similar rules always holds true can be useful.
> Interesting. Can you give an example where this rule helps a programmer
> (and plain two's complement would not)?
>
I'm doing audio programming for my hobby project at the moment, so let's
give a (hypothetical) audio problem. The 16 bit signed samples come in with
a DC bias (the average value, which should be zero), which (unrealistically
but not too unrealistically) is known at compile time.
So
#define DC_BIAS_CORRECTION 1
#define dc_correct(pcm)(pcm + DC_BIAS_CORRECTION)
if (dccorrect(pcm) > pcm)
/* dc correction increases the value, take appropriate action) */
So we've got if( n + 1 > n) in code, without the programmer writing
any aburdity.
Now what will the action be? Of course the code will be written for 32 bit machines,
so it's
int correctedpcm = dccorrect(pcm);
if (correctedpcm > 32768) /* not SHRT_MAX! Samples must fir in 16 bits */
/* dc correction has caused the sample to overflow */
correctedpcm = pcm; /* what can we do? Just reset to original value and hope */
Now with David Brown's scheme, when we move this code to a processor with
16 bit ints, the if() expression is undefined. But because it's UB, the compiler
correctly guesses that we want it to be true. Then the assignment is also UB
(the dc_correct macro hasn't been written correctly), but it will do what we want.
So ir works, With Ben's system (the commutative ring) the test return false, and it
fails
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-07-23 23:12 +0100 |
| Message-ID | <u9k8k3$c349$1@dont-email.me> |
| In reply to | #171186 |
On 23/07/2023 22:51, Malcolm McLean wrote: > On Sunday, 23 July 2023 at 22:10:25 UTC+1, Ben Bacarisse wrote: >> David Brown <david...@hesbynett.no> writes: >> >>> Agreed. But it lets you have useful rules, leading to simplification for >>> both the compiler and the programmer. Knowing that as long as the >>> programmer hasn't made a mistake earlier in their code, "n + 1 > n" and >>> similar rules always holds true can be useful. >> Interesting. Can you give an example where this rule helps a programmer >> (and plain two's complement would not)? >> > I'm doing audio programming for my hobby project at the moment, so let's > give a (hypothetical) audio problem. The 16 bit signed samples come in with > a DC bias (the average value, which should be zero), which (unrealistically > but not too unrealistically) is known at compile time. > > So > #define DC_BIAS_CORRECTION 1 > #define dc_correct(pcm)(pcm + DC_BIAS_CORRECTION) > > if (dccorrect(pcm) > pcm) > /* dc correction increases the value, take appropriate action) */ > > So we've got if( n + 1 > n) in code, without the programmer writing > any aburdity. > Now what will the action be? Of course the code will be written for 32 bit machines, > so it's > > int correctedpcm = dccorrect(pcm); > if (correctedpcm > 32768) /* not SHRT_MAX! Samples must fir in 16 bits */ > /* dc correction has caused the sample to overflow */ > correctedpcm = pcm; /* what can we do? Just reset to original value and hope */ > > Now with David Brown's scheme, when we move this code to a processor with > 16 bit ints, the if() expression is undefined. That's your problem: your task is expected to deal with values outside of -32768/+32767, you need an int type that can represent that range. (Although if samples are going to be 16-bit ones, then none of them will be outside that range. Presumably the 16-bit code will have already truncated them for you!) This stuff can happen anyway: given WAV data with 16-bit sampling, if you increase the volume slightly, or add together two lots of data, you could overflow the range. Then either you clip or scale back down (or apply complicated solutions to compress the range), but you will need suitable numeric types that can represent the overflows. Using int32 (even on the 16-bit device) will solve the problem. You don't need it for the data, only for the calculations. (Just don't store 32-bit data truncated to 16-bit.) So keep away from the problem areas at each end of an integer's bounds.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-07-23 15:19 -0700 |
| Message-ID | <cc7b88d9-bdcb-4d2e-9167-0d738921622bn@googlegroups.com> |
| In reply to | #171187 |
On Sunday, 23 July 2023 at 23:12:33 UTC+1, Bart wrote: > On 23/07/2023 22:51, Malcolm McLean wrote: > > On Sunday, 23 July 2023 at 22:10:25 UTC+1, Ben Bacarisse wrote: > >> David Brown <david...@hesbynett.no> writes: > >> > >>> Agreed. But it lets you have useful rules, leading to > simplification for > >>> both the compiler and the programmer. Knowing that as long as the > >>> programmer hasn't made a mistake earlier in their code, "n + 1 > n" and > >>> similar rules always holds true can be useful. > >> Interesting. Can you give an example where this rule helps a programmer > >> (and plain two's complement would not)? > >> > > I'm doing audio programming for my hobby project at the moment, so let's > > give a (hypothetical) audio problem. The 16 bit signed samples come > in with > > a DC bias (the average value, which should be zero), which > (unrealistically > > but not too unrealistically) is known at compile time. > > > > So > > #define DC_BIAS_CORRECTION 1 > > #define dc_correct(pcm)(pcm + DC_BIAS_CORRECTION) > > > > if (dccorrect(pcm) > pcm) > > /* dc correction increases the value, take appropriate action) */ > > > > So we've got if( n + 1 > n) in code, without the programmer writing > > any aburdity. > > Now what will the action be? Of course the code will be written for > 32 bit machines, > > so it's > > > > int correctedpcm = dccorrect(pcm); > > if (correctedpcm > 32768) /* not SHRT_MAX! Samples must fir in 16 > bits */ > > /* dc correction has caused the sample to overflow */ > > correctedpcm = pcm; /* what can we do? Just reset to original > value and hope */ > > > > Now with David Brown's scheme, when we move this code to a processor with > > 16 bit ints, the if() expression is undefined. > That's your problem: your task is expected to deal with values outside > of -32768/+32767, you need an int type that can represent that range. > 32768 is a bug. 32767 will also have the problem you mention. But it could be 32766 (for some reason we don't want the last value to be used). Then it will work with 16 bit ints, under David Brown's scheme. >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-07-24 20:25 +0200 |
| Message-ID | <u9mfm6$omis$2@dont-email.me> |
| In reply to | #171187 |
On 24/07/2023 00:12, Bart wrote: > > On 23/07/2023 22:51, Malcolm McLean wrote: > > On Sunday, 23 July 2023 at 22:10:25 UTC+1, Ben Bacarisse wrote: > >> David Brown <david...@hesbynett.no> writes: > >> > >>> Agreed. But it lets you have useful rules, leading to > simplification for > >>> both the compiler and the programmer. Knowing that as long as the > >>> programmer hasn't made a mistake earlier in their code, "n + 1 > n" > and > >>> similar rules always holds true can be useful. > >> Interesting. Can you give an example where this rule helps a programmer > >> (and plain two's complement would not)? > >> > > I'm doing audio programming for my hobby project at the moment, so let's > > give a (hypothetical) audio problem. The 16 bit signed samples come > in with > > a DC bias (the average value, which should be zero), which > (unrealistically > > but not too unrealistically) is known at compile time. > > > > So > > #define DC_BIAS_CORRECTION 1 > > #define dc_correct(pcm)(pcm + DC_BIAS_CORRECTION) > > > > if (dccorrect(pcm) > pcm) > >Â Â Â /* dc correction increases the value, take appropriate action) */ > > > > So we've got if( n + 1 > n) in code, without the programmer writing > > any aburdity. > > Now what will the action be? Of course the code will be written for > 32 bit machines, > > so it's > > > > int correctedpcm = dccorrect(pcm); > > if (correctedpcm >Â 32768) /* not SHRT_MAX! Samples must fir in 16 > bits */ > >Â Â Â Â /* dc correction has caused the sample to overflow */ > >Â Â Â Â Â Â correctedpcm = pcm; /* what can we do? Just reset to original > value and hope */ > > > > Now with David Brown's scheme, when we move this code to a processor > with > > 16 bit ints, the if() expression is undefined. > > That's your problem: your task is expected to deal with values outside > of -32768/+32767, you need an int type that can represent that range. > Exactly, yes. If you want arithmetic code to work, you need to use types with a big enough range (or know for sure that you have modulo arithmetic, and know for sure that modulo arithmetic is appropriate and gives the right answers). What you certainly can't do, as Malcolm seems to be suggesting, is see how UB happens to be implemented on one system and assume it will be implemented in the same way on another! > > So keep away from the problem areas at each end of an integer's bounds. > Yes.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-07-24 17:22 +0100 |
| Message-ID | <87351dl1ny.fsf@bsb.me.uk> |
| In reply to | #171186 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Sunday, 23 July 2023 at 22:10:25 UTC+1, Ben Bacarisse wrote: >> David Brown <david...@hesbynett.no> writes: >> >> > Agreed. But it lets you have useful rules, leading to simplification for >> > both the compiler and the programmer. Knowing that as long as the >> > programmer hasn't made a mistake earlier in their code, "n + 1 > n" and >> > similar rules always holds true can be useful. >> Interesting. Can you give an example where this rule helps a programmer >> (and plain two's complement would not)? >> > I'm doing audio programming for my hobby project at the moment, so let's > give a (hypothetical) audio problem. The 16 bit signed samples come in with > a DC bias (the average value, which should be zero), which (unrealistically > but not too unrealistically) is known at compile time. > > So > #define DC_BIAS_CORRECTION 1 > #define dc_correct(pcm)(pcm + DC_BIAS_CORRECTION) Scary! I'd prefer ((pcm) + DC_BIAS_CORRECTION). > if (dccorrect(pcm) > pcm) > /* dc correction increases the value, take appropriate action) */ > > So we've got if( n + 1 > n) in code, without the programmer writing > any aburdity. Yes, with 32-bit int all is good. In modern C, you might want to use a type that reflects the use you make of it. Here you might use int_fast32_t for pcm but then your example would not have the bug your are suggesting might be avoided by assuming that n+1 > n. > Now what will the action be? Of course the code will be written for 32 > bit machines, so it's > > int correctedpcm = dccorrect(pcm); Unless the corrected values are always in range (and surely your example is for data that do not meet that criterion) the program's behaviour is undefined from here on. It could stop right here with a signal. It could play the Marseillaise... > if (correctedpcm > 32768) /* not SHRT_MAX! Samples must fir in 16 bits */ > /* dc correction has caused the sample to overflow */ > correctedpcm = pcm; /* what can we do? Just reset to original > value and hope */ I'm confused. How can it be that a result > 32767 is not an overflow for 16-bit samples? > Now with David Brown's scheme, when we move this code to a processor > with 16 bit ints, the if() expression is undefined. With both "schemes" the if is well-defined and false (though it's too late to matter with C's undefined overflow). > But because it's > UB, the compiler correctly guesses that we want it to be true. The if is well-defined and false with either scheme. A good compiler will tell you that the test is always false. On a system with 16-bit int 32768 has type long and no int can test greater than 32768. I don't see how this shows that assuming that n+1 > n is useful to programmers. Something about your assumptions has led to some very odd code. Since UB has already occurred, the compiler can decide that the if test (which is by any reasonable logic false) is in fact true! Though why any compiler would do so is a mystery. > Then > the assignment is also UB (the dc_correct macro hasn't been written > correctly), but it will do what we want. So ir works, With Ben's > system (the commutative ring) the test return false, and it fails Note that I am not suggesting that C should define integer arithmetic as wrapping. In a language with wrapping integer arithmetic you could (and should) program this differently, but in C you can't assume that you /don't/ have wrapping arithmetic, so C's UB does not buy you much. And assuming (as a programmer) that n+1 > n seems to only buy bugs. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-07-24 09:52 -0700 |
| Message-ID | <73c98183-5866-45e7-be5b-ece21f777335n@googlegroups.com> |
| In reply to | #171218 |
On Monday, 24 July 2023 at 17:22:56 UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.ar...@gmail.com> writes: > > > On Sunday, 23 July 2023 at 22:10:25 UTC+1, Ben Bacarisse wrote: > >> David Brown <david...@hesbynett.no> writes: > >> > >> > Agreed. But it lets you have useful rules, leading to simplification for > >> > both the compiler and the programmer. Knowing that as long as the > >> > programmer hasn't made a mistake earlier in their code, "n + 1 > n" and > >> > similar rules always holds true can be useful. > >> Interesting. Can you give an example where this rule helps a programmer > >> (and plain two's complement would not)? > >> > > I'm doing audio programming for my hobby project at the moment, so let's > > give a (hypothetical) audio problem. The 16 bit signed samples come in with > > a DC bias (the average value, which should be zero), which (unrealistically > > but not too unrealistically) is known at compile time. > > > > So > > #define DC_BIAS_CORRECTION 1 > > #define dc_correct(pcm)(pcm + DC_BIAS_CORRECTION) > Scary! I'd prefer ((pcm) + DC_BIAS_CORRECTION). It's deliberately buggy code to show how UB gets into real program written by reasonably sensible but fallible people. If I put parentheses round the argument, which is good practice, the the macro wouldn't expand to n + 1 > n, which was what David Brown wanted. > > if (dccorrect(pcm) > pcm) > > /* dc correction increases the value, take appropriate action) */ > > > > So we've got if( n + 1 > n) in code, without the programmer writing > > any aburdity. > Yes, with 32-bit int all is good. In modern C, you might want to use a > type that reflects the use you make of it. Here you might use > int_fast32_t for pcm but then your example would not have the bug your > are suggesting might be avoided by assuming that n+1 > n. > Exactly. > > Now what will the action be? Of course the code will be written for 32 > > bit machines, so it's > > > > int correctedpcm = dccorrect(pcm); > > Unless the corrected values are always in range (and surely your example > is for data that do not meet that criterion) the program's behaviour is > undefined from here on. It could stop right here with a signal. It > could play the Marseillaise... > No, I think you've nodded here. Expressions are evaluated as ints. So if int is 32 bits, a short + a constant could yield a value over 32767, without UB. > > > if (correctedpcm > 32768) /* not SHRT_MAX! Samples must fir in 16 bits */ > > /* dc correction has caused the sample to overflow */ > > correctedpcm = pcm; /* what can we do? Just reset to original > > value and hope */ > I'm confused. How can it be that a result > 32767 is not an overflow > for 16-bit samples? > That was a mistake. correctedpcm is an int, so 32 bits on most machines. However its going to be assigned to a 16 bit pcm sample (storing lots of high order zero bytes in memory is too expensive), and at that point, it could go over 32767, which we need to catch to prevent a nasty click in our audio track. But > 32768 is wrong. > 32767 is right. > > Now with David Brown's scheme, when we move this code to a processor > > with 16 bit ints, the if() expression is undefined. > With both "schemes" the if is well-defined and false (though it's too > late to matter with C's undefined overflow). > > But because it's > > UB, the compiler correctly guesses that we want it to be true. > The if is well-defined and false with either scheme. A good compiler > will tell you that the test is always false. On a system with 16-bit > int 32768 has type long and no int can test greater than 32768. > > I don't see how this shows that assuming that n+1 > n is useful to > programmers. Something about your assumptions has led to some very odd > code. > > Since UB has already occurred, the compiler can decide that the if test > (which is by any reasonable logic false) is in fact true! Though why > any compiler would do so is a mystery. > You're right. The example needs a bit more work to make it show a situation in which assuming that x + 1 > x is an advantage.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-07-25 02:52 +0100 |
| Message-ID | <87ila8kb9y.fsf@bsb.me.uk> |
| In reply to | #171220 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Monday, 24 July 2023 at 17:22:56 UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.ar...@gmail.com> writes: >> >> > On Sunday, 23 July 2023 at 22:10:25 UTC+1, Ben Bacarisse wrote: >> >> David Brown <david...@hesbynett.no> writes: >> >> >> >> > Agreed. But it lets you have useful rules, leading to simplification for >> >> > both the compiler and the programmer. Knowing that as long as the >> >> > programmer hasn't made a mistake earlier in their code, "n + 1 > n" and >> >> > similar rules always holds true can be useful. >> >> Interesting. Can you give an example where this rule helps a programmer >> >> (and plain two's complement would not)? >> >> >> > I'm doing audio programming for my hobby project at the moment, so let's >> > give a (hypothetical) audio problem. The 16 bit signed samples come in with >> > a DC bias (the average value, which should be zero), which (unrealistically >> > but not too unrealistically) is known at compile time. >> > >> > So >> > #define DC_BIAS_CORRECTION 1 >> > #define dc_correct(pcm)(pcm + DC_BIAS_CORRECTION) >> Scary! I'd prefer ((pcm) + DC_BIAS_CORRECTION). > It's deliberately buggy code to show how UB gets into real program written by > reasonably sensible but fallible people. If I put parentheses round the argument, > which is good practice, the the macro wouldn't expand to n + 1 > n, which was > what David Brown wanted. >> > if (dccorrect(pcm) > pcm) >> > /* dc correction increases the value, take appropriate action) */ >> > >> > So we've got if( n + 1 > n) in code, without the programmer writing >> > any aburdity. >> Yes, with 32-bit int all is good. In modern C, you might want to use a >> type that reflects the use you make of it. Here you might use >> int_fast32_t for pcm but then your example would not have the bug your >> are suggesting might be avoided by assuming that n+1 > n. >> > Exactly. >> > Now what will the action be? Of course the code will be written for 32 >> > bit machines, so it's >> > >> > int correctedpcm = dccorrect(pcm); >> >> Unless the corrected values are always in range (and surely your example >> is for data that do not meet that criterion) the program's behaviour is >> undefined from here on. It could stop right here with a signal. It >> could play the Marseillaise... >> > No, I think you've nodded here. Expressions are evaluated as ints. So if int > is 32 bits, a short + a constant could yield a value over 32767, without UB. I mean when moved to the 16-bit machine. Is that not the whole point of this example? There's no problem on 32-bits but you wanted to illustrate how one scheme helped somehow in that move, but in that move the undefined behaviour has occurred before the "if". >> > if (correctedpcm > 32768) /* not SHRT_MAX! Samples must fir in 16 bits */ >> > /* dc correction has caused the sample to overflow */ >> > correctedpcm = pcm; /* what can we do? Just reset to original >> > value and hope */ >> I'm confused. How can it be that a result > 32767 is not an overflow >> for 16-bit samples? >> > That was a mistake. correctedpcm is an int, so 32 bits on most machines. > However its going to be assigned to a 16 bit pcm sample (storing lots of > high order zero bytes in memory is too expensive), and at that point, it > could go over 32767, which we need to catch to prevent a nasty click in > our audio track. But > 32768 is wrong. > 32767 is right. I thought the typo was > instead of >= since you'd make a lot of the fact that SHRT_MAX is not what you wanted but one way or another, I can't see what the example is suppose to show now. >> > Now with David Brown's scheme, when we move this code to a processor >> > with 16 bit ints, the if() expression is undefined. >> With both "schemes" the if is well-defined and false (though it's too >> late to matter with C's undefined overflow). >> > But because it's >> > UB, the compiler correctly guesses that we want it to be true. >> The if is well-defined and false with either scheme. A good compiler >> will tell you that the test is always false. On a system with 16-bit >> int 32768 has type long and no int can test greater than 32768. >> >> I don't see how this shows that assuming that n+1 > n is useful to >> programmers. Something about your assumptions has led to some very odd >> code. >> >> Since UB has already occurred, the compiler can decide that the if test >> (which is by any reasonable logic false) is in fact true! Though why >> any compiler would do so is a mystery. >> > You're right. The example needs a bit more work to make it show a situation in > which assuming that x + 1 > x is an advantage. You think there is one? I would like to see it. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-07-24 17:37 +0200 |
| Message-ID | <u9m5rp$nbif$1@dont-email.me> |
| In reply to | #171185 |
On 23/07/2023 23:10, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 22/07/2023 22:56, Ben Bacarisse wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> On 21/07/2023 17:14, Bart wrote:>
>>>
>>>>> C requires reduction of constant-expressions for compile-time
>>>>> expressions, and within conditional expressions of the preprocessor.
>>>>
>>>> Yes.
>>>>
>>>>> So the mechanism for doing that is already there; it is not optional.
>>>>
>>>> When you have a "constant expression" that is used wherever a "constant"
>>>> (what some people inaccurately call "integer literal") can be used, the
>>>> compiler must evaluate the expression at compile time. Apart from that, it
>>>> is all optional.
>>>>
>>>> Thus for "int x = 1 + 2;", the "1 + 2" must be evaluated at compile time
>>>> for a file-scope or static variable, but can be evaluated at run time if it
>>>> is a local variable.
>>> Objects with static storage duration are "initialized only once, prior
>>> to program startup". In any sane implementation, the calculation will
>>> be done by the compiler. But in principle the calculation and
>>> initialisation could be done by executable code that runs before main.
>>>
>>
>> Of course - compilers can do anything that gives the same observable
>> behaviour. The norm is that C toolchains put initialised static duration
>> data into a single section of the executable, with the initial values as a
>> binary section. Depending on the platform, either the initial data section
>> is loaded then made writeable, or is copied to writeable ram on startup.
>> But there is no requirement that it be done this way - merely a requirement
>> that it /could/ be done this way. (Unlike in C++, where statically
>> allocated data can have non-constant initialisation calculated at run-time
>> before main starts.)
>>
>>> <cut>
>>>>> In my languages and compilers, signed integer overflow has never been
>>>>> undefined. It's a choice.
>>>>>
>>>> A bad choice. Seriously. I mean, what kind of screwed up idea of numbers
>>>> do you have to have to think it's a good idea that adding two positive
>>>> numbers can give you a negative number?
>>> Two's complement numbers form a commutative ring. What's wrong with
>>> that?
>>
>> Nothing - but equally, it has no benefit. It gives nothing particularly
>> useful.
>
> There's nothing wrong with it but relies on a screwed up idea of
> numbers?
If you don't overflow your calculations, there's nothing wrong with
two's complement wrapping. But for most use of integer calculations, if
you overflow, something has gone wrong. Believing that a wrapped value
is somehow "correct" is - in most cases - a screwed up idea of numbers.
>
>> Now, if you were to redefine your multiplication and have your n-bit
>> numbers set up as a GF(2 ** n) finite field, you'd have some new useful
>> properties.
>
> It gives nothing particularly useful, but is the essential basis for
> something you describe as having new useful properties?
>
The properties of finite fields can be extremely useful, but only in a
very small area of coding. GF(8), for example, is critical to the
implementation of RAID 6. But since multiplication and division work
completely differently from normal integer arithmetic, having your
normal types work like finite fields would be very unhelpful for the
vast majority of coding.
My point is that having a neat mathematical description or certain
functionalities does not necessarily make a particular model for
fixed-size integers better than alternatives. Giving a mathematical
name to the model does not aid programmers or make incorrect code
correct - defined incorrect results are still wrong.
>> You'd be able to divide any integers, except for division by
>> 0, without any fractions. But would it be useful, other than for people
>> working on error correction algorithms? No, I don't believe so.
>
> That's because the special division operator is of narrow use. That's
> why it's not widely available in hardware.
Finite field division and multiplication is of narrow use, yes. (8-bit
support could easily be implemented in hardware, and would certainly be
useful, but bigger sizes would be very costly in hardware and very
little use in software.)
The main reason finite field arithmetic is not used for common integer
types is not about hardware implementation - it's that none of the
arithmetic operations (not just division) correspond to normal integer
arithmetic operations.
> But the operations that make
> two's complement numbers into a ring are widely available in hardware.
>
Lots of things are widely available in hardware but are not useful in
most software. The integer arithmetic instructions on x86 all set flags
such as carry and overflow, yet these are only useful in a small
proportion of cases (I'd guess under 10%). Most (though not all)
processors provide such flags, at least optionally. But the C language
does not provide access to these flags, despite them being available.
C is defined by the behaviour of the abstract machine, not
implementations. The abstract machine was designed with ease of
efficient implementation in mind, but the effect of hardware
instructions does not define the C language.
(Had the C language defined signed integers to have saturating overflow
behaviour, I believe that most modern processors would have saturating
arithmetic instructions. They'd still have wrapping ones, which are
useful at that level, but they'd have saturating instructions as well.)
>> Similarly, I don't believe defining the behaviour of signed integer
>> arithmetic overflow actually helps anyone (other than occasional very niche
>> situations when you really do want modulo behaviour).
>
> I think it can make reasoning about the programs easier.
I think the lack of signed integer overflow can make reasoning about
programs easier. (It's even easier if a language has no fixed size for
integers, but that's very hard to implement efficiently.)
>
>> When you overflow
>> integer arithmetic, you get the wrong answer for pretty much every
>> situation. I am at a loss as to why a predictable wrong answer is an
>> improvement over an unpredictable wrong answer - surely the aim of the game
>> is to avoid wrong answers in the first place.
>
> Yes, but you get the right answers by thinking clearly and understanding
> what the parts of a program do. I think that easier with plain two's
> complement arithmetic.
>
I disagree (to the second sentence - I obviously agree to the first). I
find if far easier to reason about arithmetic if I make sure my
calculations and types are such that overflow never occurs. Overflow
semantics, or lack thereof, are then not an issue - my integers behave
like simple plain mathematical integers.
There /are/ occasions where wrapping is useful. I have recently been
working on code with cascaded integrator-comb filters. The first
section of the filter are integrators which can increase without bound,
but the later differencing parts will decrease the correspondingly. So
to avoid working with very large numbers, you can do all the
calculations modulo any number that is bigger than a set size based on
the maximum value of the filter input and the number of filter steps.
The easiest and most common implementation is therefore to hold big
enough internal accumulators and use two's complement wrapping.
But it is easier to reason about the code and the filter if you do so
with unlimited size integers. Then you consider what happens if you add
"a_i * M" to the stages of the filter. You can see that as long as M is
big enough, the final output is the same as you get with unlimited
integer size, plus an integer multiple of M. This means you can do all
your arithmetic modulo M, and avoid overflows in your accumulators, and
it will work for any M that is big enough. This is all easier when
thinking about adding multiples of M, than specifically two's complement
wrapping of a particular size.
<https://en.wikipedia.org/wiki/Cascaded_integrator%E2%80%93comb_filter>
> From a practical point of view, where almost no one reasons about code
> any more and everyone replies on testing, you want well-defined
> semantics where overflow is trapped at run-time.
I /do/ like to reason about my code - though I very rarely do so in any
formal way. Notes on paper to convince myself that it /could/ be
formally proved is usually more than enough.
But I don't see well-defined overflow semantics as useful in any but a
very small proportion of cases - I see /avoiding/ overflow as the
critical point. And if you have made sure you arithmetic cannot
overflow, what is the benefit in any given semantics for a situation
that will not occur?
I do agree that trapping overflow at run-time, especially during testing
and debugging, is a useful tool. And that is one of the key reasons I
see for /not/ defining the behaviour of integer overflow in the
language, but leaving it clearly undefined. You cannot have the
language define the behaviour of overflow as wrapping /and/ define it as
trapping. If the language (or a particular implementation) says
overflow must wrap, then it should not be trapping on overflow - that
would be giving errors on correct (according to the language) code. A
prime benefit of not defining overflow behaviour is that tools can help
identify overflow errors with static checking or at run-time.
But if the language defined the overflow as requiring trapping
behaviour, it would need to define error handling systems (perhaps like
C++ exceptions) requiring significant machinery, while also severely
limiting optimisation through re-arrangement and simplification of
arithmetic expressions (much more so than wrapping behaviour does).
>
>>> Making some arithmetic operations undefined results is a
>>> structure with no simple mathematical description.
>>
>> Agreed. But it lets you have useful rules, leading to simplification for
>> both the compiler and the programmer. Knowing that as long as the
>> programmer hasn't made a mistake earlier in their code, "n + 1 > n" and
>> similar rules always holds true can be useful.
>
> Interesting. Can you give an example where this rule helps a programmer
> (and plain two's complement would not)?
I don't think rules like this are going to be of much help directly to a
programmer. But like other optimisations, they let the programmer write
code in a way that feels natural and clear in the source code, while the
compiler takes care of the details. Typical transformations relating to
"n + 1" would be conversions between "<=" and "<" in loops, and
knowledge that "n++" and "++n" can't go from positive to negative, which
can sometimes simplify loops. You are rarely talking about big
optimisations, but shaving a few instructions from critical loops can be
useful.
Another case where defined wrapping behaviour is a cost is when you have
expressions like "array[i++]" on systems where size_t is greater than
int (such as most 64-bit systems). With wrapping, the compiler must
treat this as though it were a circular buffer, and make sure the
increment is done with (typically) 32-bit wrapping, then added to the
pointer base. Without wrapping, the compiler can initialise a pointer
to "array + i" and increment that.
Examples that are short enough for a quick example, yet demonstrate the
effect, are therefore always somewhat artificial. Real code has more
opportunities as code is moved around with inlining and other
optimisation passes.
void foo(int x, int * p) {
for (int i = 0; i <= x; i++) {
p[i] = i;
}
}
<https://godbolt.org/z/E3bzdKGj8>
The compiler (gcc) knows that the incrementation cannot wrap, letting it
simplify the code. It can also use 64-bit instructions, which I believe
are more efficient on x86-64, rather than 32-bit instructions.
I have come across cases of my own code (on 32-bit ARM microcontrollers)
where using "int" or "int32_t" instead of "uint32_t" made a positive
difference to loop efficiency. The semantic difference in these was in
the overflow behaviour. But while I have seen it in practice, the
details are long lost.
>
>> Of course, that means the programmer is responsible for ensuring that "n"
>> is not INT_MAX at that point in the code, and may have to take steps to
>> make sure of that. But they must do so anyway, regardless of how integer
>> overflow is or is not defined, because the any definition would almost
>> certainly be wrong.
>
> Yes, none of that is specific to undefined overflow.
Agreed. However, if the programmer has ensured that they have
appropriate values, and thus there can be no overflows, then specific
defined behaviour for overflow cannot be an advantage, either in terms
of compiler-generated code efficiency, or making the programmer's life
easier. But greater compiler knowledge - such as the compiler knowing
there is no overflow (or that you don't care what happens if there is)
may allow more efficient code generation.
>
>> So you lose nothing, and gain something, by having the behaviour
>> undefined.
>
> You example might help me see the gain.
Any chance of greater efficiency in the resulting code, or any chance of
catching errors using debug modes, is a gain.
>
>> Even better, IMHO - when something is undefined behaviour, a compiler or
>> debugging tool can consider it an error. That means you can use tools to
>> help catch bugs in your code - static analysis of potential overflows, or
>> run-time error handling. But if the behaviour is defined in some way, then
>> it is not an error - the compiler has to assume that you intentionally
>> wrapped your integers.
>>
>> I for one would rather have help getting my programs correct, than a
>> language that blindly accepted all my mistakes.
>
> Tools should be to targeted at programmers. If there is a tool for C
> that can detect signed arithmetic overflow, there should be one that can
> detect wrapping in two's complement arithmetic. Maybe no one implements
> such things, but that's not the fault of the language semantics.
>
A tool that helps you find situations where your program acted correctly
according to language semantics is not going to be very useful. It
would be possible to have a tool that logged particular correct
behaviour, but I think it is more common and more useful for tools to
log (and/or halt) on /incorrect/ behaviour.
>> There are some rare occasions where modulo behaviour is useful. There are
>> also occasions where saturation would be more helpful, or some kind of NaN
>> behaviour similar to floating point arithmetic. There is no reason to
>> consider wrapping as somehow "correct" overflow behaviour.
>
> Indeed. I don't consider it as somehow "correct".
>
>>>> Two's complement wrapping is a side-effect of efficient ALU hardware
>>>> implementation, nothing more. It's not something you want in a
>>>> language.
>>> I'd make the opposite argument. Making overflow undefined in C was a
>>> consequence of hardware that behaved that way, nothing more. It has
>>> found a niche in modern optimising compilers, but that's a side effect.
>>
>> It is certainly possible that C originally made overflow UB because
>> different hardware worked in different ways in the early days of C. But I
>> think that if that had been the sole motivation and people thought two's
>> complement wrapping would be useful, it would have made more sense to make
>> overflow behaviour implementation defined rather than explicitly
>> undefined.
>
> That would require documenting all the possible behaviours. I might
> have been left as undefined because no one was confident that they could
> list all the real-world choices that mattered.
>
I'd be surprised to find hardware that had genuinely undefined behaviour
on signed integer overflow. (I /have/ seen descriptions of processor
instructions that mentioned undefined behaviour, but not for something
that fundamental.) It should not be hard for an implementation to
describe what it does on overflow if it were required to pick a
behaviour and stick to it (especially if "trap" were an allowed option).
It would be a different matter entirely for some other types of
undefined behaviour, such as calling functions with non-matching
parameter types or numbers, or dereferencing out of bounds pointers.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-07-24 16:19 +0000 |
| Message-ID | <UvxvM.35832$fRmf.30677@fx02.iad> |
| In reply to | #171216 |
David Brown <david.brown@hesbynett.no> writes:
>On 23/07/2023 23:10, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>
>But I don't see well-defined overflow semantics as useful in any but a
>very small proportion of cases - I see /avoiding/ overflow as the
>critical point. And if you have made sure you arithmetic cannot
>overflow, what is the benefit in any given semantics for a situation
>that will not occur?
>
>I do agree that trapping overflow at run-time, especially during testing
>and debugging, is a useful tool. And that is one of the key reasons I
>see for /not/ defining the behaviour of integer overflow in the
>language, but leaving it clearly undefined. You cannot have the
>language define the behaviour of overflow as wrapping /and/ define it as
>trapping. If the language (or a particular implementation) says
>overflow must wrap, then it should not be trapping on overflow - that
>would be giving errors on correct (according to the language) code. A
>prime benefit of not defining overflow behaviour is that tools can help
>identify overflow errors with static checking or at run-time.
>
>But if the language defined the overflow as requiring trapping
>behaviour, it would need to define error handling systems (perhaps like
>C++ exceptions) requiring significant machinery, while also severely
>limiting optimisation through re-arrangement and simplification of
>arithmetic expressions (much more so than wrapping behaviour does).
There is a third possibility. The overflow is detected, an overflow
processor toggle is set, and the destination operand remains unchanged.
Software is free to check the overflow toggle after potentially
problematic operations, or simply ignore it if that provides the
required semantics.
That was how the Burroughs decimal machines worked - there was no
wrap of the destination operand, it would remain unchanged. Note
that the overflow toggle was sticky, so a series of calculations
could be made with overflow checked only once at the end. The
"branch on overflow" instruction would reset the processor overflow
toggle. Note also that the operand could be from one to 100 units
in length (either digits/nibbles or bytes - where the zone digit was
preserved but otherwise ignored) which, since arithmetic operations
were memory-to-memory (no registers), made it a bit tricky to detect
overflow before starting to write the destination operand[*].
The machine mainly ran COBOL.
[*] A rather clever algorithm that did addition/subtraction
starting with the most significant digits was developed
that still handled carry correctly. The representation
was either unsigned or signed-magnitude depending on the
operand address controller, with the sign occuping the
first (MSD) digit/nibble of a signed operand.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-07-24 20:34 +0200 |
| Message-ID | <u9mg7c$omis$3@dont-email.me> |
| In reply to | #171217 |
On 24/07/2023 18:19, Scott Lurndal wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 23/07/2023 23:10, Ben Bacarisse wrote: >>> David Brown <david.brown@hesbynett.no> writes: > >> >> But I don't see well-defined overflow semantics as useful in any but a >> very small proportion of cases - I see /avoiding/ overflow as the >> critical point. And if you have made sure you arithmetic cannot >> overflow, what is the benefit in any given semantics for a situation >> that will not occur? >> >> I do agree that trapping overflow at run-time, especially during testing >> and debugging, is a useful tool. And that is one of the key reasons I >> see for /not/ defining the behaviour of integer overflow in the >> language, but leaving it clearly undefined. You cannot have the >> language define the behaviour of overflow as wrapping /and/ define it as >> trapping. If the language (or a particular implementation) says >> overflow must wrap, then it should not be trapping on overflow - that >> would be giving errors on correct (according to the language) code. A >> prime benefit of not defining overflow behaviour is that tools can help >> identify overflow errors with static checking or at run-time. >> >> But if the language defined the overflow as requiring trapping >> behaviour, it would need to define error handling systems (perhaps like >> C++ exceptions) requiring significant machinery, while also severely >> limiting optimisation through re-arrangement and simplification of >> arithmetic expressions (much more so than wrapping behaviour does). > > There is a third possibility. The overflow is detected, an overflow > processor toggle is set, and the destination operand remains unchanged. > There are many more possibilities for defining overflow behaviour, but that is certainly another one. But if it is done strictly, it will still hinder optimisation and simplification. "x + 1 - 1" could not be simplified to "x", since "x + 1" might set the toggle. Trying to define overflow behaviour in such a way that this simplification would be allowed, while an overflowing "x + 1" would set the toggle, would be very difficult. I expect it could be done, but you'd have the situation where significant observable behaviour depends on optimisation details - a situation I would not like at all. You'd have to treat things more like floating point, with very limited expression simplification as the norm, and with something akin to gcc's "-ffast-math" mode where you consider floating point operations to be approximate and don't worry about small inaccuracies or variations. > Software is free to check the overflow toggle after potentially > problematic operations, or simply ignore it if that provides the > required semantics. > > That was how the Burroughs decimal machines worked - there was no > wrap of the destination operand, it would remain unchanged. Note > that the overflow toggle was sticky, so a series of calculations > could be made with overflow checked only once at the end. The > "branch on overflow" instruction would reset the processor overflow > toggle. Note also that the operand could be from one to 100 units > in length (either digits/nibbles or bytes - where the zone digit was > preserved but otherwise ignored) which, since arithmetic operations > were memory-to-memory (no registers), made it a bit tricky to detect > overflow before starting to write the destination operand[*]. > > The machine mainly ran COBOL. > > [*] A rather clever algorithm that did addition/subtraction > starting with the most significant digits was developed > that still handled carry correctly. The representation > was either unsigned or signed-magnitude depending on the > operand address controller, with the sign occuping the > first (MSD) digit/nibble of a signed operand. >
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-07-25 02:42 +0100 |
| Message-ID | <87o7k0kbq5.fsf@bsb.me.uk> |
| In reply to | #171216 |
David Brown <david.brown@hesbynett.no> writes: > On 23/07/2023 23:10, Ben Bacarisse wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> On 22/07/2023 22:56, Ben Bacarisse wrote: >>>> David Brown <david.brown@hesbynett.no> writes: >>>> >>>>> On 21/07/2023 17:14, Bart wrote:> >>>> >>>>>> C requires reduction of constant-expressions for compile-time >>>>>> expressions, and within conditional expressions of the preprocessor. >>>>> >>>>> Yes. >>>>> >>>>>> So the mechanism for doing that is already there; it is not optional. >>>>> >>>>> When you have a "constant expression" that is used wherever a "constant" >>>>> (what some people inaccurately call "integer literal") can be used, the >>>>> compiler must evaluate the expression at compile time. Apart from that, it >>>>> is all optional. >>>>> >>>>> Thus for "int x = 1 + 2;", the "1 + 2" must be evaluated at compile time >>>>> for a file-scope or static variable, but can be evaluated at run time if it >>>>> is a local variable. >>>> Objects with static storage duration are "initialized only once, prior >>>> to program startup". In any sane implementation, the calculation will >>>> be done by the compiler. But in principle the calculation and >>>> initialisation could be done by executable code that runs before main. >>>> >>> >>> Of course - compilers can do anything that gives the same observable >>> behaviour. The norm is that C toolchains put initialised static duration >>> data into a single section of the executable, with the initial values as a >>> binary section. Depending on the platform, either the initial data section >>> is loaded then made writeable, or is copied to writeable ram on startup. >>> But there is no requirement that it be done this way - merely a requirement >>> that it /could/ be done this way. (Unlike in C++, where statically >>> allocated data can have non-constant initialisation calculated at run-time >>> before main starts.) >>> >>>> <cut> >>>>>> In my languages and compilers, signed integer overflow has never been >>>>>> undefined. It's a choice. >>>>>> >>>>> A bad choice. Seriously. I mean, what kind of screwed up idea of numbers >>>>> do you have to have to think it's a good idea that adding two positive >>>>> numbers can give you a negative number? >>>> Two's complement numbers form a commutative ring. What's wrong with >>>> that? >>> >>> Nothing - but equally, it has no benefit. It gives nothing particularly >>> useful. >> There's nothing wrong with it but relies on a screwed up idea of >> numbers? > > If you don't overflow your calculations, there's nothing wrong with two's > complement wrapping. If your calculation don't overflow, it's OK for them to do something they won't do (wrap) because they don't overflow? > But for most use of integer calculations, if you > overflow, something has gone wrong. Believing that a wrapped value is > somehow "correct" is - in most cases - a screwed up idea of numbers. But I did not say that wrapped values should be believed to be correct. You seemed to be saying that simply defining it to happen was a screwed up notion of numbers. > My point is that having a neat mathematical description or certain > functionalities does not necessarily make a particular model for fixed-size > integers better than alternatives. Giving a mathematical name to the model > does not aid programmers or make incorrect code correct - defined incorrect > results are still wrong. But there are advantages to having defined incorrect answers over undefined incorrect answers. > C is defined by the behaviour of the abstract machine, not implementations. > The abstract machine was designed with ease of efficient implementation in > mind, but the effect of hardware instructions does not define the C > language. I am not talking about C. I was simply responding to the notion that wrapping in based on a screwed-up notion of numbers. >> Yes, but you get the right answers by thinking clearly and understanding >> what the parts of a program do. I think that easier with plain two's >> complement arithmetic. > > I disagree (to the second sentence - I obviously agree to the first). I > find if far easier to reason about arithmetic if I make sure my > calculations and types are such that overflow never occurs. How can that be any harder if arithmetic wraps than if it undefined? For one thing, undefined means it might wrap. > Overflow > semantics, or lack thereof, are then not an issue - my integers behave like > simple plain mathematical integers. So you don't care what happens on overflow. Yet you seem to say that one choice for overflow behaviour makes this avoiding of overflow easier. [Sorry, I cut an example that you might have taken great care in choosing, but I could not immediately see its relevance. If that was a mistake I apologise and I'll take a close look at it.] >>> Agreed. But it lets you have useful rules, leading to simplification for >>> both the compiler and the programmer. Knowing that as long as the >>> programmer hasn't made a mistake earlier in their code, "n + 1 > n" and >>> similar rules always holds true can be useful. >> Interesting. Can you give an example where this rule helps a programmer >> (and plain two's complement would not)? > > I don't think rules like this are going to be of much help directly to a > programmer. I re-worded your claim and I think that's led us off track again. You did not say it helps, you said it can lead "to simplification for ... the programmer". Can you give an example of this simplification? >>> Even better, IMHO - when something is undefined behaviour, a compiler or >>> debugging tool can consider it an error. That means you can use tools to >>> help catch bugs in your code - static analysis of potential overflows, or >>> run-time error handling. But if the behaviour is defined in some way, then >>> it is not an error - the compiler has to assume that you intentionally >>> wrapped your integers. >>> >>> I for one would rather have help getting my programs correct, than a >>> language that blindly accepted all my mistakes. >> >> Tools should be to targeted at programmers. If there is a tool for C >> that can detect signed arithmetic overflow, there should be one that can >> detect wrapping in two's complement arithmetic. Maybe no one implements >> such things, but that's not the fault of the language semantics. > > A tool that helps you find situations where your program acted correctly > according to language semantics is not going to be very useful. Yes, but why do you think of tools in that way? A tool that can help me reason about correctness, about cache use, about memory use and leaks and so on would be very useful. Any tool that does what you say (help a programmer detect undefined integer overflow) should be able to help a programmer detect defined integer wrapping. > It would > be possible to have a tool that logged particular correct behaviour, but I > think it is more common and more useful for tools to log (and/or halt) on > /incorrect/ behaviour. It would be vastly more useful to have tools that helped to detect incorrect behaviour as defined by the programmer and not just be the language. The latter is very narrow; the former is at the heart of what programming is. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-07-25 10:36 +0200 |
| Message-ID | <u9o1ie$12n8g$1@dont-email.me> |
| In reply to | #171232 |
(I'm off on a few weeks holiday soon, which will greatly limit how much I can read and post to Usenet. So if I don't answer you or other posters in the near future, it is not through lack of interest.) On 25/07/2023 03:42, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 23/07/2023 23:10, Ben Bacarisse wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>> <snip> >>>>> Two's complement numbers form a commutative ring. What's wrong with >>>>> that? >>>> >>>> Nothing - but equally, it has no benefit. It gives nothing particularly >>>> useful. >>> There's nothing wrong with it but relies on a screwed up idea of >>> numbers? >> >> If you don't overflow your calculations, there's nothing wrong with two's >> complement wrapping. > > If your calculation don't overflow, it's OK for them to do something > they won't do (wrap) because they don't overflow? > Yes. If your calculations don't overflow, it doesn't matter what would hypothetically happen if they had overflowed. That is how gcc (and a number of other compilers) interpret undefined behaviour, and use it for optimisation to give more efficient code on the assumption that the calculations don't overflow. My position is that overflowing calculations, on the whole, only occur as a result of errors in the code. I want two things from my compiler - help finding errors, and the most efficient code practically possible on the assumption that the source code is correct. (I also like to be able to change the balance between these using compiler flags.) UB on overflow is a positive thing for both of these. I can't see the point in a feature that - given a bug in my code leading to overflow, goes out of its way to guarantee a particular type of garbage out when it gets garbage in. By the time the program flow reaches a point where two's complement wrapping is specifically generated (rather than just by coincidence as the most efficient code for arithmetic without wrapping semantics), the wrapping only applies if the values were wrong from before. >> But for most use of integer calculations, if you >> overflow, something has gone wrong. Believing that a wrapped value is >> somehow "correct" is - in most cases - a screwed up idea of numbers. > > But I did not say that wrapped values should be believed to be correct. > You seemed to be saying that simply defining it to happen was a screwed > up notion of numbers. > Fair point. So your position here is that it is advantageous to have a definition of the overflow behaviour, without any requirement for the result to be "correct" in any sense? Would you be equally happy (assuming the code performance was unchanged) with different defined overflow behaviour? Options include a trap or exception of some sort, a "non-signalling NaN" value, saturation, or an unspecified value (that is, a valid member of the type, but with no information about what value). >> My point is that having a neat mathematical description or certain >> functionalities does not necessarily make a particular model for fixed-size >> integers better than alternatives. Giving a mathematical name to the model >> does not aid programmers or make incorrect code correct - defined incorrect >> results are still wrong. > > But there are advantages to having defined incorrect answers over > undefined incorrect answers. > What are they? This is something people often say, yet are rarely able to justify. I've given reasons why having undefined behaviour is better than defined incorrect answers (optimisation opportunities, and better debugging and run-time checking options). The most common reason I have seen for supporting "defined incorrect" answers is to aid debugging (always a noble aim). The argument is that outputting a consistent wrong answer makes it easier to find a bug and confirm the fix. While I agree with that to some extent, in practice the same thing happens with UB-based optimisation. In theory, a compiler can use UB to generate code that gives the answer you expect on most days but wipes your hard disk when run on Tuesday afternoon. But in practice, compilers are deterministic and the code they generate is deterministic - given the same inputs, you'll get consistent outputs, with as much chance of this aiding your bug-hunting as you get from having defined incorrect answers. (The exception is when the "defined incorrect" behaviour is an immediate halt with error, which could help you find the problem faster. Of course, that's the option you have with UB - a compiler can offer flags to have such behaviour during debugging.) Another common reason for "defined incorrect" behaviour is to claim it avoids making things worse by having predictable behaviour. The reality is that this is simply not true. Once you have incorrect values, you are outside the specifications of the expected behaviour of your code - the consequences are unpredictable. Bugs and incorrect behaviour can spread, or they can die away with minor inconvenience - this is basically independent on whether the incorrect behaviour was defined or not. A famous example of the consequences of integer overflow is found in the original Civilisation game, with the AI leader Ghandi. The AI leaders have, amongst their other characteristics, a "peacefulness" score from 0 (psychotic) to 255 (at one with the universe). Ghandi starts at maximum peacefulness, and never attacks others. But once atomic weapons are developed in the game, every leader gets a bit more cautious about starting a war, and their peacefulness score is increased by 2. Due to wrapping of an 8-bit number, Ghandi is now at 1 and immediately declares nuclear war on everyone else. So - why do /you/ think that defined incorrect behaviours are better than undefined incorrect behaviours? >> C is defined by the behaviour of the abstract machine, not implementations. >> The abstract machine was designed with ease of efficient implementation in >> mind, but the effect of hardware instructions does not define the C >> language. > > I am not talking about C. I was simply responding to the notion that > wrapping in based on a screwed-up notion of numbers. OK. Let me instead suggest it is based on a different notion of numbers from the ordinary everyday integers. And an approximation to the ordinary everyday integers is what programmers are almost always trying to get when they use standard integer types in programming. Those of us with a more mathematical background or interests know the concept of "number" can be very much wider, but it is rarely relevant for general programming. > >>> Yes, but you get the right answers by thinking clearly and understanding >>> what the parts of a program do. I think that easier with plain two's >>> complement arithmetic. >> >> I disagree (to the second sentence - I obviously agree to the first). I >> find if far easier to reason about arithmetic if I make sure my >> calculations and types are such that overflow never occurs. > > How can that be any harder if arithmetic wraps than if it undefined? > For one thing, undefined means it might wrap. I want to reason about my code with /no/ overflows. Any behaviour on overflow is hypothetical. To me, giving a definition to some behaviour means people will expect particular behaviour. I might specify a function like this : // Precondition: abs(x) <= sqrt(INT_MAX) // Postcondition: result = x^2 int square(int x); If we wanted to specify defined two's complement wrapping behaviour (for 32-bit int), we could change the post condition to: // Postcondition: result = (x^2 + 2^31) mod 2^32 - 2^31 This is not nearly as nice to reason about. And some people would assume this holds for input values that do not satisfy the pre-condition. Leaving out any possibility or definition for overflow behaviour keeps it all simpler and clearer. > >> Overflow >> semantics, or lack thereof, are then not an issue - my integers behave like >> simple plain mathematical integers. > > So you don't care what happens on overflow. Yet you seem to say that > one choice for overflow behaviour makes this avoiding of overflow easier. > I am not asking for a particular choice of overflow behaviour - I am asking for /no/ choice of overflow behaviour. I prefer to say that overflow doesn't happen. Part of my job as a programmer is to ensure that this is the case. And if overflow does not happen, then any discussion of what happens if it does happen, is an irrelevant distraction and waste of effort, and can lead both programmers and compilers to poorer quality results. > [Sorry, I cut an example that you might have taken great care in > choosing, but I could not immediately see its relevance. If that was a > mistake I apologise and I'll take a close look at it.] > That's okay. As I said, it's not easy to make real examples that demonstrate the effect, so it was somewhat randomly generated. Just because a compiler /can/ optimise based on overflow being UB, does not mean that they /will/ do so in any given case - very often wrapping code is as good as it gets on real processors. >>>> Agreed. But it lets you have useful rules, leading to simplification for >>>> both the compiler and the programmer. Knowing that as long as the >>>> programmer hasn't made a mistake earlier in their code, "n + 1 > n" and >>>> similar rules always holds true can be useful. >>> Interesting. Can you give an example where this rule helps a programmer >>> (and plain two's complement would not)? >> >> I don't think rules like this are going to be of much help directly to a >> programmer. > > I re-worded your claim and I think that's led us off track again. You > did not say it helps, you said it can lead "to simplification for > ... the programmer". Can you give an example of this simplification? > I think we might be travelling down several tracks at once! Let me just say that the more optimisations a compiler can do, the more a programmer can write their code in a manner that is clear and maintainable, and the less they need to think about arranging their source code to produce efficient object code. (Of course for most code, efficient results are not particularly relevant - but if it wasn't somewhat important for at least some parts of your code, then you probably wouldn't be or shouldn't be programming in C.) > >>>> Even better, IMHO - when something is undefined behaviour, a compiler or >>>> debugging tool can consider it an error. That means you can use tools to >>>> help catch bugs in your code - static analysis of potential overflows, or >>>> run-time error handling. But if the behaviour is defined in some way, then >>>> it is not an error - the compiler has to assume that you intentionally >>>> wrapped your integers. >>>> >>>> I for one would rather have help getting my programs correct, than a >>>> language that blindly accepted all my mistakes. >>> >>> Tools should be to targeted at programmers. If there is a tool for C >>> that can detect signed arithmetic overflow, there should be one that can >>> detect wrapping in two's complement arithmetic. Maybe no one implements >>> such things, but that's not the fault of the language semantics. >> >> A tool that helps you find situations where your program acted correctly >> according to language semantics is not going to be very useful. > > Yes, but why do you think of tools in that way? A tool that can help me > reason about correctness, about cache use, about memory use and > leaks and so on would be very useful. Any tool that does what you say > (help a programmer detect undefined integer overflow) should be able to > help a programmer detect defined integer wrapping. > If overflow is fully defined behaviour, then it is part of the language. It is now normal behaviour in normal code, not an indication of an error. A tool /could/ track it, just as it could track every multiplication or every variable assignment. But you are monitoring normal define behaviour, rather than stopping on erroneous exceptional behaviour. >> It would >> be possible to have a tool that logged particular correct behaviour, but I >> think it is more common and more useful for tools to log (and/or halt) on >> /incorrect/ behaviour. > > It would be vastly more useful to have tools that helped to detect > incorrect behaviour as defined by the programmer and not just be the > language. The latter is very narrow; the former is at the heart of what > programming is. > Agreed.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-07-25 16:41 +0100 |
| Message-ID | <87cz0gj8wl.fsf@bsb.me.uk> |
| In reply to | #171236 |
David Brown <david.brown@hesbynett.no> writes:
> (I'm off on a few weeks holiday soon, which will greatly limit how much I
> can read and post to Usenet. So if I don't answer you or other posters in
> the near future, it is not through lack of interest.)
>
>
>
> On 25/07/2023 03:42, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 23/07/2023 23:10, Ben Bacarisse wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>
>
> <snip>
>
>>>>>> Two's complement numbers form a commutative ring. What's wrong with
>>>>>> that?
>>>>>
>>>>> Nothing - but equally, it has no benefit. It gives nothing particularly
>>>>> useful.
>>>> There's nothing wrong with it but relies on a screwed up idea of
>>>> numbers?
>>>
>>> If you don't overflow your calculations, there's nothing wrong with two's
>>> complement wrapping.
>> If your calculation don't overflow, it's OK for them to do something
>> they won't do (wrap) because they don't overflow?
>>
>
> Yes. If your calculations don't overflow, it doesn't matter what would
> hypothetically happen if they had overflowed.
I know that is what you said, but you, apparently, don't see why I think
that saying "it's screwed up" and then "there's nothing wrong with it"
and explaining that with "there's nothing wrong with it if it never
happens" leaves me confused. All I can conclude is that you /do/ think
it's screwed up because there's only nothing wrong with it if it doesn't
happen. Could you not just have stuck with the "it's screwed up" and
left out the intermediate "there's nothing wrong with it"?
> That is how gcc (and a
> number of other compilers) interpret undefined behaviour, and use it for
> optimisation to give more efficient code on the assumption that the
> calculations don't overflow.
>
> My position is that overflowing calculations, on the whole, only occur as a
> result of errors in the code.
That's true in C. But in a language with defined wrapping of integer
arithmetic, such overflows might simply result from after the fact
tests. In C one writes
if (this will overflow) {
report error or whatever
}
else do calculation
With wrapping one can sometimes write
do calculation
if (it overflowed) {
report error or whatever
}
Here, overflow is "not correct" but it's not a programming error in the
sense you mean.
> I want two things from my compiler - help
> finding errors, and the most efficient code practically possible on the
> assumption that the source code is correct. (I also like to be able to
> change the balance between these using compiler flags.) UB on overflow is
> a positive thing for both of these.
That seems to be all one has, even toady. In the 80s, I looked forward
to a world where a programmer's workbench would include tools to help
verify all sorts of program properties.
How do you use a compiler to help find overflow errors? Just compile
with something like -fsanitize=undefined and do lots of testing? If so,
there's no reason a compiler for a language with wrapping arithmetic
could not be just as helpful by do something similar for overflow,
despite it not being defined. In fact I've wanted to have an unsigned
version of gcc's -ftrapv more than once.
As for optimising, I don't know enough to know how much UB helps C. man
gcc says, for example, that -fwrapv "enables some optimizations and
disables others" so it's not as simple as you make out.
> I can't see the point in a feature that - given a bug in my code leading to
> overflow, goes out of its way to guarantee a particular type of garbage out
> when it gets garbage in. By the time the program flow reaches a point
> where two's complement wrapping is specifically generated (rather than just
> by coincidence as the most efficient code for arithmetic without wrapping
> semantics), the wrapping only applies if the values were wrong from before.
>
>>> But for most use of integer calculations, if you
>>> overflow, something has gone wrong. Believing that a wrapped value is
>>> somehow "correct" is - in most cases - a screwed up idea of numbers.
>> But I did not say that wrapped values should be believed to be correct.
>> You seemed to be saying that simply defining it to happen was a screwed
>> up notion of numbers.
>>
>
> Fair point.
>
> So your position here is that it is advantageous to have a definition of
> the overflow behaviour, without any requirement for the result to be
> "correct" in any sense?
>
> Would you be equally happy (assuming the code performance was unchanged)
> with different defined overflow behaviour? Options include a trap or
> exception of some sort, a "non-signalling NaN" value, saturation, or an
> unspecified value (that is, a valid member of the type, but with no
> information about what value).
To be honest, that's hard to say. I've not used languages with enough
of those options to make an informed comment.
>>> My point is that having a neat mathematical description or certain
>>> functionalities does not necessarily make a particular model for fixed-size
>>> integers better than alternatives. Giving a mathematical name to the model
>>> does not aid programmers or make incorrect code correct - defined incorrect
>>> results are still wrong.
>>
>> But there are advantages to having defined incorrect answers over
>> undefined incorrect answers.
>
> What are they?
>
> This is something people often say, yet are rarely able to justify.
Maybe the problem is partly the words. For example, testing for
overflow at run time can be easier with a defined incorrect result.
Another comes from the simplicity of defining the semantics of + (and -
and * and so on). Having a+b be the sum of a+b or "bottom" is messier
than having it be (a+b) mod 2^width. (It's not the usual mod, it's a
biased one, but that does not really complicate matters too much.)
Finally, there are cases that just don't need much thought. In BCPL one
writes (wrote?)
LET mid = (low + high) / 2
and there's no need to worry about overflow.
> I've given reasons why having undefined behaviour is better than defined
> incorrect answers (optimisation opportunities, and better debugging and
> run-time checking options).
I will defer to you about the optimisation, but if you have a citation
comparing the opportunities given by the two definitions I would really
like to take a look. However, nothing in having defined wrapping
prevents good debugging and run-time checking options except a narrow
view of what one considers to be the compiler's job. As I said, I've
wanted -ftrapv for unsigned arithmetic before now, ideally configurable
in the source because you don't always want it everywhere.
> The most common reason I have seen for supporting "defined incorrect"
> answers is to aid debugging (always a noble aim). The argument is that
> outputting a consistent wrong answer makes it easier to find a bug and
> confirm the fix. While I agree with that to some extent, in practice the
> same thing happens with UB-based optimisation. In theory, a compiler can
> use UB to generate code that gives the answer you expect on most days but
> wipes your hard disk when run on Tuesday afternoon. But in practice,
> compilers are deterministic and the code they generate is deterministic -
> given the same inputs, you'll get consistent outputs, with as much chance
> of this aiding your bug-hunting as you get from having defined incorrect
> answers.
Yes, I see no advantage there either way.
> (The exception is when the "defined incorrect" behaviour is an immediate
> halt with error, which could help you find the problem faster. Of course,
> that's the option you have with UB - a compiler can offer flags to have
> such behaviour during debugging.)
>
> Another common reason for "defined incorrect" behaviour is to claim it
> avoids making things worse by having predictable behaviour. The reality is
> that this is simply not true. Once you have incorrect values, you are
> outside the specifications of the expected behaviour of your code - the
> consequences are unpredictable. Bugs and incorrect behaviour can spread,
> or they can die away with minor inconvenience - this is basically
> independent on whether the incorrect behaviour was defined or not.
Yes, that sounds like a rather vague and over general argument. There
is an advantage, a small one, in being able to test, in the program,
what happened rather than having to test what would happen.
> A famous example of the consequences of integer overflow is found in the
> original Civilisation game, with the AI leader Ghandi. The AI leaders
> have, amongst their other characteristics, a "peacefulness" score from 0
> (psychotic) to 255 (at one with the universe). Ghandi starts at maximum
> peacefulness, and never attacks others. But once atomic weapons are
> developed in the game, every leader gets a bit more cautious about starting
> a war, and their peacefulness score is increased by 2. Due to wrapping of
> an 8-bit number, Ghandi is now at 1 and immediately declares nuclear war on
> everyone else.
Left without comment for reference below.
> So - why do /you/ think that defined incorrect behaviours are better than
> undefined incorrect behaviours?
See above.
>>> C is defined by the behaviour of the abstract machine, not implementations.
>>> The abstract machine was designed with ease of efficient implementation in
>>> mind, but the effect of hardware instructions does not define the C
>>> language.
>> I am not talking about C. I was simply responding to the notion that
>> wrapping in based on a screwed-up notion of numbers.
>
> OK. Let me instead suggest it is based on a different notion of numbers
> from the ordinary everyday integers.
How is declaring that a+b has no defined meaning any less of a different
notion of numbers from ordinary everyday integers?
Mind you, "ordinary everyday integers" is a bit of a myth:
> And an approximation to the ordinary
> everyday integers is what programmers are almost always trying to get when
> they use standard integer types in programming.
Your peacefulness score example is a counter-example. What's wanted
there (presumably) is saturating integer arithmetic. Do I want signed
integers for string and array lengths? What about shoe sizes? In C,
numbers are often used simply to get n distinct, easily tested, value
(like an enum) but where any arithmetic should be considered an error.
I would guess that there are far fewer "ordinary integers" in
programming that you think there are.
I used to hope that by the 21st century we'd all be using various high
level languages where programmers could declare sub-ranges with whatever
arithmetic and overflow semantics made sense for the application,
including unbounded integers is that's what was wanted. And along-side
those we'd have tools to help in verification of these type
restrictions.
>>>> Yes, but you get the right answers by thinking clearly and understanding
>>>> what the parts of a program do. I think that easier with plain two's
>>>> complement arithmetic.
>>>
>>> I disagree (to the second sentence - I obviously agree to the first). I
>>> find if far easier to reason about arithmetic if I make sure my
>>> calculations and types are such that overflow never occurs.
>> How can that be any harder if arithmetic wraps than if it undefined?
>> For one thing, undefined means it might wrap.
>
> I want to reason about my code with /no/ overflows. Any behaviour on
> overflow is hypothetical.
Eh? You never convince yourself that there are no overflows?
> To me, giving a definition to some behaviour means people will expect
> particular behaviour.
Of course. That's one reason it can, on occasion, be useful.
> I might specify a function like this :
>
> // Precondition: abs(x) <= sqrt(INT_MAX)
> // Postcondition: result = x^2
> int square(int x);
>
>
> If we wanted to specify defined two's complement wrapping behaviour (for
> 32-bit int), we could change the post condition to:
>
> // Postcondition: result = (x^2 + 2^31) mod 2^32 - 2^31
>
> This is not nearly as nice to reason about.
So why would you do that?
> And some people would assume
> this holds for input values that do not satisfy the pre-condition.
Some people might assume that for any function. Are you claiming UB is
some defence against absolute stupidity?
> Leaving out any possibility or definition for overflow behaviour keeps it
> all simpler and clearer.
Nothing in what I am saying prevents you specifying the function you
want in exactly the way you specified it.
>>> Overflow
>>> semantics, or lack thereof, are then not an issue - my integers behave like
>>> simple plain mathematical integers.
>> So you don't care what happens on overflow. Yet you seem to say that
>> one choice for overflow behaviour makes this avoiding of overflow easier.
>
> I am not asking for a particular choice of overflow behaviour - I am asking
> for /no/ choice of overflow behaviour.
I was including undefined behaviour as one choice of behaviour.
> I prefer to say that overflow
> doesn't happen. Part of my job as a programmer is to ensure that this is
> the case. And if overflow does not happen, then any discussion of what
> happens if it does happen, is an irrelevant distraction and waste of
> effort, and can lead both programmers and compilers to poorer quality
> results.
If wrapping is incorrect (i.e. your code has none of the cases I gave a
few example of above) you can do exactly the same. Nothing in wrapped
arithmetic prevents you from showing that your program is free from it.
And there is no reason for you to be distracted by discussing something
that you have proved does not happen.
>>>>> Agreed. But it lets you have useful rules, leading to simplification for
>>>>> both the compiler and the programmer. Knowing that as long as the
>>>>> programmer hasn't made a mistake earlier in their code, "n + 1 > n" and
>>>>> similar rules always holds true can be useful.
>>>> Interesting. Can you give an example where this rule helps a programmer
>>>> (and plain two's complement would not)?
>>>
>>> I don't think rules like this are going to be of much help directly to a
>>> programmer.
>> I re-worded your claim and I think that's led us off track again. You
>> did not say it helps, you said it can lead "to simplification for
>> ... the programmer". Can you give an example of this simplification?
>
> I think we might be travelling down several tracks at once!
>
> Let me just say that the more optimisations a compiler can do, the more a
> programmer can write their code in a manner that is clear and maintainable,
> and the less they need to think about arranging their source code to
> produce efficient object code.
Can you give an example where UB overflows leads to some simplification
for the programmer. I can only think of counter-examples (I showed a
couple above).
>>>>> Even better, IMHO - when something is undefined behaviour, a compiler or
>>>>> debugging tool can consider it an error. That means you can use tools to
>>>>> help catch bugs in your code - static analysis of potential overflows, or
>>>>> run-time error handling. But if the behaviour is defined in some way, then
>>>>> it is not an error - the compiler has to assume that you intentionally
>>>>> wrapped your integers.
>>>>>
>>>>> I for one would rather have help getting my programs correct, than a
>>>>> language that blindly accepted all my mistakes.
>>>>
>>>> Tools should be to targeted at programmers. If there is a tool for C
>>>> that can detect signed arithmetic overflow, there should be one that can
>>>> detect wrapping in two's complement arithmetic. Maybe no one implements
>>>> such things, but that's not the fault of the language semantics.
>>>
>>> A tool that helps you find situations where your program acted correctly
>>> according to language semantics is not going to be very useful.
>> Yes, but why do you think of tools in that way? A tool that can help me
>> reason about correctness, about cache use, about memory use and
>> leaks and so on would be very useful. Any tool that does what you say
>> (help a programmer detect undefined integer overflow) should be able to
>> help a programmer detect defined integer wrapping.
>>
>
> If overflow is fully defined behaviour, then it is part of the language.
> It is now normal behaviour in normal code, not an indication of an
> error.
a[i + 1] is an error if i is 2 and the array and only three elements.
You are privileging one small kind of error as one we might want help
finding.
> A tool /could/ track it, just as it could track every multiplication or
> every variable assignment.
Yes, just like we have incredibly valuable tools that can track array
indexing.
> But you are monitoring normal define behaviour,
> rather than stopping on erroneous exceptional behaviour.
We are monitoring correct behaviour and stopping when there's a bug.
Mind you, I am only championing detecting wrapping because you being up
detecting overflow and both are equally possible. In the vast majority
of cases we want much more specific detection than either of these.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-07-25 16:22 +0000 |
| Message-ID | <WESvM.32422$JG_b.9358@fx39.iad> |
| In reply to | #171238 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>David Brown <david.brown@hesbynett.no> writes:
>
>>
>> My position is that overflowing calculations, on the whole, only occur as a
>> result of errors in the code.
>
>That's true in C. But in a language with defined wrapping of integer
>arithmetic, such overflows might simply result from after the fact
>tests. In C one writes
>
> if (this will overflow) {
> report error or whatever
> }
> else do calculation
>
>With wrapping one can sometimes write
>
> do calculation
> if (it overflowed) {
> report error or whatever
> }
>
>Here, overflow is "not correct" but it's not a programming error in the
>sense you mean.
Overflow might actually "be correct", I just wrote such code last week.
Simulating a microcontroller countdown timer - when it wraps, an
exception needs to be generated and the timer register is reloaded.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-07-25 17:40 +0100 |
| Message-ID | <u9otu5$15mpl$1@dont-email.me> |
| In reply to | #171238 |
On 25/07/2023 16:41, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: >> If overflow is fully defined behaviour, then it is part of the language. >> It is now normal behaviour in normal code, not an indication of an >> error. > > a[i + 1] is an error if i is 2 and the array and only three elements. > You are privileging one small kind of error as one we might want help > finding. That's the kind of UB which is genuinely undefined, as the result can be unpredictable: it may return garbage, or may give a memory error if outside an allocation. (It could also be well-defined, IMV at least, if the 3-element array is in the middle of a struct or union.) But any UB due to integer overflow would be largely caused by a compiler deliberately invoking a certain behaviour because the UB tag gives it the licence to do so. This is to provide some alleged benefit, but it means the same program, on the same hardware, perhaps even with the same compiler with slightly different options, could give different, unpredictable results. Not because hardware gives you garbage, but on purpose.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-07-26 02:40 -0700 |
| Message-ID | <86mszjqacu.fsf@linuxsc.com> |
| In reply to | #171242 |
Bart <bc@freeuk.com> writes: > But any UB due to integer overflow would be largely caused by a > compiler deliberately invoking a certain behaviour because the UB > tag gives it the licence to do so. This statement is wrong. Compilers don't cause undefined behavior. "Undefined behavior" is simply a specification; the specification doesn't change regardless of what a compiler might or might not do in response to it.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-07-26 11:30 +0100 |
| Message-ID | <u9qskd$1fdli$2@dont-email.me> |
| In reply to | #171273 |
On 26/07/2023 10:40, Tim Rentsch wrote: > Bart <bc@freeuk.com> writes: > >> But any UB due to integer overflow would be largely caused by a >> compiler deliberately invoking a certain behaviour because the UB >> tag gives it the licence to do so. > > This statement is wrong. Compilers don't cause undefined behavior. > "Undefined behavior" is simply a specification; the specification > doesn't change regardless of what a compiler might or might not do > in response to it. That's the 'if (n+1 > n)' example that someone posted a few days ago, when 'n' had the value INT_MAX. It gave different results on the same hardware DEPENDING ON compiler. That is the unpredictable, undefined behaviour I'm refering to. So it is purely up to the compiler, not the language. A dumb compiler doing a mechanical translation to code running on a typical two's complement machine, where signed integer overflow has documented behaviour, would give the expected results consistently. A 'clever' compiler such as gcc would give unexpected results IN SOME CASES (which is where the problem lies). And it uses the UB within the language as an excuse to do that, with the justification that it can skimp on some code. 'In Some Cases' means where, when compiling 'if (a+1 > b)' the compiler somehow knows that integer overflow will occur (because `a` is infered to have the value INT_MAX for example).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-07-26 06:41 -0700 |
| Message-ID | <86ila6rdqz.fsf@linuxsc.com> |
| In reply to | #171276 |
Bart <bc@freeuk.com> writes: > On 26/07/2023 10:40, Tim Rentsch wrote: > >> Bart <bc@freeuk.com> writes: >> >>> But any UB due to integer overflow would be largely caused by a >>> compiler deliberately invoking a certain behaviour because the UB >>> tag gives it the licence to do so. >> >> This statement is wrong. Compilers don't cause undefined behavior. >> "Undefined behavior" is simply a specification; the specification >> doesn't change regardless of what a compiler might or might not do >> in response to it. > > That's the 'if (n+1 > n)' example that someone posted a few days ago, > when 'n' had the value INT_MAX. > > It gave different results on the same hardware DEPENDING ON > compiler. That is the unpredictable, undefined behaviour I'm refering > to. [...] I understand. You are misusing the term "undefined behavior". I responded to point out the misuse.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-07-27 01:06 +0100 |
| Message-ID | <87bkfyi5f0.fsf@bsb.me.uk> |
| In reply to | #171242 |
Bart <bc@freeuk.com> writes: > On 25/07/2023 16:41, Ben Bacarisse wrote: >> David Brown <david.brown@hesbynett.no> writes: >>> If overflow is fully defined behaviour, then it is part of the language. >>> It is now normal behaviour in normal code, not an indication of an >>> error. >> >> a[i + 1] is an error if i is 2 and the array and only three elements. >> You are privileging one small kind of error as one we might want help >> finding. > > That's the kind of UB which is genuinely undefined, as the result can be > unpredictable: it may return garbage, or may give a memory error if outside > an allocation. (It could also be well-defined, IMV at least, if the > 3-element array is in the middle of a struct or union.) If you were any other poster I would say that I think the word "behaviour" in "undefined behaviour" has led you to misunderstand the term. But I can't figure out how, after all these years, you don't know what the term means. Are you deliberately misusing it just to get people to chat (AKA trolling) or do you really no know? -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 11 of 49 — ← Prev page 1 … 9 10 [11] 12 13 … 49 Next page →
Back to top | Article view | comp.lang.c
csiph-web