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 23 of 49 — ← Prev page 1 … 21 22 [23] 24 25 … 49 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-04 15:25 +0100 |
| Message-ID | <uaj1o2$1a70n$1@dont-email.me> |
| In reply to | #171607 |
On 04/08/2023 14:56, Scott Lurndal wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 04/08/2023 00:44, Keith Thompson wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>>> On 03/08/2023 03:07, Bart wrote: >>> [...] >>>>> BTW in your link, a few languages have aliases for the same >>>>> type. That includes 'int = int32_t' for Objective C. >>>> >>>> I don't know if that is accurate or not - I am not familiar with >>>> Objective C. (In C, it certainly is not accurate.) >>> >>> The link is >>> https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(basic_instructions)#Integers >>> >>> The row for Objective C is actually labeled "Objective-C (Cocoa)", which >>> may refer to a particular implementation of Objective-C. The >>> information is likely correct for that implementation. >>> >>> There apparently is no standard document for Objective-C, but it's >>> intended to be a strict superset of C (which C++ is not). That would >>> imply that it must define int and int32_t the same way C does. There >>> may or may not be any Objective-C implementations where int32_t is not >>> defined as int, but there certainly could be. (But with Swift intended >>> to replace Objective-C, I wouldn't expect any new Objective-C >>> implementations.) >>> >>> [...] >>> >> >> Sounds reasonable. >> >> I do know that on 32-bit ARM, "int32_t" is a typedef for "long int", not >> "int". (I don't know why, and I am curious if anyone else does - 32-bit >> ARM is far and away the most popular architecture for embedded devices, >> in terms of the number of developers and projects, so it is an important >> target system.) > > It depends on how the platform ABI defines long. > > arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/arm-none-eabi/include/machine/_default_types.h: > > #ifdef __INT32_TYPE__ > typedef __INT32_TYPE__ __int32_t; > #ifdef __UINT32_TYPE__ > typedef __UINT32_TYPE__ __uint32_t; > #else > typedef unsigned __INT32_TYPE__ __uint32_t; > #endif > #define ___int32_t_defined 1 > #elif __EXP(INT_MAX) == 0x7fffffffL > typedef signed int __int32_t; > typedef unsigned int __uint32_t; > #define ___int32_t_defined 1 > #elif __EXP(LONG_MAX) == 0x7fffffffL > typedef signed long __int32_t; > typedef unsigned long __uint32_t; > #define ___int32_t_defined 1 > #elif __EXP(SHRT_MAX) == 0x7fffffffL > typedef signed short __int32_t; > typedef unsigned short __uint32_t; > #define ___int32_t_defined 1 > #elif __EXP(SCHAR_MAX) == 0x7fffffffL > typedef signed char __int32_t; > typedef unsigned char __uint32_t; > #define ___int32_t_defined 1 > #endif This is part of an implementation for, what, a compiler? You'd think a compiler would know the sizes of its types! Otherwise why is this code defining __int32_t? This is not even int32_t, what will that __int32_t be used for, surely not int32_t at some later point, and within what program? It seems that this piece of code wants to define "__int32_t", but doesn't know which standard type the underlying C compiler uses that happens to be 32 bits. (It also looks like it will fail if there is no such type.) What's that __INT32_TYPE__ all about? Decades on since C99 and still there are myriad aliases for such types lurking everywhere. I've never seen so palaver defining a simple type.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-08-04 17:05 -0400 |
| Message-ID | <mKdzM.481384$AsA.322316@fx18.iad> |
| In reply to | #171612 |
On 8/4/23 10:25 AM, Bart wrote: > On 04/08/2023 14:56, Scott Lurndal wrote: > > David Brown <david.brown@hesbynett.no> writes: > >> On 04/08/2023 00:44, Keith Thompson wrote: > >>> David Brown <david.brown@hesbynett.no> writes: > >>>> On 03/08/2023 03:07, Bart wrote: > >>> [...] > >>>>> BTW in your link, a few languages have aliases for the same > >>>>> type. That includes 'int = int32_t' for Objective C. > >>>> > >>>> I don't know if that is accurate or not - I am not familiar with > >>>> Objective C. (In C, it certainly is not accurate.) > >>> > >>> The link is > >>> > https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(basic_instructions)#Integers > >>> > >>> The row for Objective C is actually labeled "Objective-C (Cocoa)", > which > >>> may refer to a particular implementation of Objective-C. The > >>> information is likely correct for that implementation. > >>> > >>> There apparently is no standard document for Objective-C, but it's > >>> intended to be a strict superset of C (which C++ is not). That would > >>> imply that it must define int and int32_t the same way C does. There > >>> may or may not be any Objective-C implementations where int32_t is not > >>> defined as int, but there certainly could be. (But with Swift > intended > >>> to replace Objective-C, I wouldn't expect any new Objective-C > >>> implementations.) > >>> > >>> [...] > >>> > >> > >> Sounds reasonable. > >> > >> I do know that on 32-bit ARM, "int32_t" is a typedef for "long int", > not > >> "int". (I don't know why, and I am curious if anyone else does - > 32-bit > >> ARM is far and away the most popular architecture for embedded devices, > >> in terms of the number of developers and projects, so it is an > important > >> target system.) > > > > It depends on how the platform ABI defines long. > > > > > arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/arm-none-eabi/include/machine/_default_types.h: > > > > #ifdef __INT32_TYPE__ > > typedef __INT32_TYPE__ __int32_t; > > #ifdef __UINT32_TYPE__ > > typedef __UINT32_TYPE__ __uint32_t; > > #else > > typedef unsigned __INT32_TYPE__ __uint32_t; > > #endif > > #define ___int32_t_defined 1 > > #elif __EXP(INT_MAX) == 0x7fffffffL > > typedef signed int __int32_t; > > typedef unsigned int __uint32_t; > > #define ___int32_t_defined 1 > > #elif __EXP(LONG_MAX) == 0x7fffffffL > > typedef signed long __int32_t; > > typedef unsigned long __uint32_t; > > #define ___int32_t_defined 1 > > #elif __EXP(SHRT_MAX) == 0x7fffffffL > > typedef signed short __int32_t; > > typedef unsigned short __uint32_t; > > #define ___int32_t_defined 1 > > #elif __EXP(SCHAR_MAX) == 0x7fffffffL > > typedef signed char __int32_t; > > typedef unsigned char __uint32_t; > > #define ___int32_t_defined 1 > > #endif > > This is part of an implementation for, what, a compiler? You'd think a > compiler would know the sizes of its types! > > Otherwise why is this code defining __int32_t? This is not even int32_t, > what will that __int32_t be used for, surely not int32_t at some later > point, and within what program? > > It seems that this piece of code wants to define "__int32_t", but > doesn't know which standard type the underlying C compiler uses that > happens to be 32 bits. (It also looks like it will fail if there is no > such type.) > > What's that __INT32_TYPE__ all about? Decades on since C99 and still > there are myriad aliases for such types lurking everywhere. > > I've never seen so palaver defining a simple type. > > Remmber, the compiler is only allowed to use int32_t if <stdint.h> has been included. If it hasn't, then then name is still in user name space. __int32_t is always in the implementation namespace, so can be freely defined for library code that might be written to work for multiple targers (as most code is). Such a file is a natural for a part of the library that might not want to fix what processor it is being written for. Maybe your problem is you dont understand that there are more than one type of processors, and code (even implementation code) may want to be written to work on many different processors (or modes on a given processor)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-04 22:32 +0100 |
| Message-ID | <uajqpr$1e0or$1@dont-email.me> |
| In reply to | #171643 |
On 04/08/2023 22:05, Richard Damon wrote: > On 8/4/23 10:25 AM, Bart wrote: >> On 04/08/2023 14:56, Scott Lurndal wrote: >> > David Brown <david.brown@hesbynett.no> writes: >> >> On 04/08/2023 00:44, Keith Thompson wrote: >> >>> David Brown <david.brown@hesbynett.no> writes: >> >>>> On 03/08/2023 03:07, Bart wrote: >> >>> [...] >> >>>>> BTW in your link, a few languages have aliases for the same >> >>>>> type. That includes 'int = int32_t' for Objective C. >> >>>> >> >>>> I don't know if that is accurate or not - I am not familiar with >> >>>> Objective C. (In C, it certainly is not accurate.) >> >>> >> >>> The link is >> >>> >> https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(basic_instructions)#Integers >> >>> >> >>> The row for Objective C is actually labeled "Objective-C >> (Cocoa)", which >> >>> may refer to a particular implementation of Objective-C. The >> >>> information is likely correct for that implementation. >> >>> >> >>> There apparently is no standard document for Objective-C, but it's >> >>> intended to be a strict superset of C (which C++ is not). That >> would >> >>> imply that it must define int and int32_t the same way C does. >> There >> >>> may or may not be any Objective-C implementations where int32_t >> is not >> >>> defined as int, but there certainly could be. (But with Swift >> intended >> >>> to replace Objective-C, I wouldn't expect any new Objective-C >> >>> implementations.) >> >>> >> >>> [...] >> >>> >> >> >> >> Sounds reasonable. >> >> >> >> I do know that on 32-bit ARM, "int32_t" is a typedef for "long >> int", not >> >> "int". (I don't know why, and I am curious if anyone else does - >> 32-bit >> >> ARM is far and away the most popular architecture for embedded >> devices, >> >> in terms of the number of developers and projects, so it is an >> important >> >> target system.) >> > >> > It depends on how the platform ABI defines long. >> > >> > >> arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/arm-none-eabi/include/machine/_default_types.h: >> > >> > #ifdef __INT32_TYPE__ >> > typedef __INT32_TYPE__ __int32_t; >> > #ifdef __UINT32_TYPE__ >> > typedef __UINT32_TYPE__ __uint32_t; >> > #else >> > typedef unsigned __INT32_TYPE__ __uint32_t; >> > #endif >> > #define ___int32_t_defined 1 >> > #elif __EXP(INT_MAX) == 0x7fffffffL >> > typedef signed int __int32_t; >> > typedef unsigned int __uint32_t; >> > #define ___int32_t_defined 1 >> > #elif __EXP(LONG_MAX) == 0x7fffffffL >> > typedef signed long __int32_t; >> > typedef unsigned long __uint32_t; >> > #define ___int32_t_defined 1 >> > #elif __EXP(SHRT_MAX) == 0x7fffffffL >> > typedef signed short __int32_t; >> > typedef unsigned short __uint32_t; >> > #define ___int32_t_defined 1 >> > #elif __EXP(SCHAR_MAX) == 0x7fffffffL >> > typedef signed char __int32_t; >> > typedef unsigned char __uint32_t; >> > #define ___int32_t_defined 1 >> > #endif >> >> This is part of an implementation for, what, a compiler? You'd think a >> compiler would know the sizes of its types! >> >> Otherwise why is this code defining __int32_t? This is not even >> int32_t, what will that __int32_t be used for, surely not int32_t at >> some later point, and within what program? >> >> It seems that this piece of code wants to define "__int32_t", but >> doesn't know which standard type the underlying C compiler uses that >> happens to be 32 bits. (It also looks like it will fail if there is no >> such type.) >> >> What's that __INT32_TYPE__ all about? Decades on since C99 and still >> there are myriad aliases for such types lurking everywhere. >> >> I've never seen so palaver defining a simple type. >> >> > > Remmber, the compiler is only allowed to use int32_t if <stdint.h> has > been included. If it hasn't, then then name is still in user name space. > > __int32_t is always in the implementation namespace, so can be freely > defined for library code that might be written to work for multiple > targers (as most code is). > > Such a file is a natural for a part of the library that might not want > to fix what processor it is being written for. > > Maybe your problem is you dont understand that there are more than one > type of processors, and code (even implementation code) may want to be > written to work on many different processors (or modes on a given > processor) Presumably `__int32_t` is being defined on top of whatever 32-bit type the C compiler has. So why doesn't it just define it on top of `int32_t`? Or better, forget `__int32_t` and just use `int32_t`? Don't tell me, there is some really, really complicated reason why it has to be done like this (maybe these are some of those programmers paid by the line!). That example is just ridiculous. And I've seen plenty just like it. It seems C is still a breeding ground for pointless typedefs a quarter of a century after C99 was supposed to put paid to it.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-08-04 17:46 -0400 |
| Message-ID | <9lezM.490986$AsA.486209@fx18.iad> |
| In reply to | #171644 |
On 8/4/23 5:32 PM, Bart wrote: > > On 04/08/2023 22:05, Richard Damon wrote: > > On 8/4/23 10:25 AM, Bart wrote: > >> On 04/08/2023 14:56, Scott Lurndal wrote: > >> > David Brown <david.brown@hesbynett.no> writes: > >> >> On 04/08/2023 00:44, Keith Thompson wrote: > >> >>> David Brown <david.brown@hesbynett.no> writes: > >> >>>> On 03/08/2023 03:07, Bart wrote: > >> >>> [...] > >> >>>>> BTW in your link, a few languages have aliases for the same > >> >>>>> type. That includes 'int = int32_t' for Objective C. > >> >>>> > >> >>>> I don't know if that is accurate or not - I am not familiar with > >> >>>> Objective C. (In C, it certainly is not accurate.) > >> >>> > >> >>> The link is > >> >>> > >> > https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(basic_instructions)#Integers > >> >>> > >> >>> The row for Objective C is actually labeled "Objective-C > >> (Cocoa)", which > >> >>> may refer to a particular implementation of Objective-C. The > >> >>> information is likely correct for that implementation. > >> >>> > >> >>> There apparently is no standard document for Objective-C, but it's > >> >>> intended to be a strict superset of C (which C++ is not). That > >> would > >> >>> imply that it must define int and int32_t the same way C does. > >> There > >> >>> may or may not be any Objective-C implementations where int32_t > >> is not > >> >>> defined as int, but there certainly could be. (But with Swift > >> intended > >> >>> to replace Objective-C, I wouldn't expect any new Objective-C > >> >>> implementations.) > >> >>> > >> >>> [...] > >> >>> > >> >> > >> >> Sounds reasonable. > >> >> > >> >> I do know that on 32-bit ARM, "int32_t" is a typedef for "long > >> int", not > >> >> "int". (I don't know why, and I am curious if anyone else does - > >> 32-bit > >> >> ARM is far and away the most popular architecture for embedded > >> devices, > >> >> in terms of the number of developers and projects, so it is an > >> important > >> >> target system.) > >> > > >> > It depends on how the platform ABI defines long. > >> > > >> > > >> > arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/arm-none-eabi/include/machine/_default_types.h: > >> > > >> > #ifdef __INT32_TYPE__ > >> > typedef __INT32_TYPE__ __int32_t; > >> > #ifdef __UINT32_TYPE__ > >> > typedef __UINT32_TYPE__ __uint32_t; > >> > #else > >> > typedef unsigned __INT32_TYPE__ __uint32_t; > >> > #endif > >> > #define ___int32_t_defined 1 > >> > #elif __EXP(INT_MAX) == 0x7fffffffL > >> > typedef signed int __int32_t; > >> > typedef unsigned int __uint32_t; > >> > #define ___int32_t_defined 1 > >> > #elif __EXP(LONG_MAX) == 0x7fffffffL > >> > typedef signed long __int32_t; > >> > typedef unsigned long __uint32_t; > >> > #define ___int32_t_defined 1 > >> > #elif __EXP(SHRT_MAX) == 0x7fffffffL > >> > typedef signed short __int32_t; > >> > typedef unsigned short __uint32_t; > >> > #define ___int32_t_defined 1 > >> > #elif __EXP(SCHAR_MAX) == 0x7fffffffL > >> > typedef signed char __int32_t; > >> > typedef unsigned char __uint32_t; > >> > #define ___int32_t_defined 1 > >> > #endif > >> > >> This is part of an implementation for, what, a compiler? You'd think a > >> compiler would know the sizes of its types! > >> > >> Otherwise why is this code defining __int32_t? This is not even > >> int32_t, what will that __int32_t be used for, surely not int32_t at > >> some later point, and within what program? > >> > >> It seems that this piece of code wants to define "__int32_t", but > >> doesn't know which standard type the underlying C compiler uses that > >> happens to be 32 bits. (It also looks like it will fail if there is no > >> such type.) > >> > >> What's that __INT32_TYPE__ all about? Decades on since C99 and still > >> there are myriad aliases for such types lurking everywhere. > >> > >> I've never seen so palaver defining a simple type. > >> > >> > > > > Remmber, the compiler is only allowed to use int32_t if <stdint.h> has > > been included. If it hasn't, then then name is still in user name space. > > > > __int32_t is always in the implementation namespace, so can be freely > > defined for library code that might be written to work for multiple > > targers (as most code is). > > > > Such a file is a natural for a part of the library that might not want > > to fix what processor it is being written for. > > > > Maybe your problem is you dont understand that there are more than one > > type of processors, and code (even implementation code) may want to be > > written to work on many different processors (or modes on a given > > processor) > > Presumably `__int32_t` is being defined on top of whatever 32-bit type > the C compiler has. > > So why doesn't it just define it on top of `int32_t`? Or better, forget > `__int32_t` and just use `int32_t`? > > Don't tell me, there is some really, really complicated reason why it > has to be done like this (maybe these are some of those programmers paid > by the line!). > > That example is just ridiculous. And I've seen plenty just like it. It > seems C is still a breeding ground for pointless typedefs a quarter of a > century after C99 was supposed to put paid to it. > Because int32_t isn't a fundamental tyoe in C. It is only a name that comes into existance if your included <stdint.h> The only standardly defined integral types are char, short, int, long, long long, and the unsigned version of those (plus signed character). The implementaiton may define names for additional built in types, but they MUST be defined using names that are unconditionally reserved for the implementation, which doesn't include int32_t, which is only reserved if <stdint.h> is included. Yes, the way the C language is specified, implementation really do need to use a lot of typedef "magic" behind the scenes using implementation reserved names, but you aren't expected to be normally looking into that, but working with the public published API. Thus, ANY header, except one DEFINED to effectively include <stdint.h> (like <inttypes.h>) can't use the names like int32_t, because they don't belong to the implementation there, but must use "private" version of them.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-04 21:47 +0000 |
| Message-ID | <20230804144511.511@kylheku.com> |
| In reply to | #171644 |
On 2023-08-04, Bart <bc@freeuk.com> wrote: > Presumably `__int32_t` is being defined on top of whatever 32-bit type > the C compiler has. > > So why doesn't it just define it on top of `int32_t`? Or better, forget > `__int32_t` and just use `int32_t`? > > Don't tell me, there is some really, really complicated reason why it > has to be done like this (maybe these are some of those programmers paid > by the line!). Mostly, the reasons can be summarized by that it's not some solo developer's recently started greenfield project, but something with a long history on various kinds of machines, and numerous implementations. C first had 18 bit int; most machines don't have that now. Good thing we are not stuck with int18, right? -- 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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-05 00:43 +0100 |
| Message-ID | <uak2eu$1f25c$1@dont-email.me> |
| In reply to | #171648 |
On 04/08/2023 22:47, Kaz Kylheku wrote:
> On 2023-08-04, Bart <bc@freeuk.com> wrote:
>> Presumably `__int32_t` is being defined on top of whatever 32-bit type
>> the C compiler has.
>>
>> So why doesn't it just define it on top of `int32_t`? Or better, forget
>> `__int32_t` and just use `int32_t`?
>>
>> Don't tell me, there is some really, really complicated reason why it
>> has to be done like this (maybe these are some of those programmers paid
>> by the line!).
>
> Mostly, the reasons can be summarized by that it's not some solo
> developer's recently started greenfield project, but something with a
> long history on various kinds of machines, and numerous implementations.
> C first had 18 bit int; most machines don't have that now.
>
> Good thing we are not stuck with int18, right?
>
And the exact reason why that code can't just do:
#include <stdint.h>
typedef int32_t __int32_t;
is? I can't imagine that it still needs to run on the PDP7, and with the
code shown, it wouldn't work anyway.
There have dozens of posts extolling the benefits of using stdint.h, and
not rolling your own types, and now we have a piece of code that
completely ignores that advice.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-05 00:15 +0000 |
| Message-ID | <20230804170652.627@kylheku.com> |
| In reply to | #171650 |
On 2023-08-04, Bart <bc@freeuk.com> wrote: > On 04/08/2023 22:47, Kaz Kylheku wrote: > > On 2023-08-04, Bart <bc@freeuk.com> wrote: > >> Presumably `__int32_t` is being defined on top of whatever 32-bit type > >> the C compiler has. > >> > >> So why doesn't it just define it on top of `int32_t`? Or better, forget > >> `__int32_t` and just use `int32_t`? > >> > >> Don't tell me, there is some really, really complicated reason why it > >> has to be done like this (maybe these are some of those programmers paid > >> by the line!). > > > > Mostly, the reasons can be summarized by that it's not some solo > > developer's recently started greenfield project, but something with a > > long history on various kinds of machines, and numerous implementations. > > C first had 18 bit int; most machines don't have that now. > > > > Good thing we are not stuck with int18, right? > > > > And the exact reason why that code can't just do: > > #include <stdint.h> > > typedef int32_t __int32_t; It appears that this thread is about something found in a library header _default_types.h. I don't have a _default_types.h anywhere except a bunch of Cygwin trees. It looks like a Newlib thing (a library from the BSD world on which Cygwin is based). The reason the header cannot just do #include <stdint.h> is that it is the basis for that header! $ grep default_types /mnt/c/Cygwin/cygwin64/usr/include/stdint.h #include <machine/_default_types.h> $ ls /mnt/c/Cygwin/cygwin64/usr/include/machine/_default_types.h /mnt/c/Cygwin/cygwin64/usr/include/machine/_default_types.h The library is designed such that it provides its own <stdint.h> header, not relying on the compiler providing one. It defines some underscored types in machine/_default_types.h and then it uses those to declare the public, standard ones in <stdint.h>. I would do it similarly, if I had to. Any more trick questions? -- 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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-05 01:33 +0100 |
| Message-ID | <uak5d5$1fclo$1@dont-email.me> |
| In reply to | #171651 |
On 05/08/2023 01:15, Kaz Kylheku wrote:
> On 2023-08-04, Bart <bc@freeuk.com> wrote:
>> On 04/08/2023 22:47, Kaz Kylheku wrote:
>>> On 2023-08-04, Bart <bc@freeuk.com> wrote:
>>>> Presumably `__int32_t` is being defined on top of whatever 32-bit type
>>>> the C compiler has.
>>>>
>>>> So why doesn't it just define it on top of `int32_t`? Or better,
forget
>>>> `__int32_t` and just use `int32_t`?
>>>>
>>>> Don't tell me, there is some really, really complicated reason why it
>>>> has to be done like this (maybe these are some of those
programmers paid
>>>> by the line!).
>>>
>>> Mostly, the reasons can be summarized by that it's not some solo
>>> developer's recently started greenfield project, but something with a
>>> long history on various kinds of machines, and numerous
implementations.
>>> C first had 18 bit int; most machines don't have that now.
>>>
>>> Good thing we are not stuck with int18, right?
>>>
>>
>> And the exact reason why that code can't just do:
>>
>> #include <stdint.h>
>>
>> typedef int32_t __int32_t;
>
> It appears that this thread is about something found in a
> library header _default_types.h.
>
> I don't have a _default_types.h anywhere except a bunch
> of Cygwin trees. It looks like a Newlib thing (a library from the
> BSD world on which Cygwin is based).
>
> The reason the header cannot just do #include <stdint.h>
> is that it is the basis for that header!
>
> $ grep default_types /mnt/c/Cygwin/cygwin64/usr/include/stdint.h
> #include <machine/_default_types.h>
> $ ls /mnt/c/Cygwin/cygwin64/usr/include/machine/_default_types.h
> /mnt/c/Cygwin/cygwin64/usr/include/machine/_default_types.h
>
> The library is designed such that it provides its own <stdint.h>
> header, not relying on the compiler providing one. It defines
> some underscored types in machine/_default_types.h and then it
> uses those to declare the public, standard ones in <stdint.h>.
Which is going around the houses.
stdint.h should be provided by the C implementation, which knows the
exact sizes of its char, short, int, long, long long types. So int32_t
is typically defined of top of int when it knows int is exactly 32 bits.
Even it if prefers to go through all the basic types looking for the one
with a suitable upper limit, why define the intermediate __int32_t at
all, why not just define int32_t.
> I would do it similarly, if I had to.
I have done it, and mine looks like this inside my stdint.h:
typedef int int32_t;
A bit simpler, isn't it? This is for an x64 target. If I wanted to have
a different target where 'int' was 16 bits or 64 bits, say, then that
would have its own dedicated stdint.h file.
>
> Any more trick questions?
It depends; have you get any more convincing answers, other than this is
the mess that one implementation ended up with and it's like that
because it's nobody's job to clean it up.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-05 02:11 +0000 |
| Message-ID | <20230804185340.437@kylheku.com> |
| In reply to | #171652 |
On 2023-08-05, Bart <bc@freeuk.com> wrote:
> On 05/08/2023 01:15, Kaz Kylheku wrote:
> > On 2023-08-04, Bart <bc@freeuk.com> wrote:
> >> On 04/08/2023 22:47, Kaz Kylheku wrote:
> >>> On 2023-08-04, Bart <bc@freeuk.com> wrote:
> >>>> Presumably `__int32_t` is being defined on top of whatever 32-bit type
> >>>> the C compiler has.
> >>>>
> >>>> So why doesn't it just define it on top of `int32_t`? Or better,
> forget
> >>>> `__int32_t` and just use `int32_t`?
> >>>>
> >>>> Don't tell me, there is some really, really complicated reason why it
> >>>> has to be done like this (maybe these are some of those
> programmers paid
> >>>> by the line!).
> >>>
> >>> Mostly, the reasons can be summarized by that it's not some solo
> >>> developer's recently started greenfield project, but something with a
> >>> long history on various kinds of machines, and numerous
> implementations.
> >>> C first had 18 bit int; most machines don't have that now.
> >>>
> >>> Good thing we are not stuck with int18, right?
> >>>
> >>
> >> And the exact reason why that code can't just do:
> >>
> >> #include <stdint.h>
> >>
> >> typedef int32_t __int32_t;
> >
> > It appears that this thread is about something found in a
> > library header _default_types.h.
> >
> > I don't have a _default_types.h anywhere except a bunch
> > of Cygwin trees. It looks like a Newlib thing (a library from the
> > BSD world on which Cygwin is based).
> >
> > The reason the header cannot just do #include <stdint.h>
> > is that it is the basis for that header!
> >
> > $ grep default_types /mnt/c/Cygwin/cygwin64/usr/include/stdint.h
> > #include <machine/_default_types.h>
> > $ ls /mnt/c/Cygwin/cygwin64/usr/include/machine/_default_types.h
> > /mnt/c/Cygwin/cygwin64/usr/include/machine/_default_types.h
> >
> > The library is designed such that it provides its own <stdint.h>
> > header, not relying on the compiler providing one. It defines
> > some underscored types in machine/_default_types.h and then it
> > uses those to declare the public, standard ones in <stdint.h>.
>
> Which is going around the houses.
>
> stdint.h should be provided by the C implementation, which knows the
> exact sizes of its char, short, int, long, long long types.
<stdint.h> is described in the Library section of the standard.
Cygwin's Newlib is a library.
This is not rocket science.
Some compilers are not complete C implementations. GCC isn't
a complete, hosted implementation.
It becomes one when combined with a library.
The GNU project, from the start, provided piecemeal replacement
for Unix tools. People used GNU C on Unix boxes, with the library
(including headers) from those Unix boxes.
GNU has a C library, which is a separate project.
GCC + { glibc, uCLibc, musl, Newlib, Bionic, ...} becomes a C
implementation.
I /think/ GCC now does provide a stdint.h? But it wasn't historically
the case. A library that doesn't depend on the compiler providing
a header like stdint.h will just do it itself.
> So int32_t is typically defined of top of int when it knows int is
> exactly 32 bits.
Fair game for a library.
>
> Even it if prefers to go through all the basic types looking for the one
> with a suitable upper limit, why define the intermediate __int32_t at
> all, why not just define int32_t.
This can only be explained by people familiar with the history
of Newlib and its ongoing maintenance.
The code may date back to a time when you could not rely on
compilers providing <stdint.h>. Newlib wanted its users to
have that and so it "polyfilled" it.
Maybe it would be easy to remove that, but nobody has
noticed and bothered.
p
> > I would do it similarly, if I had to.
> I have done it, and mine looks like this inside my stdint.h:
>
> typedef int int32_t;
>
> A bit simpler, isn't it?
Look at the machines Newlib supports:
https://sourceware.org/git/?p=newlib-cygwin.git;a=tree;f=newlib/libc/machine
It may be that at least one of them doesn't have a 32 bit int.
You can't compare your green field solo project to something like that.
Newlib is not just the basis for Cygwin.
https://sourceware.org/newlib/
Newlib is a C library intended for use on embedded systems. It is a
conglomeration of several library parts, all under free software
licenses that make them easily usable on embedded products.
Newlib is only available in source form. It can be compiled for a wide
array of processors, and will usually work on any architecture with the
addition of a few low-level routines.
--
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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-05 11:00 +0100 |
| Message-ID | <ual6k3$1mu72$1@dont-email.me> |
| In reply to | #171653 |
On 05/08/2023 03:11, Kaz Kylheku wrote:
> On 2023-08-05, Bart <bc@freeuk.com> wrote:
>> On 05/08/2023 01:15, Kaz Kylheku wrote:
>>> On 2023-08-04, Bart <bc@freeuk.com> wrote:
>>>> On 04/08/2023 22:47, Kaz Kylheku wrote:
>>>>> On 2023-08-04, Bart <bc@freeuk.com> wrote:
>>>>>> Presumably `__int32_t` is being defined on top of whatever
32-bit type
>>>>>> the C compiler has.
>>>>>>
>>>>>> So why doesn't it just define it on top of `int32_t`? Or better,
>> forget
>>>>>> `__int32_t` and just use `int32_t`?
>>>>>>
>>>>>> Don't tell me, there is some really, really complicated reason
why it
>>>>>> has to be done like this (maybe these are some of those
>> programmers paid
>>>>>> by the line!).
>>>>>
>>>>> Mostly, the reasons can be summarized by that it's not some solo
>>>>> developer's recently started greenfield project, but something with a
>>>>> long history on various kinds of machines, and numerous
>> implementations.
>>>>> C first had 18 bit int; most machines don't have that now.
>>>>>
>>>>> Good thing we are not stuck with int18, right?
>>>>>
>>>>
>>>> And the exact reason why that code can't just do:
>>>>
>>>> #include <stdint.h>
>>>>
>>>> typedef int32_t __int32_t;
>>>
>>> It appears that this thread is about something found in a
>>> library header _default_types.h.
>>>
>>> I don't have a _default_types.h anywhere except a bunch
>>> of Cygwin trees. It looks like a Newlib thing (a library from the
>>> BSD world on which Cygwin is based).
>>>
>>> The reason the header cannot just do #include <stdint.h>
>>> is that it is the basis for that header!
>>>
>>> $ grep default_types /mnt/c/Cygwin/cygwin64/usr/include/stdint.h
>>> #include <machine/_default_types.h>
>>> $ ls /mnt/c/Cygwin/cygwin64/usr/include/machine/_default_types.h
>>> /mnt/c/Cygwin/cygwin64/usr/include/machine/_default_types.h
>>>
>>> The library is designed such that it provides its own <stdint.h>
>>> header, not relying on the compiler providing one. It defines
>>> some underscored types in machine/_default_types.h and then it
>>> uses those to declare the public, standard ones in <stdint.h>.
>>
>> Which is going around the houses.
>>
>> stdint.h should be provided by the C implementation, which knows the
>> exact sizes of its char, short, int, long, long long types.
>
> <stdint.h> is described in the Library section of the standard.
>
> Cygwin's Newlib is a library.
>
> This is not rocket science.
>
> Some compilers are not complete C implementations. GCC isn't
> a complete, hosted implementation.
>
> It becomes one when combined with a library.
>
> The GNU project, from the start, provided piecemeal replacement
> for Unix tools. People used GNU C on Unix boxes, with the library
> (including headers) from those Unix boxes.
>
> GNU has a C library, which is a separate project.
>
> GCC + { glibc, uCLibc, musl, Newlib, Bionic, ...} becomes a C
> implementation.
>
> I /think/ GCC now does provide a stdint.h? But it wasn't historically
> the case. A library that doesn't depend on the compiler providing
> a header like stdint.h will just do it itself.
>
>> So int32_t is typically defined of top of int when it knows int is
>> exactly 32 bits.
>
> Fair game for a library.
>>
>> Even it if prefers to go through all the basic types looking for the one
>> with a suitable upper limit, why define the intermediate __int32_t at
>> all, why not just define int32_t.
>
> This can only be explained by people familiar with the history
> of Newlib and its ongoing maintenance.
>
> The code may date back to a time when you could not rely on
> compilers providing <stdint.h>. Newlib wanted its users to
> have that and so it "polyfilled" it.
>
> Maybe it would be easy to remove that, but nobody has
> noticed and bothered.
> p
>>> I would do it similarly, if I had to.
>> I have done it, and mine looks like this inside my stdint.h:
>>
>> typedef int int32_t;
>>
>> A bit simpler, isn't it?
>
> Look at the machines Newlib supports:
>
>
https://sourceware.org/git/?p=newlib-cygwin.git;a=tree;f=newlib/libc/machine
So each of those dozens of targets (which mostly seem to use
8-16-32-64-bit word sizes) has its own set of headers?
Even better! Use a dedicated header for each one that defines __int32_t
using one typedef.
> It may be that at least one of them doesn't have a 32 bit int.
>
> You can't compare your green field solo project to something like that.
I've written compilers for five architectures, starting in 1979.
I take a different approach: I don't try and support myriad different
targets spanning decades using only a single file that is a mess of
conditional code blocks.
> Newlib is not just the basis for Cygwin.
>
> https://sourceware.org/newlib/
>
> Newlib is a C library intended for use on embedded systems.
And? I gave a link yesterday to a header designed for use on Arduino, it
had:
typedef uint8_t byte;
So breaking two rules at once: using stdint.h (imagine if a user program
included arduino.h, but is inadvertently exposed to uint8_t which must
be kept under wraps unless they explicitly use stdint.h), and defining a
much better alias for a C99 type,.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-06 16:50 +0200 |
| Message-ID | <uaoc00$2ad07$1@dont-email.me> |
| In reply to | #171662 |
On 05/08/2023 12:00, Bart wrote: > On 05/08/2023 03:11, Kaz Kylheku wrote: > > Newlib is a C library intended for use on embedded systems. > > And? I gave a link yesterday to a header designed for use on Arduino, it > had: > > typedef uint8_t byte; > > So breaking two rules at once: using stdint.h (imagine if a user program > included arduino.h, but is inadvertently exposed to uint8_t which must > be kept under wraps unless they explicitly use stdint.h), and defining a > much better alias for a C99 type,. > The Arduino headers are not standard C library headers. The Arduino is aimed as a system that is easy to get started with for learning, testing, and proof of concepts. It does not use C, but a subset of C++, and its IDE hides away many of the details and complexities of C++, toolchains (it is based on gcc), and embedded development. This makes it easy to get started and to make simple test code - but terrible for serious work where you want repeatable builds, efficiency, reliability, or other features that are usually important in embedded development of actual products. It would have been better, IMHO, if it did not use C or C++ at all, but rather was based on a language where ease of use was already given more precedence than efficiency - perhaps BASIC would have been a better fit.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-08-06 18:40 -0400 |
| Message-ID | <qjVzM.447263$SuUf.69717@fx14.iad> |
| In reply to | #171662 |
On 8/5/23 6:00 AM, Bart wrote:
> On 05/08/2023 03:11, Kaz Kylheku wrote:
> > On 2023-08-05, Bart <bc@freeuk.com> wrote:
> >> On 05/08/2023 01:15, Kaz Kylheku wrote:
> >>> On 2023-08-04, Bart <bc@freeuk.com> wrote:
> >>>> On 04/08/2023 22:47, Kaz Kylheku wrote:
> >>>>> On 2023-08-04, Bart <bc@freeuk.com> wrote:
> >>>>>> Presumably `__int32_t` is being defined on top of whatever
> 32-bit type
> >>>>>> the C compiler has.
> >>>>>>
> >>>>>> So why doesn't it just define it on top of `int32_t`? Or better,
> >> forget
> >>>>>> `__int32_t` and just use `int32_t`?
> >>>>>>
> >>>>>> Don't tell me, there is some really, really complicated reason
> why it
> >>>>>> has to be done like this (maybe these are some of those
> >> programmers paid
> >>>>>> by the line!).
> >>>>>
> >>>>> Mostly, the reasons can be summarized by that it's not some solo
> >>>>> developer's recently started greenfield project, but something
> with a
> >>>>> long history on various kinds of machines, and numerous
> >> implementations.
> >>>>> C first had 18 bit int; most machines don't have that now.
> >>>>>
> >>>>> Good thing we are not stuck with int18, right?
> >>>>>
> >>>>
> >>>> And the exact reason why that code can't just do:
> >>>>
> >>>> #include <stdint.h>
> >>>>
> >>>> typedef int32_t __int32_t;
> >>>
> >>> It appears that this thread is about something found in a
> >>> library header _default_types.h.
> >>>
> >>> I don't have a _default_types.h anywhere except a bunch
> >>> of Cygwin trees. It looks like a Newlib thing (a library from the
> >>> BSD world on which Cygwin is based).
> >>>
> >>> The reason the header cannot just do #include <stdint.h>
> >>> is that it is the basis for that header!
> >>>
> >>> $ grep default_types /mnt/c/Cygwin/cygwin64/usr/include/stdint.h
> >>> #include <machine/_default_types.h>
> >>> $ ls /mnt/c/Cygwin/cygwin64/usr/include/machine/_default_types.h
> >>> /mnt/c/Cygwin/cygwin64/usr/include/machine/_default_types.h
> >>>
> >>> The library is designed such that it provides its own <stdint.h>
> >>> header, not relying on the compiler providing one. It defines
> >>> some underscored types in machine/_default_types.h and then it
> >>> uses those to declare the public, standard ones in <stdint.h>.
> >>
> >> Which is going around the houses.
> >>
> >> stdint.h should be provided by the C implementation, which knows the
> >> exact sizes of its char, short, int, long, long long types.
> >
> > <stdint.h> is described in the Library section of the standard.
> >
> > Cygwin's Newlib is a library.
> >
> > This is not rocket science.
> >
> > Some compilers are not complete C implementations. GCC isn't
> > a complete, hosted implementation.
> >
> > It becomes one when combined with a library.
> >
> > The GNU project, from the start, provided piecemeal replacement
> > for Unix tools. People used GNU C on Unix boxes, with the library
> > (including headers) from those Unix boxes.
> >
> > GNU has a C library, which is a separate project.
> >
> > GCC + { glibc, uCLibc, musl, Newlib, Bionic, ...} becomes a C
> > implementation.
> >
> > I /think/ GCC now does provide a stdint.h? But it wasn't historically
> > the case. A library that doesn't depend on the compiler providing
> > a header like stdint.h will just do it itself.
> >
> >> So int32_t is typically defined of top of int when it knows int is
> >> exactly 32 bits.
> >
> > Fair game for a library.
> >>
> >> Even it if prefers to go through all the basic types looking for the
> one
> >> with a suitable upper limit, why define the intermediate __int32_t at
> >> all, why not just define int32_t.
> >
> > This can only be explained by people familiar with the history
> > of Newlib and its ongoing maintenance.
> >
> > The code may date back to a time when you could not rely on
> > compilers providing <stdint.h>. Newlib wanted its users to
> > have that and so it "polyfilled" it.
> >
> > Maybe it would be easy to remove that, but nobody has
> > noticed and bothered.
> > p
> >>> I would do it similarly, if I had to.
> >> I have done it, and mine looks like this inside my stdint.h:
> >>
> >> typedef int int32_t;
> >>
> >> A bit simpler, isn't it?
> >
> > Look at the machines Newlib supports:
> >
> >
> https://sourceware.org/git/?p=newlib-cygwin.git;a=tree;f=newlib/libc/machine
>
> So each of those dozens of targets (which mostly seem to use
> 8-16-32-64-bit word sizes) has its own set of headers?
>
> Even better! Use a dedicated header for each one that defines __int32_t
> using one typedef.
> > It may be that at least one of them doesn't have a 32 bit int.
> >
> > You can't compare your green field solo project to something like that.
>
> I've written compilers for five architectures, starting in 1979.
>
> I take a different approach: I don't try and support myriad different
> targets spanning decades using only a single file that is a mess of
> conditional code blocks.
>
> > Newlib is not just the basis for Cygwin.
> >
> > https://sourceware.org/newlib/
> >
> > Newlib is a C library intended for use on embedded systems.
>
> And? I gave a link yesterday to a header designed for use on Arduino, it
> had:
>
> typedef uint8_t byte;
>
> So breaking two rules at once: using stdint.h (imagine if a user program
> included arduino.h, but is inadvertently exposed to uint8_t which must
> be kept under wraps unless they explicitly use stdint.h), and defining a
> much better alias for a C99 type,.
>
>
>
And, since arduino.h isn't listed in the C standard as an implementation
header, it required to follow the restrictions of an implementation
header, nor is it allowed to presume it can use implementation namespace.
You seem to not understand how "C" works, which really puts you at a big
disadvantage.
For every thing you need to look at where it is defined, and what rules
that means it needs to follow (and realize some things will cross the
line or just be "incorrect", even if it "works")
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-07 00:31 +0000 |
| Message-ID | <20230806171223.293@kylheku.com> |
| In reply to | #171662 |
On 2023-08-05, Bart <bc@freeuk.com> wrote: > On 05/08/2023 03:11, Kaz Kylheku wrote: > > On 2023-08-05, Bart <bc@freeuk.com> wrote: > >> I have done it, and mine looks like this inside my stdint.h: > >> > >> typedef int int32_t; > >> > >> A bit simpler, isn't it? > > > > Look at the machines Newlib supports: > > > > > https://sourceware.org/git/?p=newlib-cygwin.git;a=tree;f=newlib/libc/machine > > So each of those dozens of targets (which mostly seem to use > 8-16-32-64-bit word sizes) has its own set of headers? > > Even better! Use a dedicated header for each one that defines __int32_t > using one typedef. For one reason or another, in spite having these separate directories for machine-specific C and assembly code, they rolled that _default_types.h thing into one header. Probably they found it quite manageable that way. The content isn't very long or complicated. I actually have some gripes with Newlib, but not this. Newlib is based on some BSD code (I don't know the exact history) which interprets feature selection macros in a silly way. In BSD land, if you don't define feature selection macros like -D_POSIX_C_SOURCE=whatever, your program is exposed to everything by default: every extension available in every header. The feature selection macros do not *enable* features, but *hide*. Newlib inherits this problem. When we do this: gcc -ansi -D_POSIX_SOURCE then Newlib hides all the POSIX extensions in headers like <stdio.h>. Why? Because -ansi turns on some GCC macro like __STDC__ or whatever, which Newlib interprets as meaning "hide everything but ANSI C". And it interprets _POSIX_SOURCE as "hide everything but 1990's POSIX stuff". But there is nothing left to hide: the POSIX stuff is all hidden. The sane thing is for feature selection macros to enable rather than disable. If at least one feature selection macro is present, should enable the union of all feature selection macros, and hide everything else. So that, for instance, -ansi -D_POSIX_SOURCE gets the compiler to use the C90 dialect, and _POSIX_SOURCE reveals classic POSIX identifiers like fileno in <stdio.h> and strdup in <string.h>. > > Newlib is not just the basis for Cygwin. > > > > https://sourceware.org/newlib/ > > > > Newlib is a C library intended for use on embedded systems. > > And? I gave a link yesterday to a header designed for use on Arduino, it > had: > > typedef uint8_t byte; > > So breaking two rules at once: using stdint.h (imagine if a user program > included arduino.h, but is inadvertently exposed to uint8_t which must > be kept under wraps unless they explicitly use stdint.h), and defining a > much better alias for a C99 type,. Since arduino.h isn't a standard C header, it can do whatever the Arduino people want. They can document that <arduino.h> includes <stdint.h> and then if it does exactly that, everthing is copacetic. They could have it that including <arduino.h> causes the rest of the translation unit to be parsed as Fortran. When a C program includes a header that it doesn't provide, the header is not in the standard language, the behavior is undefined. - The header might be not found, in which case that's a diagnosable error. - A header might be found and bring in arbitrary content that can cause any behavior imaginable. There could be an #include <wipe_flash.h> which causes the compiled object file to wipe the flash on the target machine without the program having to call any function to do that. -- 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 | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-08-04 22:44 -0400 |
| Message-ID | <RHizM.23810$Wk53.20739@fx01.iad> |
| In reply to | #171650 |
On 8/4/23 7:43 PM, Bart wrote: > On 04/08/2023 22:47, Kaz Kylheku wrote: > > On 2023-08-04, Bart <bc@freeuk.com> wrote: > >> Presumably `__int32_t` is being defined on top of whatever 32-bit type > >> the C compiler has. > >> > >> So why doesn't it just define it on top of `int32_t`? Or better, forget > >> `__int32_t` and just use `int32_t`? > >> > >> Don't tell me, there is some really, really complicated reason why it > >> has to be done like this (maybe these are some of those programmers > paid > >> by the line!). > > > > Mostly, the reasons can be summarized by that it's not some solo > > developer's recently started greenfield project, but something with a > > long history on various kinds of machines, and numerous implementations. > > C first had 18 bit int; most machines don't have that now. > > > > Good thing we are not stuck with int18, right? > > > > And the exact reason why that code can't just do: > > #include <stdint.h> > > typedef int32_t __int32_t; > > is? I can't imagine that it still needs to run on the PDP7, and with the > code shown, it wouldn't work anyway. > > There have dozens of posts extolling the benefits of using stdint.h, and > not rolling your own types, and now we have a piece of code that > completely ignores that advice. System headers are not allowed to bring in identifiers from another system header without explicit indication that it should do so in the Standard. As int32_t is an identifier in the user namespace UNLESS <stdint.h> has been included by USER code, or it is defined to be included by some header that it includes. The header you are talking about, is an INTERNAL header, used by system headers other than <stdint.h>, so it isn't allowed to define symbols like int32_t Do you not understand the rules of namespace?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-05 10:46 +0100 |
| Message-ID | <ual5qb$1mrft$1@dont-email.me> |
| In reply to | #171654 |
On 05/08/2023 03:44, Richard Damon wrote: > On 8/4/23 7:43 PM, Bart wrote: >> On 04/08/2023 22:47, Kaz Kylheku wrote: >> > On 2023-08-04, Bart <bc@freeuk.com> wrote: >> >> Presumably `__int32_t` is being defined on top of whatever 32-bit >> type >> >> the C compiler has. >> >> >> >> So why doesn't it just define it on top of `int32_t`? Or better, >> forget >> >> `__int32_t` and just use `int32_t`? >> >> >> >> Don't tell me, there is some really, really complicated reason why it >> >> has to be done like this (maybe these are some of those >> programmers paid >> >> by the line!). >> > >> > Mostly, the reasons can be summarized by that it's not some solo >> > developer's recently started greenfield project, but something with a >> > long history on various kinds of machines, and numerous >> implementations. >> > C first had 18 bit int; most machines don't have that now. >> > >> > Good thing we are not stuck with int18, right? >> > >> >> And the exact reason why that code can't just do: >> >> #include <stdint.h> >> >> typedef int32_t __int32_t; >> >> is? I can't imagine that it still needs to run on the PDP7, and with >> the code shown, it wouldn't work anyway. >> >> There have dozens of posts extolling the benefits of using stdint.h, >> and not rolling your own types, and now we have a piece of code that >> completely ignores that advice. > > System headers are not allowed to bring in identifiers from another > system header without explicit indication that it should do so in the > Standard. > > As int32_t is an identifier in the user namespace UNLESS <stdint.h> has > been included by USER code, or it is defined to be included by some > header that it includes. > > The header you are talking about, is an INTERNAL header, used by system > headers other than <stdint.h>, so it isn't allowed to define symbols > like int32_t > > Do you not understand the rules of namespace? So, despite C99 introducing those types in stdint.h, system headers are not allowed to use stdint.h because it int32_t cannot be exposed to user programs unless they explicitly include stdint.h? And those system headers cannot have stdint.h being included in any internal headerss that they call, for the same reason? Does that mean that none of the functions of the C runtime declared in the system headers will ever be allowed to use C99 types? It gets better and better! This explanation is anyway at odds with that provided by Kaz, where the code apparently is in an external library, not a component of the system library. If what you say is the case, then NO library should be allowed to use int32_t in their APIs, unless a prior '#include <stdint.h>' has been seen in any user code that wants to use that library. Because the user might be defining int32_t for their own purposes? (Isn't a _t suffix reserved? I find that abolutely extraordinary. I thought C's type system was already a complete mess. This is verging on unbelievable. So, basically, C doesn't really have int32_t as a type, not one you can just use anywhere; it is a privileged type.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-08-06 07:53 -0400 |
| Message-ID | <NQLzM.86422$uEkc.62848@fx35.iad> |
| In reply to | #171660 |
On 8/5/23 5:46 AM, Bart wrote: > On 05/08/2023 03:44, Richard Damon wrote: > > On 8/4/23 7:43 PM, Bart wrote: > >> On 04/08/2023 22:47, Kaz Kylheku wrote: > >> > On 2023-08-04, Bart <bc@freeuk.com> wrote: > >> >> Presumably `__int32_t` is being defined on top of whatever 32-bit > >> type > >> >> the C compiler has. > >> >> > >> >> So why doesn't it just define it on top of `int32_t`? Or better, > >> forget > >> >> `__int32_t` and just use `int32_t`? > >> >> > >> >> Don't tell me, there is some really, really complicated reason > why it > >> >> has to be done like this (maybe these are some of those > >> programmers paid > >> >> by the line!). > >> > > >> > Mostly, the reasons can be summarized by that it's not some solo > >> > developer's recently started greenfield project, but something > with a > >> > long history on various kinds of machines, and numerous > >> implementations. > >> > C first had 18 bit int; most machines don't have that now. > >> > > >> > Good thing we are not stuck with int18, right? > >> > > >> > >> And the exact reason why that code can't just do: > >> > >> #include <stdint.h> > >> > >> typedef int32_t __int32_t; > >> > >> is? I can't imagine that it still needs to run on the PDP7, and with > >> the code shown, it wouldn't work anyway. > >> > >> There have dozens of posts extolling the benefits of using stdint.h, > >> and not rolling your own types, and now we have a piece of code that > >> completely ignores that advice. > > > > System headers are not allowed to bring in identifiers from another > > system header without explicit indication that it should do so in the > > Standard. > > > > As int32_t is an identifier in the user namespace UNLESS <stdint.h> has > > been included by USER code, or it is defined to be included by some > > header that it includes. > > > > The header you are talking about, is an INTERNAL header, used by system > > headers other than <stdint.h>, so it isn't allowed to define symbols > > like int32_t > > > > Do you not understand the rules of namespace? > > So, despite C99 introducing those types in stdint.h, system headers are > not allowed to use stdint.h because it int32_t cannot be exposed to user > programs unless they explicitly include stdint.h? Right. User namespace must be respected. A header only gets to use the namespace authorized by THAT header, which doesn't include names used in some other arbitrary header unless the Standard says it does. > > And those system headers cannot have stdint.h being included in any > internal headerss that they call, for the same reason? Yep. Can't use names that are still in the use namespace. int32_t is in the user namespace until the USER does something to give it back to the implementation, which is by including <stdint.h> or a header DEFINED BY THE STANDARD to possible add that name. > > Does that mean that none of the functions of the C runtime declared in > the system headers will ever be allowed to use C99 types? None of the current headers can. It could introduce a new header that defines that it also reserves the new type names, and functions in that header could use the new types. THe key point is that user namespace is respected, and no symbols in that namespace can be used by the system without an explicit action of the code (like including a header). > > It gets better and better! > > This explanation is anyway at odds with that provided by Kaz, where the > code apparently is in an external library, not a component of the system > library. An external library has a similar restriction because it needs to be compatible with code that has included <stdint.h> and thus those names might be reserved for the system. But in that case, it can't use __ names. But, he said it was in something like _int_types.h, which could well be a system header (and in fact is very likely a system header) > > If what you say is the case, then NO library should be allowed to use > int32_t in their APIs, unless a prior '#include <stdint.h>' has been > seen in any user code that wants to use that library. A USER library just needs to define that it effectively includes <stdint.h>, and then it can use those names for the standard defined purpose. The restriction is just on the implementation, it has no impact on what "user libraries" can do. They need to respect the system namespace division, and should define how they will interact with other code as far as namespace. > > Because the user might be defining int32_t for their own purposes? > (Isn't a _t suffix reserved? To my knowledge, _t reservation was done by POSIX, not the C standard. The C Standard defines these sort of names that will become reserved when a given header is included. Since in C, the "name" of a type is actually actually immaterial except within that translation unit, there is no need to globally reserve the names. > > I find that abolutely extraordinary. You don't seem to understand backwards compatibility. > > I thought C's type system was already a complete mess. This is verging > on unbelievable. > > So, basically, C doesn't really have int32_t as a type, not one you can > just use anywhere; it is a privileged type. > > It is usable BY THE USER, by just including <stdint.h>, if that type exists in the system. The IMPLEMENTATION can't use it by that name unless it KNOWS that <stdint.h> has been included. There is a hard line in namespaces between user code and implementation code, as duplicating names in the same namespace is a big no-no.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-07 11:53 +0200 |
| Message-ID | <uaqevk$2qe14$1@dont-email.me> |
| In reply to | #171660 |
On 05/08/2023 11:46, Bart wrote: > On 05/08/2023 03:44, Richard Damon wrote: > > System headers are not allowed to bring in identifiers from another > > system header without explicit indication that it should do so in the > > Standard. > > > > As int32_t is an identifier in the user namespace UNLESS <stdint.h> has > > been included by USER code, or it is defined to be included by some > > header that it includes. > > > > The header you are talking about, is an INTERNAL header, used by system > > headers other than <stdint.h>, so it isn't allowed to define symbols > > like int32_t > > > > Do you not understand the rules of namespace? > > So, despite C99 introducing those types in stdint.h, system headers are > not allowed to use stdint.h because it int32_t cannot be exposed to user > programs unless they explicitly include stdint.h? > "System headers" is perhaps not an ideal term to use, because the term is not clear. C standard library headers cannot define any identifiers other than those they say they will define, or that are within the reserved formats (like starting with two underscores). They also have to work regardless of the order people use them, and regardless of what identifiers user code has defined before the #include. This means that a C library header such as <string.h> that needs, say, "size_t" from <stddef.h> can't just include that file itself - maybe the user wants to make their own definition of NULL. The header can't just do a typedef for "size_t", since perhaps the user has included <stddef.h> before <string.h>. So you need guard macros around the typedef. The declaration of a function or a macro in a standard header can't use informative parameter names like "format" or "filename", because someone might have defined these as macros before including the header. These kinds of subtleties may be lost on you, because - like most C programmers - you put your standard library headers at the start of your C file, and don't do weird stuff in your coding. But serious libraries and C standard headers have to take all this kind of thing into account, and it makes them messy. But really, it doesn't matter - this is all part of the implementation, and not something users need to examine or understand - they should get their information from the documentation, not the standard library headers. Of course it is easy to see how this could all have been much better if the C standard library (and C language itself) were re-done to get the features of modern C without the need of backwards compatibility. So when the C++ library was made, everything (except what it inherited from C) was put inside the std:: namespace. Then any standard library headers can freely include any others, since all the identifiers are in a reserved namespace. The term "system headers" could also refer to headers specific to the OS - Windows headers, Linux headers, or whatever. These kinds of headers most certainly /can/ use <stdint.h> and any other standard library headers. They can also use whatever of their own headers they like, as long as any identifier usage is documented. (But like many OS's, these have histories stretching back before C99, and rarely use C99 headers and types.) > And those system headers cannot have stdint.h being included in any > internal headerss that they call, for the same reason? > > Does that mean that none of the functions of the C runtime declared in > the system headers will ever be allowed to use C99 types? > New ones certainly can. Old ones cannot. So when C11 introduced <threads.h> and <stdatomic.h>, if the people behind these APIs thought the <stdint.h> types would have been useful, they could happily use them. But they would only have done so if there were real benefits - they would not add dependencies unnecessarily. > It gets better and better! > We are hoping that your understanding will get better and better. (Some might say such optimism is unrealistic.) Your opinions, of course, are your own - no one expects them to change. (And I don't think many others have expressed opinions - we understand how C works, and why it works that way, but that does not imply that any particular person here likes every aspect of C or agrees with every design decision.) > This explanation is anyway at odds with that provided by Kaz, where the > code apparently is in an external library, not a component of the system > library. > I believe the headers mentioned by Kaz were used for providing the C standard library headers on some platform. Again, it really doesn't matter how these are implemented or what other headers they use - it only matters that the conform to the documented specifications for the headers, providing the public interface that is documented without interfering with any user-level symbols. > If what you say is the case, then NO library should be allowed to use > int32_t in their APIs, unless a prior '#include <stdint.h>' has been > seen in any user code that wants to use that library. > User code can do what it likes. Library headers should conform to the documentation for the library (or the documentation should match the headers, whichever way works best). The C standard library headers have to match the C standards documentation - other libraries make their own choices. But it is generally considered a good idea for most C headers that they be usable stand-alone. That is, if a header makes use of <stdint.h> types, then it should include <stdint.h> itself. Headers should also have guards so that they can safely be included multiple times. Well-designed headers should be usable regardless of the ordering of the includes, and regardless of how many or how few are included. They should at least work for code that puts the includes at the start and does not go out of its way to be awkward. This restricts user coding style more than the C standard library headers are allowed to do, but it is more convenient for users and for the writers of the library headers. > Because the user might be defining int32_t for their own purposes? They can do, as long as they don't include <stdint.h> (or <inttypes.h>). > (Isn't a _t suffix reserved? By POSIX - not by C. > > I find that abolutely extraordinary. > > I thought C's type system was already a complete mess. This is verging > on unbelievable. > > So, basically, C doesn't really have int32_t as a type, not one you can > just use anywhere; it is a privileged type. > It is a type defined in a standard library header.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-06 16:43 +0200 |
| Message-ID | <uaobja$2a6ui$1@dont-email.me> |
| In reply to | #171650 |
On 05/08/2023 01:43, Bart wrote: > On 04/08/2023 22:47, Kaz Kylheku wrote: > > On 2023-08-04, Bart <bc@freeuk.com> wrote: > >> Presumably `__int32_t` is being defined on top of whatever 32-bit type > >> the C compiler has. > >> > >> So why doesn't it just define it on top of `int32_t`? Or better, forget > >> `__int32_t` and just use `int32_t`? > >> > >> Don't tell me, there is some really, really complicated reason why it > >> has to be done like this (maybe these are some of those programmers > paid > >> by the line!). > > > > Mostly, the reasons can be summarized by that it's not some solo > > developer's recently started greenfield project, but something with a > > long history on various kinds of machines, and numerous implementations. > > C first had 18 bit int; most machines don't have that now. > > > > Good thing we are not stuck with int18, right? > > > > And the exact reason why that code can't just do: > > #include <stdint.h> > > typedef int32_t __int32_t; > > is? Library headers can't #include <stdint.h>, because it might conflict with user identifiers. User code can't (or at least, shouldn't) define identifiers starting with two underscores. So that code is bad for any use-case. Serious C compilers and libraries are very careful to follow the rules as closely as possible, and to avoid any possibility of intruding on programmers' freedom of coding if they can. Since the C standards allow programmers to define a variable, function, macro or type called "int32_t" as long as they don't include <stdint.h> or <inttypes.h>, then the C libraries and compilers also allow that - no matter how silly it might seem for a program to have a function "int32_t". The situation is greatly complicated for libraries designed to work with a range of compilers and targets, including ones with different sizes of basic integers and other fundamental implementation-dependent behaviour. They also like to support a range of C versions (including all minor details), and perhaps other options and variants available in some toolchains. In that context, a bit messy definitions in a header that no one looks at does not really matter. In hindsight, it's easy to see how the language could have been designed a little differently to get the features we have now, but C has evolved with backwards compatibility as a major guiding factor. Simplicity of hidden headers or implementations of C compilers and libraries, on the other hand, has always been considered pretty much irrelevant in comparison.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-08-04 19:50 -0700 |
| Message-ID | <86wmyafbid.fsf@linuxsc.com> |
| In reply to | #171643 |
Richard Damon <Richard@Damon-Family.org> writes: > On 8/4/23 10:25 AM, Bart wrote: > >> [...] > > Maybe your problem is you dont understand [...] Bart's problem isn't that he doesn't understand. Bart's problem is that he doesn't _want_ to understand.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-05 02:58 +0000 |
| Message-ID | <20230804195226.231@kylheku.com> |
| In reply to | #171656 |
On 2023-08-05, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > Richard Damon <Richard@Damon-Family.org> writes: > >> On 8/4/23 10:25 AM, Bart wrote: >> >>> [...] >> >> Maybe your problem is you dont understand [...] > > Bart's problem isn't that he doesn't understand. Bart's > problem is that he doesn't _want_ to understand. BartC act a lot like someone whose salary depends on not understanding. All that is missing is the actual money. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
Page 23 of 49 — ← Prev page 1 … 21 22 [23] 24 25 … 49 Next page →
Back to top | Article view | comp.lang.c
csiph-web