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 10 of 49 — ← Prev page 1 … 8 9 [10] 11 12 … 49 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-08-12 10:57 -0700 |
| Message-ID | <86r0o887op.fsf@linuxsc.com> |
| In reply to | #171267 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
> [...]
>
>>> Yes, C++ calls them literals. But that site does use the same
>>> terminology as the C standard when talking about C:
>>>
>>> https://en.cppreference.com/w/c/language/integer_constant
>>>
>>> I prefer C++'s usage, since "integer constant" can be so easily
>>> confused for "integer constant expression".
>>
>> Using the same term for both suggests a false equivalence, and
>> also is ahistorical. The two kinds of entities are fundamentally
>> different: constants denote values, literals denote objects.
>> Constants, like mathematical constants, always denote the same
>> value; literals denote different objects at different times or
>> places, even if the values used to produce a given literal are
>> always the same, which they need not be. The distinctions are
>> too important to gloss over by using a common term for both.
>
> When you say that "literals denote objects", are you referring
> specifically to the way C uses the terms "string literal" and
> "compound literal"?
>
> I haven't done an exhaustive search, but every language other than
> C whose documentation I've just checked (C++, Ada, Perl, Python,
> Go, Java) calls 42 an integer literal and "foo" a string literal.
> C is a bit of an outlier in callling 42 an integer constant.
>
> I suggest that the fact that C uses "constant" for tokens that
> refer to values and "literal" (string or compound) for constructs
> that refer to anonymous objects was an arbitrary choice, and the
> distinction you mention is not nearly as fundamental as you
> suggest it is.
>
> I do prefer to use the term "integer constant" when discussing C,
> but the phrase "integer literal" is (a) correct in most other
> languages and (b) perfectly clear. It wouldn't occur to me that
> "integer literal" implies something that refers to an object.
The word literal, used as a noun when describing programming
languages, came into vogue sometime after it became common to
specify language syntax by using a formal grammar (usually
expressed in some variation of Backus-Naur Form); roughly the
1970s timeframe. A typical usage would be for "literal" to be
synonymous with "terminal symbol", or perhaps with just a subset
of terminal symbols, as used in the rules of grammar. In some
cases the words "constant" and "literal" were used more or less
interchangeably.
A good decade earlier, however, the word literal was used in a
somewhat different programming language context, not as part of
describing a language but as an element of the language. The
assembly language for IBM System/360 had constants, both ordinary
numeric and character constants, and symbolic constants (defined
with EQU). Constants could be used as direct operands for some
instructions, depending on the particulars of the instruction and
for which operand, and represented values encoded directly in the
instruction. Distinct from constants there were also /literals/,
a distinct category of operand that produced the address of an
initialized anonymous region of memory. Here are two example
lines of assembly, to illustrate the difference:
OI VAL+2,X'F0'
C 3,=F'1000'
In the first line, there are two constants, 2 and X'F0'. These
tokens are numerical quantities that are used directly in the
generated instruction. (In the case of the constant 2 the value
is added to the address VAL, and it is the sum that is used to
produce the bytes of the instruction, but the key property is
that the value 2 participates locally, and not remotely.)
The second line has a constant 3 and a literal =F'1000'. Like in
the first line, the value 3 is used directly in the generated
instruction. The literal =F'1000' is not used directly. Instead,
the assembler keeps track of literals used in the program, and
uses them to initialize areas of memory elsewhere in the program.
A use of a literal, such as the =F'1000' here, results in the
address of the memory area reserved for the value of the literal.
(There are some further details about literals, such as literal
pools and the LTORG directive, that I won't explain because those
details are not important to the discussion.)
Note the parallels between how these terms are used in assembly
language and in C. Constants are used to generate code but appear
only implicitly; literals always occupy areas of memory (objects)
and use of a literal causes its address (lvalue) to be part of a
generated instruction. The distinction between constants and
literals is primarily a semantic distinction, not a syntactic one.
Besides being more historically faithful, having two different
terms provides a useful semantic distinction that would disappear
if the term "literal" were used for both concepts.
>> Given a choice between the level of confusion seen in the C++
>> standard and the level of confusion seen in the C standard ("integer
>> constant" and "integer constant expression" is confusing? really?)
>> I'm happy to be on the side of C's choice any day of the week and
>> twice on Sunday. Please cast my vote to continue using the terms
>> "constant" and "literal" as they are used in the C standard.
>
> I use those terms simply because that's how they're used in the C
> standard.
Obviously it's a good idea to use terminology in the C standard
when talking about the C language. My point though is that the
terminology used in the C standard is a better choice both
historically and semantically.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-12 16:37 -0700 |
| Message-ID | <87350nomsc.fsf@nosuchdomain.example.com> |
| In reply to | #172121 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> [...]
>>>> Yes, C++ calls them literals. But that site does use the same
>>>> terminology as the C standard when talking about C:
>>>>
>>>> https://en.cppreference.com/w/c/language/integer_constant
>>>>
>>>> I prefer C++'s usage, since "integer constant" can be so easily
>>>> confused for "integer constant expression".
>>>
>>> Using the same term for both suggests a false equivalence, and
>>> also is ahistorical. The two kinds of entities are fundamentally
>>> different: constants denote values, literals denote objects.
>>> Constants, like mathematical constants, always denote the same
>>> value; literals denote different objects at different times or
>>> places, even if the values used to produce a given literal are
>>> always the same, which they need not be. The distinctions are
>>> too important to gloss over by using a common term for both.
>>
>> When you say that "literals denote objects", are you referring
>> specifically to the way C uses the terms "string literal" and
>> "compound literal"?
>>
>> I haven't done an exhaustive search, but every language other than
>> C whose documentation I've just checked (C++, Ada, Perl, Python,
>> Go, Java) calls 42 an integer literal and "foo" a string literal.
>> C is a bit of an outlier in callling 42 an integer constant.
>>
>> I suggest that the fact that C uses "constant" for tokens that
>> refer to values and "literal" (string or compound) for constructs
>> that refer to anonymous objects was an arbitrary choice, and the
>> distinction you mention is not nearly as fundamental as you
>> suggest it is.
>>
>> I do prefer to use the term "integer constant" when discussing C,
>> but the phrase "integer literal" is (a) correct in most other
>> languages and (b) perfectly clear. It wouldn't occur to me that
>> "integer literal" implies something that refers to an object.
>
> The word literal, used as a noun when describing programming
> languages, came into vogue sometime after it became common to
> specify language syntax by using a formal grammar (usually
> expressed in some variation of Backus-Naur Form); roughly the
> 1970s timeframe. A typical usage would be for "literal" to be
> synonymous with "terminal symbol", or perhaps with just a subset
> of terminal symbols, as used in the rules of grammar. In some
> cases the words "constant" and "literal" were used more or less
> interchangeably.
>
> A good decade earlier, however, the word literal was used in a
> somewhat different programming language context, not as part of
> describing a language but as an element of the language. The
> assembly language for IBM System/360 had constants, both ordinary
> numeric and character constants, and symbolic constants (defined
> with EQU). Constants could be used as direct operands for some
> instructions, depending on the particulars of the instruction and
> for which operand, and represented values encoded directly in the
> instruction. Distinct from constants there were also /literals/,
> a distinct category of operand that produced the address of an
> initialized anonymous region of memory. Here are two example
> lines of assembly, to illustrate the difference:
>
> OI VAL+2,X'F0'
> C 3,=F'1000'
>
> In the first line, there are two constants, 2 and X'F0'. These
> tokens are numerical quantities that are used directly in the
> generated instruction. (In the case of the constant 2 the value
> is added to the address VAL, and it is the sum that is used to
> produce the bytes of the instruction, but the key property is
> that the value 2 participates locally, and not remotely.)
>
> The second line has a constant 3 and a literal =F'1000'. Like in
> the first line, the value 3 is used directly in the generated
> instruction. The literal =F'1000' is not used directly. Instead,
> the assembler keeps track of literals used in the program, and
> uses them to initialize areas of memory elsewhere in the program.
> A use of a literal, such as the =F'1000' here, results in the
> address of the memory area reserved for the value of the literal.
> (There are some further details about literals, such as literal
> pools and the LTORG directive, that I won't explain because those
> details are not important to the discussion.)
>
> Note the parallels between how these terms are used in assembly
> language and in C. Constants are used to generate code but appear
> only implicitly; literals always occupy areas of memory (objects)
> and use of a literal causes its address (lvalue) to be part of a
> generated instruction. The distinction between constants and
> literals is primarily a semantic distinction, not a syntactic one.
>
> Besides being more historically faithful, having two different
> terms provides a useful semantic distinction that would disappear
> if the term "literal" were used for both concepts.
>
>
>>> Given a choice between the level of confusion seen in the C++
>>> standard and the level of confusion seen in the C standard ("integer
>>> constant" and "integer constant expression" is confusing? really?)
>>> I'm happy to be on the side of C's choice any day of the week and
>>> twice on Sunday. Please cast my vote to continue using the terms
>>> "constant" and "literal" as they are used in the C standard.
>>
>> I use those terms simply because that's how they're used in the C
>> standard.
>
> Obviously it's a good idea to use terminology in the C standard
> when talking about the C language. My point though is that the
> terminology used in the C standard is a better choice both
> historically and semantically.
Ok, that's some interesting history -- but I've never heard of anything
other than IBM System/360 assembly language (and C) that makes that
particular distinction. Most programmers these days (myself included)
are not more than vaguely familiar with System/360.
The distinction you suggest never occurred to me until you brought it up
here. (The term "string literal" appears to have been introduced in
K&R1, 1978; earlier documents use the term "string". All C documents
I've checked back to 1975 refer to integer, character, and floating
constants as "constants". B did the same. BCPL used the term "string
constant".)
Do you have other examples, or evidence that the distinction between
"literals" and "constants" has been common?
On the other hand, multiple modern languages use "literal" to refer
to what C calls "constants". I know that C only uses "literal"
to refer to string literals and compound literals, but I never
perceived any implication that a "literal" is something that refers
to an object. (And I'd have no problem if a future C standard
adopted the word "literal" for what it now calls "constants".)
A question for the group: does anyone else perceive this general
distinction between "constant" (denoting a value) and "literal"
(denoting an object)?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2023-08-13 08:16 +0000 |
| Message-ID | <OsLW3EkZJRqdlKdPP@bongo-ra.co> |
| In reply to | #172129 |
On Sat, 12 Aug 2023 16:37:07 -0700 Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > On the other hand, multiple modern languages use "literal" to refer > to what C calls "constants". I know that C only uses "literal" > to refer to string literals and compound literals, but I never > perceived any implication that a "literal" is something that refers > to an object. (And I'd have no problem if a future C standard > adopted the word "literal" for what it now calls "constants".) > > A question for the group: does anyone else perceive this general > distinction between "constant" (denoting a value) and "literal" > (denoting an object)? I've never given it much thought and I'm content to use the terms (or any other related) in the same manner as the specification(s) for the language I'm using.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-13 15:48 +0000 |
| Message-ID | <lX6CM.741124$GMN3.387991@fx16.iad> |
| In reply to | #172129 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> [...]
>>>>> Yes, C++ calls them literals. But that site does use the same
>>>>> terminology as the C standard when talking about C:
>>>>>
>>>>> https://en.cppreference.com/w/c/language/integer_constant
>>>>>
>>>>> I prefer C++'s usage, since "integer constant" can be so easily
>>>>> confused for "integer constant expression".
>>>>
>>>> Using the same term for both suggests a false equivalence, and
>>>> also is ahistorical. The two kinds of entities are fundamentally
>>>> different: constants denote values, literals denote objects.
>>>> Constants, like mathematical constants, always denote the same
>>>> value; literals denote different objects at different times or
>>>> places, even if the values used to produce a given literal are
>>>> always the same, which they need not be. The distinctions are
>>>> too important to gloss over by using a common term for both.
>>>
>>> When you say that "literals denote objects", are you referring
>>> specifically to the way C uses the terms "string literal" and
>>> "compound literal"?
>>>
>>> I haven't done an exhaustive search, but every language other than
>>> C whose documentation I've just checked (C++, Ada, Perl, Python,
>>> Go, Java) calls 42 an integer literal and "foo" a string literal.
>>> C is a bit of an outlier in callling 42 an integer constant.
>>>
>>> I suggest that the fact that C uses "constant" for tokens that
>>> refer to values and "literal" (string or compound) for constructs
>>> that refer to anonymous objects was an arbitrary choice, and the
>>> distinction you mention is not nearly as fundamental as you
>>> suggest it is.
>>>
>>> I do prefer to use the term "integer constant" when discussing C,
>>> but the phrase "integer literal" is (a) correct in most other
>>> languages and (b) perfectly clear. It wouldn't occur to me that
>>> "integer literal" implies something that refers to an object.
>>
>> The word literal, used as a noun when describing programming
>> languages, came into vogue sometime after it became common to
>> specify language syntax by using a formal grammar (usually
>> expressed in some variation of Backus-Naur Form); roughly the
>> 1970s timeframe. A typical usage would be for "literal" to be
>> synonymous with "terminal symbol", or perhaps with just a subset
>> of terminal symbols, as used in the rules of grammar. In some
>> cases the words "constant" and "literal" were used more or less
>> interchangeably.
>>
>> A good decade earlier, however, the word literal was used in a
>> somewhat different programming language context, not as part of
>> describing a language but as an element of the language. The
>> assembly language for IBM System/360 had constants, both ordinary
>> numeric and character constants, and symbolic constants (defined
>> with EQU). Constants could be used as direct operands for some
>> instructions, depending on the particulars of the instruction and
>> for which operand, and represented values encoded directly in the
>> instruction. Distinct from constants there were also /literals/,
>> a distinct category of operand that produced the address of an
>> initialized anonymous region of memory. Here are two example
>> lines of assembly, to illustrate the difference:
>>
>> OI VAL+2,X'F0'
>> C 3,=F'1000'
>>
>> In the first line, there are two constants, 2 and X'F0'. These
>> tokens are numerical quantities that are used directly in the
>> generated instruction. (In the case of the constant 2 the value
>> is added to the address VAL, and it is the sum that is used to
>> produce the bytes of the instruction, but the key property is
>> that the value 2 participates locally, and not remotely.)
>>
>> The second line has a constant 3 and a literal =F'1000'. Like in
>> the first line, the value 3 is used directly in the generated
>> instruction. The literal =F'1000' is not used directly. Instead,
>> the assembler keeps track of literals used in the program, and
>> uses them to initialize areas of memory elsewhere in the program.
>> A use of a literal, such as the =F'1000' here, results in the
>> address of the memory area reserved for the value of the literal.
>> (There are some further details about literals, such as literal
>> pools and the LTORG directive, that I won't explain because those
>> details are not important to the discussion.)
>>
>> Note the parallels between how these terms are used in assembly
>> language and in C. Constants are used to generate code but appear
>> only implicitly; literals always occupy areas of memory (objects)
>> and use of a literal causes its address (lvalue) to be part of a
>> generated instruction. The distinction between constants and
>> literals is primarily a semantic distinction, not a syntactic one.
>>
>> Besides being more historically faithful, having two different
>> terms provides a useful semantic distinction that would disappear
>> if the term "literal" were used for both concepts.
>>
>>
>>>> Given a choice between the level of confusion seen in the C++
>>>> standard and the level of confusion seen in the C standard ("integer
>>>> constant" and "integer constant expression" is confusing? really?)
>>>> I'm happy to be on the side of C's choice any day of the week and
>>>> twice on Sunday. Please cast my vote to continue using the terms
>>>> "constant" and "literal" as they are used in the C standard.
>>>
>>> I use those terms simply because that's how they're used in the C
>>> standard.
>>
>> Obviously it's a good idea to use terminology in the C standard
>> when talking about the C language. My point though is that the
>> terminology used in the C standard is a better choice both
>> historically and semantically.
>
>Ok, that's some interesting history -- but I've never heard of anything
>other than IBM System/360 assembly language (and C) that makes that
>particular distinction. Most programmers these days (myself included)
>are not more than vaguely familiar with System/360.
The Burroughs medium systems BPL compiler describes the term
LITERAL as follows:
Numeric Literal
A numeric literal is defined as an item composed of characters
chosen from the digits 0 through 9, the plus sign or minus sign
and the decimal point.
Non-Numeric Literal
A non-numeric Literal may be composed of any allowable character.
The beginning and ending of a non-numeric literal is denoted by
a quotation mark.
Undigit Numeric Literals
Hexidecimal values 10 through 15 are represented as A through F and
must be bound by @ signs when used. For example, hexadecimal 11
would be literalized by @B@. A hexadecimal literal cannot exceed
99 digits. Hexadecimal values 10 through 15, when enclosed in
percent signs (%), will represent numeric literals in byte format,
for example %F2% would cause a one-byte literal to be generated.
http://bitsavers.org/pdf/burroughs/MediumSystems/Software/5024789_BPL_7.2_198708.pdf
<snip>
>On the other hand, multiple modern languages use "literal" to refer
>to what C calls "constants". I know that C only uses "literal"
>to refer to string literals and compound literals, but I never
>perceived any implication that a "literal" is something that refers
>to an object. (And I'd have no problem if a future C standard
>adopted the word "literal" for what it now calls "constants".)
>
>A question for the group: does anyone else perceive this general
>distinction between "constant" (denoting a value) and "literal"
>(denoting an object)?
No. But then I managed to avoid the 360 family for the most part
being a burroughs employee.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-08-15 13:05 -0700 |
| Message-ID | <86fs4k6pgq.fsf@linuxsc.com> |
| In reply to | #172129 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>
>>> [...]
>>>
>>>>> Yes, C++ calls them literals. But that site does use the same
>>>>> terminology as the C standard when talking about C:
>>>>>
>>>>> https://en.cppreference.com/w/c/language/integer_constant
>>>>>
>>>>> I prefer C++'s usage, since "integer constant" can be so easily
>>>>> confused for "integer constant expression".
>>>>
>>>> Using the same term for both suggests a false equivalence, and
>>>> also is ahistorical. The two kinds of entities are fundamentally
>>>> different: constants denote values, literals denote objects.
>>>> Constants, like mathematical constants, always denote the same
>>>> value; literals denote different objects at different times or
>>>> places, even if the values used to produce a given literal are
>>>> always the same, which they need not be. The distinctions are
>>>> too important to gloss over by using a common term for both.
>>>
>>> When you say that "literals denote objects", are you referring
>>> specifically to the way C uses the terms "string literal" and
>>> "compound literal"?
>>>
>>> I haven't done an exhaustive search, but every language other than
>>> C whose documentation I've just checked (C++, Ada, Perl, Python,
>>> Go, Java) calls 42 an integer literal and "foo" a string literal.
>>> C is a bit of an outlier in callling 42 an integer constant.
>>>
>>> I suggest that the fact that C uses "constant" for tokens that
>>> refer to values and "literal" (string or compound) for constructs
>>> that refer to anonymous objects was an arbitrary choice, and the
>>> distinction you mention is not nearly as fundamental as you
>>> suggest it is.
>>>
>>> I do prefer to use the term "integer constant" when discussing C,
>>> but the phrase "integer literal" is (a) correct in most other
>>> languages and (b) perfectly clear. It wouldn't occur to me that
>>> "integer literal" implies something that refers to an object.
>>
>> The word literal, used as a noun when describing programming
>> languages, came into vogue sometime after it became common to
>> specify language syntax by using a formal grammar (usually
>> expressed in some variation of Backus-Naur Form); roughly the
>> 1970s timeframe. A typical usage would be for "literal" to be
>> synonymous with "terminal symbol", or perhaps with just a subset
>> of terminal symbols, as used in the rules of grammar. In some
>> cases the words "constant" and "literal" were used more or less
>> interchangeably.
>>
>> A good decade earlier, however, the word literal was used in a
>> somewhat different programming language context, not as part of
>> describing a language but as an element of the language. The
>> assembly language for IBM System/360 had constants, both ordinary
>> numeric and character constants, and symbolic constants (defined
>> with EQU). Constants could be used as direct operands for some
>> instructions, depending on the particulars of the instruction and
>> for which operand, and represented values encoded directly in the
>> instruction. Distinct from constants there were also /literals/,
>> a distinct category of operand that produced the address of an
>> initialized anonymous region of memory. Here are two example
>> lines of assembly, to illustrate the difference:
>>
>> OI VAL+2,X'F0'
>> C 3,=F'1000'
>>
>> In the first line, there are two constants, 2 and X'F0'. These
>> tokens are numerical quantities that are used directly in the
>> generated instruction. (In the case of the constant 2 the value
>> is added to the address VAL, and it is the sum that is used to
>> produce the bytes of the instruction, but the key property is
>> that the value 2 participates locally, and not remotely.)
>>
>> The second line has a constant 3 and a literal =F'1000'. Like in
>> the first line, the value 3 is used directly in the generated
>> instruction. The literal =F'1000' is not used directly. Instead,
>> the assembler keeps track of literals used in the program, and
>> uses them to initialize areas of memory elsewhere in the program.
>> A use of a literal, such as the =F'1000' here, results in the
>> address of the memory area reserved for the value of the literal.
>> (There are some further details about literals, such as literal
>> pools and the LTORG directive, that I won't explain because those
>> details are not important to the discussion.)
>>
>> Note the parallels between how these terms are used in assembly
>> language and in C. Constants are used to generate code but appear
>> only implicitly; literals always occupy areas of memory (objects)
>> and use of a literal causes its address (lvalue) to be part of a
>> generated instruction. The distinction between constants and
>> literals is primarily a semantic distinction, not a syntactic one.
>>
>> Besides being more historically faithful, having two different
>> terms provides a useful semantic distinction that would disappear
>> if the term "literal" were used for both concepts.
>>
>>
>>>> Given a choice between the level of confusion seen in the C++
>>>> standard and the level of confusion seen in the C standard ("integer
>>>> constant" and "integer constant expression" is confusing? really?)
>>>> I'm happy to be on the side of C's choice any day of the week and
>>>> twice on Sunday. Please cast my vote to continue using the terms
>>>> "constant" and "literal" as they are used in the C standard.
>>>
>>> I use those terms simply because that's how they're used in the C
>>> standard.
>>
>> Obviously it's a good idea to use terminology in the C standard
>> when talking about the C language. My point though is that the
>> terminology used in the C standard is a better choice both
>> historically and semantically.
>
> Ok, that's some interesting history -- but I've never heard of
> anything other than IBM System/360 assembly language (and C) that
> makes that particular distinction. Most programmers these days
> (myself included) are not more than vaguely familiar with
> System/360.
I have seen "literal" used in the descriptions of other high level
languages in much the same sense that it is used in C and in 360
Assembly. I don't remember where and haven't made an effort to
track them down.
> The distinction you suggest never occurred to me until you brought
> it up here. (The term "string literal" appears to have been
> introduced in K&R1, 1978; earlier documents use the term "string".
> All C documents I've checked back to 1975 refer to integer,
> character, and floating constants as "constants". B did the same.
> BCPL used the term "string constant".)
>
> Do you have other examples, or evidence that the distinction
> between "literals" and "constants" has been common?
I think this question misses the point of my comments. The word
"constant" seems reasonable to me for the sorts of things that C
calls constants; maybe another word would be okay, I haven't
really thought about it. My point though is not that "constant" is
right but that "literal" is wrong, both because it is ahistorical
and because it hides an important semantic distinction.
Furthermore, using "literal" for both constants and literals is bad
in another way, because the secondary meaning of "literal" had to
do with a lexical property (that "literals" correspond to terminal
symbols), but that property is lost when applied to things like
compound literals. I don't know if other languages do something
like that, but if they do then they are showing poor use of
language - in particular, copying the form of a word use without
understanding the underlying meaning. There's no reason to copy
bad examples, no matter how many of them there are.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-08-15 14:20 -0700 |
| Message-ID | <86bkf86lzx.fsf@linuxsc.com> |
| In reply to | #172129 |
A postscript to my recent posting...
Perusing the C++ standard, I stumbled on this note:
Note: A literal type is one for which it might be possible
to create an object within a constant expression. It is not
a guarantee that it is possible to create such an object,
nor is it a guarantee that any object of that type will be
usable in a constant expression. --end note
No point to make, I just thought it's amusing.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-07-25 20:08 -0700 |
| Message-ID | <868rb3s72a.fsf@linuxsc.com> |
| In reply to | #171208 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > I prefer C++'s usage, since "integer constant" can be so easily > confused for "integer constant expression". P.S. It might help to remember that "integer constant expression" is parsed as "integer (constant expression)", because if it were the other way then it would be written "integer-constant expression".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-07-24 20:19 +0200 |
| Message-ID | <u9mfbm$omis$1@dont-email.me> |
| In reply to | #171200 |
On 24/07/2023 11:58, Bart wrote: > On 24/07/2023 08:50, David Brown wrote: > > On 23/07/2023 21:18, Bart wrote: > >> Including C. Since C is used in the OSes of those systems, in the APIs > >> of countless libraries, and is used to implement or be the target of > >> half those languages. > > > > To the nearest percent, 0% of programmers are involved in coding for > > operating systems or common libraries. > > Their APIs are usually expressed in C terms. I'm talking about Windows > and Linux. (MS tends to label many as 'C++' even when they are clearly C > only.) > > This actually the reason why I first got involved with C at all: to be > able to use Windows. > When you write your own languages, or program in assembly, you are responsible for everything. But people using Python, Rust, Java, C#, TCL, or whatever, will use interface libraries in their language in order to access the external shared libraries or OS calls. > >> But you are saying all those people above cannot assume a 32-bit int, > >> because a small number of embedded C developers are using machines > >> where the compiler has chosen a 16-bit type. > > > > No, I never said any such thing - nothing even close to that. > > You said I was wrong to assume that 'int' in C implementations was > commonly 32 bits, and pointed out that the number of instances of > devices that are programmed using a C with 16-bit int outnumber all others. > No, I said it was wrong to write as though it was /always/ 32-bit. > (At least it uses 16 and not something like 12 bits; I guess no one is > using the PDP8 any more.) No C (standard) implementation has ever used 12-bit int. 12-bit char, sure, but not 12-bit int. > >> It still leaves the problem of integer literals having a `int` type > >> that now doesn't match their chosen alternative. > > > > No, it does not. > > > > Integer constants (since that is the correct term - "literal" is only > > used for "string literal" in C) > > You're right, the C standard only uses that for string literals and > compound literals. But in the wider world, 'integer literal' is commonly > used to mean 'integer constant', including in this C++ reference: > > https://en.cppreference.com/w/cpp/language/integer_literal Read again what I wrote. In /C/, the term for things like 12345 is "integer constant". This is described clearly in section 6.4.4, right before the section on "string literals". In /C++/, which sometimes uses significantly different terminology, the concept of "literal" is far wider - it includes not only "string literals" and "integer literals" but also user-define literals, and "literal types". The C++ reference you give, unsurprisingly, describes the C++ term. At the bottom of the page under "See also", it has a link to "C documentation for integer constant". You have a habit of stubbornly resisting use of C standard terms, despite posting in a C language group and discussing the C language. We all know what you mean by "integer literal", but it still makes sense to use the correct terms. > > I use 'literal' in an even broader sense for all sorts of constructors > for floats, bignums, ranges, characters, records, lists and dicts. > Anywhere where you 'literally' enumerate the actual value(s), and it is > not hidden behind a name. > For your own language, that's fine - it's an appropriate choice of term. The C term "constant" was picked before "const" was added to the language, by which time it was too late to change to "literal". But when you are discussing C, the correct term is "constant" (or "integer constant" for integers).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-07-21 14:52 +0200 |
| Message-ID | <u9dv2c$38ir2$1@dont-email.me> |
| In reply to | #171028 |
On 21/07/2023 12:21, Bart wrote:
> On 21/07/2023 02:28, Keith Thompson wrote:
> > Bart <bc@freeuk.com> writes:
> >> On 21/07/2023 00:58, Keith Thompson wrote:
> >>> No, it's not. It's exactly the output the program produced when I
> >>> compiled and ran it.
> >>> Please explain what you mean by "fake result". Are you insinuating
> >>> that
> >>> I lied about it?
> >>
> >> No. gcc on my machine hard-codes that output without bothering to
> >> execute the comparison to see what the hardware does with it.
> >
> > Are you saying that that's what you meant by "fake result"? Are you
> > saying there's something "fake" about not emitting an ADD instruction in
> > response to a C "+" operation? Is evaluating 2+2 at compile time
> > "fake"?
>
> Transforming 2+2 is more acceptable since the result is always going to
> be consistent. It is not controversial.
If it is merely "more" acceptable, then it is still controversial.
There will be people who don't understand how the C language works who
feel it should be translated into assembly instructions to add 2 and 2.
You understand a bit more than such people, and thus think 2 + 2 can be
pre-calculated at compile time, but you apparently still don't
understand that the same applies to the comparison in Keith's program.
>
>
> >> Because it makes an assumption about the result of comparing n+1 with
> >> n. If those same two values were compared via variables where it did
> >> not not know their values and their relationship, it would be forced
> >> to do an actual comparison.
> >
> > Yes. Are you under the impression I didn't know that? Do you think the
> > assumption is invalid, given that the code's behavior is undefined?
> >
> >> On my machine, that produced a different result even still comparing
> >> values of INT_MAX+1 with INT_MAX.
> >
> > And what exactly is your point?
>
> What was yours?
His point - if I may be so bold as to interpret Keith's post - was that
real-world compilers regularly make use of assumptions about UB in order
to generate more efficient code. An example does not prove that this is
how the C language is defined, but it /does/ prove that mainstream
toolmakers believe that. (And the people behind the gcc compiler know
more about the definition of the language than you or I do.)
>
> You posted a piece of code and challenged people to try it themselves on
> their own platforms.
No, he did not. He posted a piece of code and ran it on his own system.
>
> However, the platform doesn't matter: gcc will always produce that
> result no matter what. It does not attempt to put the actual hardware to
> the test.
>
Why would you think it would do that? There's nothing
hardware-dependent in Keith's program.
When I am investigating how a compiler treats particular code pieces, I
usually don't bother running it at all on any hardware - it's a lot more
efficient and insightful (to me) to use godbolt and look at the
generated assembly. The hardware is irrelevant, beyond
implementation-dependent details like the size of the types and the
value of INT_MAX.
> There was me looking at the output of my compilers trying to figure why
> it was different, and gcc is not even bothering generating the
> instructions.
>
If you had looked up instead, you'd have seen Keith's point flying over
your head.
> It's a like taking a program that calculates and prints fib(36), and
> then discovering that the winning compiler or interpreter is only
> emitting puts("14930352") and not doing the actual work.
>
And that would be perfectly reasonable. We already know you have no
idea how to benchmark tools.
> Suppose someone is tasked with surveying dozens of machines to find out
> exactly what `if (n+1>n)` produces. Well, if they're using gcc, they
> might as well not bother, as they're not going to find out what /the
> machine/ produces, only what gcc has decided it should produce.
They would manage fine with gcc - /if/ they understand the language and
how to test compilers. You, apparently, do not, and are flummoxed by
the task.
>
> Presumably your point was to demonstrate something about the
> unpredictability of UB, but your chosen compiler had already made up its
> mind in advance that it was going to do X no matter what!
>
> This is what you said:
>
> >(This applies only to the quick experiment I just did, and could vary
> with the phase of the moon.)
>
> I doubt anything would make gcc do anything different!
Different code could give different results. Different versions of gcc
could give different results. Different flags could give different
results. It's undefined behaviour - only a fool would expect some
particular consistent choice of output. /That/ is the point. It would
be nice if you tried harder to understand.
>
> But if you still can't see my objection, then forget it.
>
>
> > Or are you just trying to make this look worse and more complicated than
> > it really is?
>
> I consider inconsistency in comparing the same two values to be poor.
As always - you are allowed to have an opinion on whether you like or
dislike the way C specifies this kind of thing. You are not allowed an
opinion on /how/ it specifies it - only on whether or not you like it or
approve of it. Understand the facts first - then form an opinion.
Oh, and note that it is not the comparison that is UB - comparison of
two int expressions is fully defined in C. It is the overflow on the
addition (INTMAX + 1) that is UB.
> That is, comparing INT_MIN with INT_MAX. Because if you do this:
>
> int b = INT_MAX;
> int a = b+1; // yields INT_MIN even with gcc
It /might/ yield INT_MIN. It might not. It might crash the program
when it runs (try compiling with -fsantize=undefined). It might
complain at compile time. (gcc will do that if you mark "b" as "const".
I think it is weak that it does not do so for non-const "b", but
compilers can't warn about all bad code.) It is undefined behaviour -
maybe it will do what /you/ want it to do, but maybe not.
And it can certainly get in a self-contradictory state - it is /fine/
for the compiler to store one thing in "a" (if it bothers doing that at
all) while also tracking known facts about "a" for use in later
optimisations - such as a comparison. The compiler tracks range and
value facts all the time, allowing all kinds of optimisations. If you
give it code that gives the compiler contradictory information, you can
expect the possibility of contradictory results. Lying to your compiler
is not a good idea - it always ends in tears.
>
> if (a>b) {
>
> that will get a different results compared with 'if (b+1, b)`. Is that
> supposed to be good?
It's garbage in, garbage out. Charles Babbage had this figured out - it
really should not come as a surprise to you.
Despite having written several compilers of your own, I really don't
think you understand how they work. A compiler is not a dumb translator
that works line by line. It analyses the code and forms internal graphs
tracking information and decisions. It re-arranges things to minimise
dependencies, re-use calculations, pre-calculate what it can, eliminate
redundant code, merge loads, stores and calculations, etc. The
statement "if (a > b) {" can therefore be transformed to "if (b + 1 >
b)" and then "if (true)", regardless of any writes to "a" which may or
may not take place, and which may be moved forwards or backwards in the
code.
And yes, this is /good/. It lets people write their code in whatever
makes the most sense when writing it - they can write clear and
maintainable source code, without getting bogged down in
micro-optimisations and concerns about the details of the code
generation. Human programmers can do what they do best, and let the
compiler do what it does best.
It is only a problem if there is a programmer who disregards the rules
of the language (and you certainly can't claim you don't know these
particular rules - if you break them, it is by intention). Compilers
can provide tools to help programmers spot accidental mistakes (and they
can always get better at this), but they can't force you to write proper
code.
>
> Comparing values at the limits of a type's bounds is always going to be
> dodgy anyway, but at least you might expect the results to be always the
> same.
Comparing integer type values is always defined. It can be "dodgy" if
you are mixing signed and unsigned types, or if you are comparing
non-finite floating point values and don't know the rules for how they
work. But comparing two ints is always fine - just as executing UB such
as adding 1 to INT_MAX is never fine.
>
> Note that if you do this test using unsigned and UINT_MAX, gcc also
> hardcodes the result, even this in this case it knows that b+1 could
> wrap around to zero. The result showed will be wrong, but so is mine. At
> least it is consistent with the signed version!
With unsigned types, it is not a case of "may wrap around to zero", it
is a case of "/must/ wrap around to zero". That's the way unsigned
integer arithmetic is defined. The result shown will be correct -
because that is how unsigned arithmetic works.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-07-21 16:14 +0100 |
| Message-ID | <u9e7bp$3a1ug$1@dont-email.me> |
| In reply to | #171032 |
On 21/07/2023 13:52, David Brown wrote:
> On 21/07/2023 12:21, Bart wrote:
>> On 21/07/2023 02:28, Keith Thompson wrote:
>> > Bart <bc@freeuk.com> writes:
>> >> On 21/07/2023 00:58, Keith Thompson wrote:
>> >>> No, it's not. It's exactly the output the program produced when I
>> >>> compiled and ran it.
>> >>> Please explain what you mean by "fake result". Are you insinuating
>> >>> that
>> >>> I lied about it?
>> >>
>> >> No. gcc on my machine hard-codes that output without bothering to
>> >> execute the comparison to see what the hardware does with it.
>> >
>> > Are you saying that that's what you meant by "fake result"? Are you
>> > saying there's something "fake" about not emitting an ADD
>> instruction in
>> > response to a C "+" operation? Is evaluating 2+2 at compile time
>> > "fake"?
>>
>> Transforming 2+2 is more acceptable since the result is always going
>> to be consistent. It is not controversial.
>
> If it is merely "more" acceptable, then it is still controversial. There
> will be people who don't understand how the C language works who feel it
> should be translated into assembly instructions to add 2 and 2.
C requires reduction of constant-expressions for compile-time
expressions, and within conditional expressions of the preprocessor.
So the mechanism for doing that is already there; it is not optional.
Actually it is also required for ?:
> Why would you think it would do that? There's nothing
> hardware-dependent in Keith's program.
>
> When I am investigating how a compiler treats particular code pieces, I
> usually don't bother running it at all on any hardware - it's a lot more
> efficient and insightful (to me) to use godbolt and look at the
> generated assembly. The hardware is irrelevant,
The generated assembly depends entirely on the hardware.
> If you had looked up instead, you'd have seen Keith's point flying over
> your head.
I suspect Keith had not even bothered looking at the output, whether
running on a real machine, or even at the generated code.
Some of us are more practically minded.
(I think that of those discussing this here, I'm the only one who has
had to generate real code for real machines for real applications, from
source code like this. )
>> It's a like taking a program that calculates and prints fib(36), and
>> then discovering that the winning compiler or interpreter is only
>> emitting puts("14930352") and not doing the actual work.
>>
>
> And that would be perfectly reasonable. We already know you have no
> idea how to benchmark tools.
And that comment suggests *you* have no idea! Recursive Fibonacci is a
famous benchmark that involves very large numbers of function calls.
That allows you to compare how languages and implmentations cope.
One that always takes 0 seconds because it has completely elided the
user's code would be useless.
> Different code could give different results. Different versions of gcc
> could give different results. Different flags could give different
> results.
On the same hardware.
> It's undefined behaviour - only a fool would expect some
> particular consistent choice of output. /That/ is the point. It would
> be nice if you tried harder to understand.
Apparently C23 has finally admitted that signed integers predominantly
use two's complement representation. But they have to keep overflow as
UB, *BECAUSE* of compilers like gcc which have invested so much into
exploiting it.
In my languages and compilers, signed integer overflow has never been
undefined. It's a choice.
There is still plenty of UB (to do with out-of-bounds accesses etc), but
I haven't catalogued it. Overflow however has never been UB because on
all my targets, it has been well-defined.
>> That is, comparing INT_MIN with INT_MAX. Because if you do this:
>>
>> int b = INT_MAX;
>> int a = b+1; // yields INT_MIN even with gcc
>
> It /might/ yield INT_MIN. It might not.
The probablity is near 100% that it will do so on x64 and likely most
other two's complement machines.
If you had to put money on what the output might be here:
int a=INT_MAX;
a=a+1;
printf("%d\n", a);
what would you go for? If the program was run again, would you make the
same choice, or would you genuinely think the result might be different?
I suspect I might win a lot of money from you!
Some of us are realists. However, even I would be hesitant of putting
that into a real program, but /because/ of the reputation of C compilers
regarding overflow.
BTW what is the purpose of gcc's -fwrapv option? Does it specify a
version of C where integer overflow is well-defined?
> It's garbage in, garbage out.
Unless -fwrapv suddenly makes it OK? How can one simple flag make sense
of 'garbage'?
> Despite having written several compilers of your own, I really don't
> think you understand how they work.
I know how mine works. It is not 'written' how compilers are supposed to
work. You're only familiar with gcc with its 1000s of options which can
make it work a million different ways.
So I can well make it a dumb line to line translator. It seems to work
well. There have been innumerable compilers before gcc and since that
work the same way, and they do the job.
> A compiler is not a dumb translator
> that works line by line. It analyses the code and forms internal graphs
> tracking information and decisions. It re-arranges things to minimise
> dependencies, re-use calculations, pre-calculate what it can, eliminate
> redundant code, merge loads, stores and calculations, etc.
You're describing an optimising compiler. If there is a place for a slow
language like Python, then there is also a place for a non-optimising
native code compiler, which is still a magnitude or two faster than Python.
When I was briefly using gcc 12.x, it took 500 times longer to optimise
my generated-C interpreter via -O3, as my language's compiler took to do
a non-optimised build.
However, the result wasn't 500 times faster, it was under 1.4 times as
fast (38%). But on that application, I normally use an accelerator, not
available using C, that makes it twice as fast as gcc-compiled code anyway.
So I think I'll stick with my compiler, thank you!
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-07-21 12:52 -0700 |
| Message-ID | <87r0p1nity.fsf@nosuchdomain.example.com> |
| In reply to | #171041 |
Bart <bc@freeuk.com> writes:
> On 21/07/2023 13:52, David Brown wrote:
>> On 21/07/2023 12:21, Bart wrote:
>>> On 21/07/2023 02:28, Keith Thompson wrote:
[...]
>> Why would you think it would do that? There's nothing
>> hardware-dependent in Keith's program.
>>
>> When I am investigating how a compiler treats particular code pieces, I
>> usually don't bother running it at all on any hardware - it's a lot more
>> efficient and insightful (to me) to use godbolt and look at the
>> generated assembly. The hardware is irrelevant,
>
> The generated assembly depends entirely on the hardware.
>
>> If you had looked up instead, you'd have seen Keith's point flying over
>> your head.
>
> I suspect Keith had not even bothered looking at the output, whether
> running on a real machine, or even at the generated code.
I certainly did look at the output before I posted it. I had to,
because I knew that the source code of my sample program does not
completely determine what the output will be.
No, I didn't look at the generated code, because it was irrelevant to my
point.
Again, C code specifies behavior, not CPU instructions.
[...]
>>> It's a like taking a program that calculates and prints fib(36), and
>>> then discovering that the winning compiler or interpreter is only
>>> emitting puts("14930352") and not doing the actual work.
>>
>> And that would be perfectly reasonable. We already know you have no
>> idea how to benchmark tools.
>
> And that comment suggests *you* have no idea! Recursive Fibonacci is a
> famous benchmark that involves very large numbers of function calls.
> That allows you to compare how languages and implmentations cope.
>
> One that always takes 0 seconds because it has completely elided the
> user's code would be useless.
Not if it gives the correct result.
It doesn't matter that something is a poor benchmark if it wasn't
intended to be a benchmark. If a program produces the correct output by
transforming `printf("%d\n", fib(36));` to `puts("14930352")`, what's
the problem?
>> Different code could give different results. Different versions of gcc
>> could give different results. Different flags could give different
>> results.
>
> On the same hardware.
Yes.
>> It's undefined behaviour - only a fool would expect some
>> particular consistent choice of output. /That/ is the point. It would
>> be nice if you tried harder to understand.
>
> Apparently C23 has finally admitted that signed integers predominantly
> use two's complement representation. But they have to keep overflow as
> UB, *BECAUSE* of compilers like gcc which have invested so much into
> exploiting it.
>
> In my languages and compilers, signed integer overflow has never been
> undefined. It's a choice.
In C, signed integer overflow is undefined. You reject that choice.
[...]
> BTW what is the purpose of gcc's -fwrapv option? Does it specify a
> version of C where integer overflow is well-defined?
Yes.
Note that "gcc -fwrapv" is still conforming. Since integer overflow is
undefined, having it wrap consistently is one of the allowed behaviors.
The "-fwrapv" option simply tells gcc to make once particular choice out
of the many that are allowed by the standard.
>> It's garbage in, garbage out.
>
> Unless -fwrapv suddenly makes it OK? How can one simple flag make
> sense of 'garbage'?
That's its job. Seriously, what are you pretending not to understand?
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-07-22 18:29 +0200 |
| Message-ID | <u9h055$3s62g$7@dont-email.me> |
| In reply to | #171041 |
On 21/07/2023 17:14, Bart wrote:>
> On 21/07/2023 13:52, David Brown wrote:
> > On 21/07/2023 12:21, Bart wrote:
> >> On 21/07/2023 02:28, Keith Thompson wrote:
> >> > Bart <bc@freeuk.com> writes:
> >> >> On 21/07/2023 00:58, Keith Thompson wrote:
> >> >>> No, it's not. It's exactly the output the program produced
when I
> >> >>> compiled and ran it.
> >> >>> Please explain what you mean by "fake result". Are you
> insinuating
> >> >>> that
> >> >>> I lied about it?
> >> >>
> >> >> No. gcc on my machine hard-codes that output without bothering to
> >> >> execute the comparison to see what the hardware does with it.
> >> >
> >> > Are you saying that that's what you meant by "fake result"?
Are you
> >> > saying there's something "fake" about not emitting an ADD
> >> instruction in
> >> > response to a C "+" operation? Is evaluating 2+2 at compile time
> >> > "fake"?
> >>
> >> Transforming 2+2 is more acceptable since the result is always going
> >> to be consistent. It is not controversial.
> >
> > If it is merely "more" acceptable, then it is still controversial.
There
> > will be people who don't understand how the C language works who
feel it
> > should be translated into assembly instructions to add 2 and 2.
>
> 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.
>
> Actually it is also required for ?:
>
Would you care to elaborate? There's nothing special about ?:
>
> > Why would you think it would do that? There's nothing
> > hardware-dependent in Keith's program.
> >
> > When I am investigating how a compiler treats particular code
pieces, I
> > usually don't bother running it at all on any hardware - it's a
lot more
> > efficient and insightful (to me) to use godbolt and look at the
> > generated assembly. The hardware is irrelevant,
>
> The generated assembly depends entirely on the hardware.
True. But optimisations like the ones under discussion do not, and I
find them easier to see with godbolt. It is also very easy to check
different compilers, letting you see the effect of different hardware. I
think we can all read some basic x86-64 assembly.
>
> > If you had looked up instead, you'd have seen Keith's point flying
over
> > your head.
>
> I suspect Keith had not even bothered looking at the output, whether
> running on a real machine, or even at the generated code.
>
It would not occur to me to accuse Keith of lying. Even if he were the
kind of character who might lie, why would he do so for something so
easily checked?
Personally, /I/ might not have bothered running such code - I might not
even have bothered using godbolt, because I know how gcc handles these
things. But I would not then have claimed that I /had/ run it.
> Some of us are more practically minded.
>
> (I think that of those discussing this here, I'm the only one who has
> had to generate real code for real machines for real applications, from
> source code like this. )
And I think that is irrelevant. We are discussing C, undefined
behaviour, and demonstrating with real-world handling of it in
real-world compilers. Little experiments with a single very limited
compiler are not important - not to the theory, obviously, but not in
practice either since practically no one uses your tools. (As always,
don't take that as mockery of your tools - it's just facts. Users of
gcc outnumber users of your compiler by about a million to one.)
>
>
> >> It's a like taking a program that calculates and prints fib(36), and
> >> then discovering that the winning compiler or interpreter is only
> >> emitting puts("14930352") and not doing the actual work.
> >>
> >
> > And that would be perfectly reasonable. We already know you have no
> > idea how to benchmark tools.
>
> And that comment suggests *you* have no idea! Recursive Fibonacci is a
> famous benchmark that involves very large numbers of function calls.
> That allows you to compare how languages and implmentations cope.
Yes, that's true. But /I/ know how to run a benchmark of Fibonacci
implementations. You don't, as you have demonstrated many times before,
and then followed by complaints about gcc not playing fair.
>
> One that always takes 0 seconds because it has completely elided the
> user's code would be useless.
And that's why you don't know how to benchmark tools.
>
> > Different code could give different results. Different versions
of gcc
> > could give different results. Different flags could give different
> > results.
>
> On the same hardware.
Yes, that's UB for you.
>
> > It's undefined behaviour - only a fool would expect some
> > particular consistent choice of output. /That/ is the point. It
would
> > be nice if you tried harder to understand.
>
> Apparently C23 has finally admitted that signed integers predominantly
> use two's complement representation. But they have to keep overflow as
> UB, *BECAUSE* of compilers like gcc which have invested so much into
> exploiting it.
No, they keep signed integer overflow as undefined behaviour because
there is no useful definition of what it would do, and keeping it as UB
gives programmers useful tools - it helps them find errors in their code
more easily, it makes it easier to reason about the code, and it gives
them more efficient results. That is why the solid majority of voters
in the C standards committee (and the C++ committee, who made a similar
change to fix on two's complement representation) did not want wrapping
overflow.
>
> 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 wrapping is a side-effect of efficient ALU hardware
implementation, nothing more. It's not something you want in a language.
>
> >> That is, comparing INT_MIN with INT_MAX. Because if you do this:
> >>
> >> int b = INT_MAX;
> >> int a = b+1; // yields INT_MIN even with gcc
> >
> > It /might/ yield INT_MIN. It might not.
> The probablity is near 100% that it will do so on x64 and likely most
> other two's complement machines.
No, it is not. The hardware does not define the language.
>
> If you had to put money on what the output might be here:
>
> int a=INT_MAX;
> a=a+1;
> printf("%d\n", a);
>
> what would you go for?
I wouldn't - plain and simple. It makes no sense to bet on something
that does not have a defined behaviour!
> If the program was run again, would you make the
> same choice, or would you genuinely think the result might be different?
> I suspect I might win a lot of money from you!
I do agree that it's very unlikely that you'd get different outputs on
different runs with a simple case like this. On a more complex case,
you might get different outputs with seemingly irrelevant changes to the
input, when there is UB involved. I have seen cases where apparently
unrelated changes to other parts of the source code have affected the
output in unpredictable ways due to UB.
>
> Some of us are realists. However, even I would be hesitant of putting
> that into a real program, but /because/ of the reputation of C compilers
> regarding overflow.
I am a realist too - that's why I don't put stupid and meaningless
constructs in my source code (at least, not knowingly!)
I really do not comprehend why anyone would want to write something that
makes no sense, and is specifically documented as having no guarantees
of the outcome. When I write code, I am aiming to get correct outcomes
and behaviour - that means I have to write correct source code. I don't
write twaddle and hope that some little elf in the compiler reads my
mind and straightens it out for me!
>
> BTW what is the purpose of gcc's -fwrapv option? Does it specify a
> version of C where integer overflow is well-defined?
>
Yes, that is /exactly/ what it does. And it is /documented/. (Comments
on the quality of gcc documentation are another matter entirely.) You
can rely on that behaviour if - and only if - you are using a compiler
like gcc with the flags like this, or another compiler that /documents/
that it makes signed integer overflow wrapping behaviour, then you can
safely use it on non-portable code compiled with such tools.
>
> > It's garbage in, garbage out.
>
> Unless -fwrapv suddenly makes it OK? How can one simple flag make sense
> of 'garbage'?
That's what the flag does.
"INT_MAX + 1" is garbage when you don't use that flag, and documented
well-behaved code when you do. Without the flag, the expression has no
meaning - with the flag, the compiler uses a mode in which it /does/
have a meaning.
>
> > Despite having written several compilers of your own, I really don't
> > think you understand how they work.
>
> I know how mine works. It is not 'written' how compilers are supposed to
> work. You're only familiar with gcc with its 1000s of options which can
> make it work a million different ways.
>
You are correct that there is no set of rules for how a compiler can
work. The reality is that compilers work in many different ways.
The only thing that is "written" is the C syntax and constraint
requirements, and the observable behaviour of the C abstract machine for
constructs that meant these requirements. Compilers can use any methods
they like for constructing any code they like, as long as the generated
code matches the required observable behaviour when the compiler is
given source code that meets the requirements of the C language.
Note that when given source code that does not meet the requirements -
such as "INT_MAX + 1" - they can do anything they like. (Producing a
helpful error message is nice, but not required.) When the inputs are
such that the abstract machine has no defined behaviour (such as signed
integer overflow at runtime), neither does the generated code have any
requirements. Between points of observable behaviour, there are no
requirements.
Compilers have a great deal of freedom. Good compilers take advantage
of that to give more efficient code (and/or more helpful debugging and
diagnostics).
> So I can well make it a dumb line to line translator. It seems to work
> well. There have been innumerable compilers before gcc and since that
> work the same way, and they do the job.
You can most certainly make a line-by-line translator. Just don't
imagine that other compilers work that way.
>
>
> > A compiler is not a dumb translator
> > that works line by line. It analyses the code and forms internal
graphs
> > tracking information and decisions. It re-arranges things to minimise
> > dependencies, re-use calculations, pre-calculate what it can,
eliminate
> > redundant code, merge loads, stores and calculations, etc.
>
> You're describing an optimising compiler.
And you are imagining that there is such a thing as a "not optimising
compiler", and that there are somehow different rules involved. The
rules are the same for the language (unless a compiler specifically
documents something else). There is certainly no binary
optimising/non-optimising choice.
> If there is a place for a slow
> language like Python, then there is also a place for a non-optimising
> native code compiler, which is still a magnitude or two faster than
Python.
Why? A non-optimising compiler doesn't do anything better than an
optimising one in the usual significant properties of a compiler - the
code it produces, the diagnostics and help it gives the programmer. It
does not implement a different language, or let the programmer use
constructs that are undefined in the language. If compile-time speed or
compiler size is critical to your needs, then a simpler compiler is
likely to be better - but that's all.
You may feel there is place for a compiler that implements two's
complement signed integer overflow, or allows access to data through any
kind of pointer, or other /specific/ features. That's fine. It is
entirely a matter of opinion if C with those additional semantics is a
better language - and you would not be alone in thinking that. If you
want those features, use compilers that have these features (such as
"gcc -fwrapv -fno-strict-aliasing") and accept that your code is
non-portable. Give your own compilers those features (but document it,
if you want anyone else to use them).
But don't pretend that these are features of "non-optimising compilers".
>
> When I was briefly using gcc 12.x, it took 500 times longer to optimise
> my generated-C interpreter via -O3, as my language's compiler took to do
> a non-optimised build.
Well, as you know full well - but prefer to ignore when making pointless
artificial comparisons between gcc and your own tools - the -O3 setting
on gcc asks the compiler to work as hard as possible trying to squeeze
out the last drops of efficiency from the code. It's not a setting that
many people use in practice - the results are sometimes faster, but not
always, and it can take so much longer to run that it's rarely worth the
effort. (When you want the absolute best code generation, there are
more useful features - profile-guided optimisation, tuning for the exact
processor being targeted, etc.)
>
> However, the result wasn't 500 times faster, it was under 1.4 times as
> fast (38%). But on that application, I normally use an accelerator, not
> available using C, that makes it twice as fast as gcc-compiled code
anyway.
>
> So I think I'll stick with my compiler, thank you!
>
As you wish - no need to thank me :-)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-07-22 21:56 +0100 |
| Message-ID | <87351foebi.fsf@bsb.me.uk> |
| In reply to | #171101 |
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. <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? Making some arithmetic operations undefined results is a structure with no simple mathematical description. > 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. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-07-22 16:11 -0700 |
| Message-ID | <87lef7mths.fsf@nosuchdomain.example.com> |
| In reply to | #171114 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> David Brown <david.brown@hesbynett.no> writes:
[...]
>> 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.
Except that an overflow in a constant expression is a constraint
violation, and must be diagnosed at compile time.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-07-23 00:45 +0100 |
| Message-ID | <87r0ozmrwz.fsf@bsb.me.uk> |
| In reply to | #171127 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> David Brown <david.brown@hesbynett.no> writes: > [...] >>> 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. > > Except that an overflow in a constant expression is a constraint > violation, and must be diagnosed at compile time. I'd forgotten that. But since I'm talking about non-sane implementations that does mean that an expression must be evaluated. For example, any expression involving only unsigned values will result in a value that is in rage for the its. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-07-23 17:24 +0200 |
| Message-ID | <u9jgmu$9i98$1@dont-email.me> |
| In reply to | #171114 |
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. 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. 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. 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). 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. > 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. 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. So you lose nothing, and gain something, by having the behaviour undefined. 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. 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. > >> 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. But I do not believe any language has defined signed integer overflow to be modulo wrapping because it is a good idea mathematically, or useful for applications - languages do so only if they want to give /some/ definition to it, regardless of its usefulness. And since two's complement wrapping is a side-effect of almost all hardware implementations for the last 50 years or more, that's what is picked - anything else would be hugely expensive, and surprising to programmers. Remember what the C standards actually say here, in 6.5p5 : """ If an exceptional condition occurs during the evaluation of an expression (that is, if the result is not mathematically defined or not in the range of representable values for its type), the behavior is undefined. """ Overflow is an "exceptional condition" with results "not mathematically defined" or where the result is not representable by the type. That sounds to me very much like saying if the result doesn't make sense in the program, the C language doesn't try to impose a sense on it.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-07-23 17:28 +0100 |
| Message-ID | <u9jkfc$9ub8$1@dont-email.me> |
| In reply to | #171165 |
On 23/07/2023 16:24, David Brown wrote:
> On 22/07/2023 22:56, Ben Bacarisse wrote:
> 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). When you
> overflow integer arithmetic, you get the wrong answer for pretty much
> every situation.
That's not true.
INT_MAX + 1 - 1 will give the correct answer. If you instead write it
like this:
typedef unsigned int u32;
(int)((u32)INT_MAX + (u32)1 - (u32)1);
then even C agrees that is well-behaved, despite probably performing
exactly the same machine operations (where the compiler deigns to
actually let it, that is, in actual code where variables are used and
the steps are in different expressions)).
So, it's possible to view most signed operations as though there were
implicits casts to convert to unsigned and back again, for the purposes
of making them well-defined in C. But then, why the need for an /any/ cast?
(Some operations will give different results between signed and
unsigned, like shifts.)
> 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.
Are you talking about signed arithmetic here? Because your comments can
equally to unsigned arithmetic.
>
>> 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.
> 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.
>
> So you lose nothing, and gain something, by having the behaviour
undefined.
I thought I'd try a test, and compiled one of my generated-C programs
with both -O3 and -O3 -fwrapv, to see if there was actually any gain in
performance due to taking advantage of UB.
(The program was an interpreter running a JPEG-decoder script.)
Sure enough, I saw a 4% gain in performance, so that I'd have to admit
that that would be handy...
... until I looked at the test results more carefully: the faster
results were when compiled with -fwrapv, so integer overflow was not UB!
Having well-defined wrapping behaviour was faster in this case (I only
did one test). However the executable was slightly bigger by 0.25%.
So, what I'd wanted to ask was, is the UB really worth it overall? What
improvements you get purely with -fwrapv in general? As I showed I got a
slight slowdown.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-07-23 16:45 +0000 |
| Message-ID | <20230723093714.83@kylheku.com> |
| In reply to | #171167 |
On 2023-07-23, Bart <bc@freeuk.com> wrote: > On 23/07/2023 16:24, David Brown wrote: > > On 22/07/2023 22:56, Ben Bacarisse wrote: > > 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). When you > > overflow integer arithmetic, you get the wrong answer for pretty much > > every situation. > > That's not true. > > INT_MAX + 1 - 1 will give the correct answer. If you instead write it > like this: This is something the compiler can advantage of, regardless of whether the behavior is defined to the programmer. When we write a + 3 - c, then, if the compiler knows that the underlying target language has wrapping behavior with no ill consequences, it can rearrange the calculation to a - c + 3. (For whatever reason, such has having previously calculated a - c in another expression, and the consolidation of non-constant terms allows the result to be reused.) If overflow has negative/undefined consequences in the target language, then the rearrangement cannot be made; the programmer may have written the calculation in that order way on purpose, and verified that it doesn't overflow or underflow. (Speaking of "underlying target language", defined wrapping arithmetic can help writers of languages that translate to C, in the same way.) -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-07-24 10:04 +0200 |
| Message-ID | <u9lbak$jbjl$1@dont-email.me> |
| In reply to | #171169 |
On 23/07/2023 18:45, Kaz Kylheku wrote: > On 2023-07-23, Bart <bc@freeuk.com> wrote: >> On 23/07/2023 16:24, David Brown wrote: >>> On 22/07/2023 22:56, Ben Bacarisse wrote: >>> 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). When you >>> overflow integer arithmetic, you get the wrong answer for pretty much >>> every situation. >> >> That's not true. >> >> INT_MAX + 1 - 1 will give the correct answer. If you instead write it >> like this: > > This is something the compiler can advantage of, regardless of > whether the behavior is defined to the programmer. > > When we write a + 3 - c, then, if the compiler knows that the > underlying target language has wrapping behavior with no ill > consequences, it can rearrange the calculation to a - c + 3. (For > whatever reason, such has having previously calculated a - c in another > expression, and the consolidation of non-constant terms allows the > result to be reused.) > > If overflow has negative/undefined consequences in the target language, > then the rearrangement cannot be made; the programmer may have written > the calculation in that order way on purpose, and verified that it > doesn't overflow or underflow. > > (Speaking of "underlying target language", defined wrapping arithmetic > can help writers of languages that translate to C, in the same way.) > If the compiler knows the target platform does not have something like overflow exceptions, then it can rearrange "a + 3 - c" to "a - c + 3" regardless of whether or not overflow is wrapping. Conversely, if the platform does (or might) have overflow exceptions, then it cannot make this re-arrangement regardless of whether overflow is wrapping or not. Remember, treating integer overflow as wrapping is a plausible extension to the semantics of the C language - it is not something that particular hardware forces back up the chain to the compiler. Compilers can take advantage of their knowledge of the overflow behaviour of particular hardware instructions to optimise code - regardless of any additional semantics they may or may not guarantee to the programmer. Many processors have a range of different "add" instructions - the compiler can pick one based on generated flags that might be useful, or other characteristics.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-07-24 07:43 +0200 |
| Message-ID | <u9l320$iepd$1@dont-email.me> |
| In reply to | #171167 |
On 23/07/2023 18:28, Bart wrote: > On 23/07/2023 16:24, David Brown wrote: > > On 22/07/2023 22:56, Ben Bacarisse wrote: > > 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). When you > > overflow integer arithmetic, you get the wrong answer for pretty much > > every situation. > > That's not true. > > INT_MAX + 1 - 1 will give the correct answer. That's asking a completely different question - why would it be surprising that you get a completely different answer? > If you instead write it > like this: > > typedef unsigned int u32; > (int)((u32)INT_MAX + (u32)1 - (u32)1); > Unsigned arithmetic in C is defined as modulo arithmetic - again, a totally different situation. > then even C agrees that is well-behaved, despite probably performing > exactly the same machine operations (where the compiler deigns to > actually let it, that is, in actual code where variables are used and > the steps are in different expressions)). > C is not, and never has been, defined in terms of any instructions it might generate or the behaviour of any particular processor. > So, it's possible to view most signed operations as though there were > implicits casts to convert to unsigned and back again, for the purposes > of making them well-defined in C. But then, why the need for an /any/ cast? > (A "cast" is an /explicit/ conversion. You mean "implicit conversions".) Processors often provide different instructions that are similar in some ways, and different in others. The same goes for languages. Some languages only have one integer type, others have many. A compiler (or compiler flags) aiming to help developers catch errors will likely use different instructions for signed and unsigned arithmetic - precisely because it aims to stop with an error message on signed integer overflow. > (Some operations will give different results between signed and > unsigned, like shifts.) > > > > 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. > > Are you talking about signed arithmetic here? Because your comments can > equally to unsigned arithmetic. > I have always said that I think unsigned integer overflow is usually a mistake too (except perhaps for the common use of "-1u"). But C defines unsigned integer arithmetic to be modulo - whether I like it or not. (I do like the language has /some/ way to get modulo arithmetic efficiently, because it is /occasionally/ useful.) But since we are talking about C and the way C is defined, I was referring to signed arithmetic. > > > > >> 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. > > > 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. > > > > So you lose nothing, and gain something, by having the behaviour > undefined. > > I thought I'd try a test, and compiled one of my generated-C programs > with both -O3 and -O3 -fwrapv, to see if there was actually any gain in > performance due to taking advantage of UB. > And you think you'd show something here? > (The program was an interpreter running a JPEG-decoder script.) > > Sure enough, I saw a 4% gain in performance, so that I'd have to admit > that that would be handy... > > ... until I looked at the test results more carefully: the faster > results were when compiled with -fwrapv, so integer overflow was not UB! > > Having well-defined wrapping behaviour was faster in this case (I only > did one test). However the executable was slightly bigger by 0.25%. > > So, what I'd wanted to ask was, is the UB really worth it overall? What > improvements you get purely with -fwrapv in general? As I showed I got a > slight slowdown. > I think almost any case where "-fwrapv" produces faster code than "-fno-wrapv" is either undefined behaviour in the source code, or a bug (at least a "missed optimisation" issue) in the compiler. After all, the compiler can freely use wrapping behaviour if it wants, and should do so if it generates better code. It is possible that /if/ you are writing code for which you actually /want/ two's complement wrapping in your signed integer arithmetic (it is very rare that this has any benefit, especially on modern processors where using 64-bit integer types is faster, but it occasionally happens) then you could find that using -fwrapv gives faster results than some kinds of re-writing of your code. But since you can always convert back and forth to unsigned types to get the same effect, I think it is unlikely.
[toc] | [prev] | [next] | [standalone]
Page 10 of 49 — ← Prev page 1 … 8 9 [10] 11 12 … 49 Next page →
Back to top | Article view | comp.lang.c
csiph-web