Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #145830 > unrolled thread
| Started by | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| First post | 2019-08-28 16:11 -0500 |
| Last post | 2019-09-09 01:09 -0700 |
| Articles | 20 on this page of 144 — 32 participants |
Back to article view | Back to comp.lang.c
"“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Lynn McGuire <lynnmcguire5@gmail.com> - 2019-08-28 16:11 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" already5chosen@yahoo.com - 2019-08-28 15:48 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bart <bc@freeuk.com> - 2019-08-29 00:20 +0100
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Les Cargill <lcargill99@comcast.com> - 2019-09-01 17:31 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Melzzzzz <Melzzzzz@zzzzz.com> - 2019-08-29 02:36 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-29 11:02 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Ian Collins <ian-news@hotmail.com> - 2019-08-29 22:21 +1200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-29 13:24 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Keith Thompson <kst-u@mib.org> - 2019-08-29 13:29 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 08:04 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Keith Thompson <kst-u@mib.org> - 2019-08-29 23:11 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-30 10:14 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 07:42 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-29 14:54 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 08:07 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@gmail.com> - 2019-08-29 05:14 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bart <bc@freeuk.com> - 2019-08-29 15:00 +0100
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@gmail.com> - 2019-08-29 10:39 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Thiago Adams <thiago.adams@gmail.com> - 2019-08-30 04:24 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bart <bc@freeuk.com> - 2019-08-30 20:52 +0100
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" legalize+jeeves@mail.xmission.com (Richard) - 2019-09-03 20:07 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@gmail.com> - 2019-09-03 17:13 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-29 14:53 +0200
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" gazelle@shell.xmission.com (Kenny McCormack) - 2019-08-29 13:14 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-29 15:38 +0200
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" legalize+jeeves@mail.xmission.com (Richard) - 2019-09-03 20:09 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Paavo Helde <myfirstname@osa.pri.ee> - 2019-09-04 08:31 +0300
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" legalize+jeeves@mail.xmission.com (Richard) - 2019-09-05 16:55 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 08:13 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 08:38 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 08:51 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 10:13 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 10:18 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 10:31 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 10:39 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 10:43 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 10:47 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-30 11:41 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 11:56 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-30 13:08 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 13:47 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-31 23:39 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-01 05:16 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-01 16:03 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-01 18:22 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" My nuts hurt <cdalten@gmail.com> - 2019-09-01 12:20 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Richard Damon <Richard@Damon-Family.org> - 2019-09-01 15:23 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-01 22:39 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-09-02 00:48 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-02 06:47 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Richard Damon <Richard@Damon-Family.org> - 2019-09-02 11:12 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-02 17:52 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Manfred <noname@add.invalid> - 2019-09-02 18:43 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Richard Damon <Richard@Damon-Family.org> - 2019-09-02 13:05 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-02 19:33 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Richard Damon <Richard@Damon-Family.org> - 2019-09-02 17:16 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 06:49 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 08:31 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 08:39 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 09:06 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 09:19 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 10:30 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Richard Damon <Richard@Damon-Family.org> - 2019-09-03 07:11 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 13:17 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 15:29 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 15:42 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 15:51 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Manfred <noname@add.invalid> - 2019-09-03 17:35 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 17:43 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-09-03 18:51 +0100
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 20:03 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 21:53 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-04 06:42 +0200
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" legalize+jeeves@mail.xmission.com (Richard) - 2019-09-05 16:56 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-06 07:10 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" My nuts hurt <cdalten@gmail.com> - 2019-09-06 12:32 -0700
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" scott@slp53.sl.home (Scott Lurndal) - 2019-09-03 20:33 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-04 06:38 +0200
Re: "?Rust is the future of systems programming, C is the new Assembly?: Intel principal engineer, Josh Triplett" antispam@math.uni.wroc.pl - 2019-09-03 22:08 +0000
Re: "?Rust is the future of systems programming, C is the new Assembly?: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-04 06:41 +0200
Re: "?Rust is the future of systems programming, C is the new Assembly?: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-04 09:13 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 21:50 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-09-03 22:43 +0100
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-04 09:24 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Keith Thompson <kst-u@mib.org> - 2019-09-03 11:03 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 22:14 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Clifford Heath <no.spam@please.net> - 2019-09-04 10:47 +1000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Ian Collins <ian-news@hotmail.com> - 2019-09-04 16:56 +1200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-04 09:37 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-09-03 05:37 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Hans im Glück <hig68@gmx.at> - 2019-09-03 15:26 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-09-03 06:54 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 16:08 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" My nuts hurt <cdalten@gmail.com> - 2019-09-03 07:16 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 19:07 +0200
Re: Exceptions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-09-04 06:12 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" My nuts hurt <cdalten@gmail.com> - 2019-09-03 07:14 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2019-09-05 22:02 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-08-31 13:20 +0100
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-31 23:45 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Paavo Helde <myfirstname@osa.pri.ee> - 2019-08-30 14:08 +0300
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 13:37 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 13:48 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" My nuts hurt <cdalten@gmail.com> - 2019-08-30 05:01 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Paavo Helde <myfirstname@osa.pri.ee> - 2019-08-30 15:18 +0300
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 14:24 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 15:43 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 16:23 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Melzzzzz <Melzzzzz@zzzzz.com> - 2019-08-30 14:40 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" already5chosen@yahoo.com - 2019-08-30 07:56 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Melzzzzz <Melzzzzz@zzzzz.com> - 2019-08-30 15:08 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 19:19 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Anton Shepelev <anton.txt@gmail.com> - 2019-08-31 03:05 +0300
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Ian Collins <ian-news@hotmail.com> - 2019-08-31 12:18 +1200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-08-31 10:48 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-31 11:43 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Paavo Helde <myfirstname@osa.pri.ee> - 2019-08-31 17:17 +0300
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-31 16:28 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-01 00:06 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Paavo Helde <myfirstname@osa.pri.ee> - 2019-09-01 15:49 +0300
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-01 16:12 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" already5chosen@yahoo.com - 2019-09-08 10:23 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-08 20:29 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" My nuts hurt <cdalten@gmail.com> - 2019-09-09 12:51 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 16:57 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 15:42 +0200
Re: "???Rust is the future of systems programming, C is the new Assembly???: Intel principal engineer, Josh Triplett" Juha Nieminen <nospam@thanks.invalid> - 2019-08-30 21:03 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Ian Collins <ian-news@hotmail.com> - 2019-08-31 09:42 +1200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 23:53 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@gmail.com> - 2019-09-06 06:24 -0500
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" scott@slp53.sl.home (Scott Lurndal) - 2019-09-06 13:51 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@gmail.com> - 2019-09-06 22:03 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@hotmail.com> - 2019-09-07 10:57 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-07 18:17 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-07 18:48 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bart <bc@freeuk.com> - 2019-09-07 18:09 +0100
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@gmail.com> - 2019-09-07 15:32 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" legalize+jeeves@mail.xmission.com (Richard) - 2019-09-03 18:39 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 20:46 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-09-04 01:07 +0100
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" William Ahern <william@25thandClement.com> - 2019-09-03 20:04 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-04 06:46 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Melzzzzz <Melzzzzz@zzzzz.com> - 2019-09-04 04:48 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" "Chris M. Thomasson " <chris.m.thomasson.1@gmail.com> - 2019-09-09 01:09 -0700
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
| From | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| Date | 2019-08-28 16:11 -0500 |
| Subject | "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" |
| Message-ID | <qk6qmj$83p$1@dont-email.me> |
"“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" https://hub.packtpub.com/rust-is-the-future-of-systems-programming-c-is-the-new-assembly-intel-principal-engineer-josh-triplett/ "At Open Source Technology Summit (OSTS) 2019, Josh Triplett, a Principal Engineer at Intel gave an insight into what Intel is contributing to bring the most loved language, Rust to full parity with C. In his talk titled Intel and Rust: the Future of Systems Programming, he also spoke about the history of systems programming, how C became the “default” systems programming language, what features of Rust gives it an edge over C, and much more." Lynn
[toc] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2019-08-28 15:48 -0700 |
| Message-ID | <1f26f838-80a4-4551-8689-a6b5591b4c9d@googlegroups.com> |
| In reply to | #145830 |
On Thursday, August 29, 2019 at 12:12:00 AM UTC+3, Lynn McGuire wrote: > "“Rust is the future of systems programming, C is the new Assembly”: > Intel principal engineer, Josh Triplett" > > https://hub.packtpub.com/rust-is-the-future-of-systems-programming-c-is-the-new-assembly-intel-principal-engineer-josh-triplett/ > > "At Open Source Technology Summit (OSTS) 2019, Josh Triplett, a > Principal Engineer at Intel gave an insight into what Intel is > contributing to bring the most loved language, Rust to full parity with > C. In his talk titled Intel and Rust: the Future of Systems Programming, > he also spoke about the history of systems programming, how C became the > “default” systems programming language, what features of Rust gives it > an edge over C, and much more." > > Lynn IMHO, Rust is not going to be used widely. As Josh Triplett correctly mentioned "People care about usability and productivity". What he forgot to mention is that Rust has the worst productivity this side of TCL. No level of security excellence can save against such critical flow.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-08-29 00:20 +0100 |
| Message-ID | <a%D9F.95887$ir6.92819@fx16.am4> |
| In reply to | #145831 |
On 28/08/2019 23:48, already5chosen@yahoo.com wrote:
> On Thursday, August 29, 2019 at 12:12:00 AM UTC+3, Lynn McGuire wrote:
>> "“Rust is the future of systems programming, C is the new Assembly”:
>> Intel principal engineer, Josh Triplett"
>>
>> https://hub.packtpub.com/rust-is-the-future-of-systems-programming-c-is-the-new-assembly-intel-principal-engineer-josh-triplett/
>>
>> "At Open Source Technology Summit (OSTS) 2019, Josh Triplett, a
>> Principal Engineer at Intel gave an insight into what Intel is
>> contributing to bring the most loved language, Rust to full parity with
>> C. In his talk titled Intel and Rust: the Future of Systems Programming,
>> he also spoke about the history of systems programming, how C became the
>> “default” systems programming language, what features of Rust gives it
>> an edge over C, and much more."
>>
>> Lynn
>
> IMHO, Rust is not going to be used widely.
> As Josh Triplett correctly mentioned "People care about usability and productivity". What he forgot to mention is that Rust has the worst productivity this side of TCL. No level of security excellence can save against such critical flow.
I won't comment about the features of Rust. But at the start of this
year it was an entry in my set of simple compiler tests:
https://github.com/sal55/qx/blob/master/compilertest.txt, where Rust
performed very badly.
I've just tested again with the latest version (this on Windows), and if
anything it's worse:
100 lines of 'a=a+c*d;' (it now complains about 'a=b+c*d;') took 0.6
seconds, and 1000 lines was 27 seconds. Compilation time seems to be
proportional to N-squared (5000 lines took 12.5 minutes - a blistering 7
lines per second! The first column in my table for 20K lines would take
3 hours; the last column, 3 years.)
Avoiding variables, lines such as 'println!("Hello World!");' exhibited
more linear behaviour: 2 seconds for 1000 lines, and 25 seconds for
10,000 lines. Still pretty slow (the compilers I normally use have
speeds in the hundreds of thousands of lines per second).
Those speeds are unoptimised builds, otherwise rustc (the compiler)
would be even slower.
I've no idea what it's up to. But if considering productivity, this
could have a significant impact.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2019-09-01 17:31 -0500 |
| Message-ID | <qkhglt$n00$1@dont-email.me> |
| In reply to | #145831 |
already5chosen@yahoo.com wrote: <snip> > What he forgot to mention is that Rust has the worst productivity this side of TCL. Tcl is actually pretty productive. 10:1 with C for the right problem set -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2019-08-29 02:36 +0000 |
| Message-ID | <0TG9F.183628$vW4.72670@fx24.am4> |
| In reply to | #145830 |
On 2019-08-28, Lynn McGuire <lynnmcguire5@gmail.com> wrote: > "“Rust is the future of systems programming, C is the new Assembly”: > Intel principal engineer, Josh Triplett" > > https://hub.packtpub.com/rust-is-the-future-of-systems-programming-c-is-the-new-assembly-intel-principal-engineer-josh-triplett/ > > "At Open Source Technology Summit (OSTS) 2019, Josh Triplett, a > Principal Engineer at Intel gave an insight into what Intel is > contributing to bring the most loved language, Rust to full parity with > C. In his talk titled Intel and Rust: the Future of Systems Programming, > he also spoke about the history of systems programming, how C became the > “default” systems programming language, what features of Rust gives it > an edge over C, and much more." Rust is nowhere near C. Actually, nowhere near C++. It is nice language, but not for low level programming. During years they ditched GC and most of the things that cripples determinism and performance, it is ok, but without pointer arithmetic and null pointers it is high level language. Having to convert pointer to int and back in order to perform arithmetic is worse that doing it in assembler. But what Rust got it right is error handling, much better than excpetions. But not having inheritance and forbidding two mutable references to distinct array elements is stupid. Also no tail recursion optimisation and no way to disable array checks. > > Lynn > -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-29 11:02 +0200 |
| Message-ID | <qk84b7$80n$1@dont-email.me> |
| In reply to | #145834 |
On 29/08/2019 04:36, Melzzzzz wrote: > On 2019-08-28, Lynn McGuire <lynnmcguire5@gmail.com> wrote: >> "“Rust is the future of systems programming, C is the new Assembly”: >> Intel principal engineer, Josh Triplett" >> >> https://hub.packtpub.com/rust-is-the-future-of-systems-programming-c-is-the-new-assembly-intel-principal-engineer-josh-triplett/ >> >> "At Open Source Technology Summit (OSTS) 2019, Josh Triplett, a >> Principal Engineer at Intel gave an insight into what Intel is >> contributing to bring the most loved language, Rust to full parity with >> C. In his talk titled Intel and Rust: the Future of Systems Programming, >> he also spoke about the history of systems programming, how C became the >> “default” systems programming language, what features of Rust gives it >> an edge over C, and much more." > > Rust is nowhere near C. Actually, nowhere near C++. It is nice language, > but not for low level programming. During years they ditched GC and most > of the things that cripples determinism and performance, it is ok, but > without pointer arithmetic and null pointers it is high level language. > Having to convert pointer to int and back in order to perform arithmetic > is worse that doing it in assembler. That sounds terrible. (I am not very familiar with Rust.) > But what Rust got it right is error handling, much better than > excpetions. But not having inheritance and forbidding two mutable > references to distinct array elements is stupid. I have worked with a C-like language which had that many of that kind of restriction (XC for the XMOS microcontrollers, if anyone is curious). For a lot of code, it can be helpful - it allowed the compiler to find lots of situations that could be problematic, especially in heavily threaded and parallel code. But you invariably had situations where the restrictions were too much - you needed shared access, or whatever, in cases where you know they are safe. This typically lead to inline assembly code to get round the safety limitations imposed by the language and compiler - that was /not/ a good situation! > Also no tail recursion optimisation and no way to disable array checks. > Surely tail recursion optimisation is just a matter of the compiler? C and C++ don't have any mention of such optimisations in their standards, but a compiler can do it as long as the code works under the "as if" rule. Does the same not apply to Rust? As for array checks, again I would think a compiler could elide a fair number of them, reducing the cost of having them on all the time. One thing that I gather Rust does well, that C++ has trouble with, is that when you do the Rust equivalent of std::move'ing something, any attempt to use the moved-from object is flagged by the compiler. I think that would be good to spot in C++.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-08-29 22:21 +1200 |
| Message-ID | <gspn8jF75cdU1@mid.individual.net> |
| In reply to | #145835 |
On 29/08/2019 21:02, David Brown wrote: > > One thing that I gather Rust does well, that C++ has trouble with, is > that when you do the Rust equivalent of std::move'ing something, any > attempt to use the moved-from object is flagged by the compiler. I > think that would be good to spot in C++. clang-tidy does a pretty good job with "bugprone-use-after-move" <https://clang.llvm.org/extra/clang-tidy/checks/bugprone-use-after-move.html> -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-29 13:24 +0200 |
| Message-ID | <qk8cm5$mhr$1@dont-email.me> |
| In reply to | #145837 |
On 29/08/2019 12:21, Ian Collins wrote:
> On 29/08/2019 21:02, David Brown wrote:
>>
>> One thing that I gather Rust does well, that C++ has trouble with, is
>> that when you do the Rust equivalent of std::move'ing something, any
>> attempt to use the moved-from object is flagged by the compiler. I
>> think that would be good to spot in C++.
>
> clang-tidy does a pretty good job with "bugprone-use-after-move"
> <https://clang.llvm.org/extra/clang-tidy/checks/bugprone-use-after-move.html>
>
Yes, I saw that after googling a bit.
I would have thought, however, that pretty much any use (other than
assignment of some sort) of a named object after it is moved, is likely
to be a bug. And it is therefore something that could be warning about
by default.
#include <memory>
extern int a, b, c;
void foo(void) {
auto p = std::make_unique<int>(3);
a = *p;
auto q = std::move(p);
b = *q;
c = *p;
}
Both clang and gcc are smart enough to move the value 3 directly into
"a" and "b", and if the last line is omitted, they can remove the call
to "new" (at least in their trunk versions). Both are smart enough to
know that "c = *p;" is undefined behaviour here, and generate "ud2"
instructions on x86.
Yet neither compiler warns about this clearly wrong behaviour despite
-Wall -Wextra.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-08-29 13:29 -0700 |
| Message-ID | <lnd0gnyaug.fsf@kst-u.example.com> |
| In reply to | #145835 |
David Brown <david.brown@hesbynett.no> writes:
> On 29/08/2019 04:36, Melzzzzz wrote:
[...]
>> Rust is nowhere near C. Actually, nowhere near C++. It is nice language,
>> but not for low level programming. During years they ditched GC and most
>> of the things that cripples determinism and performance, it is ok, but
>> without pointer arithmetic and null pointers it is high level language.
>> Having to convert pointer to int and back in order to perform arithmetic
>> is worse that doing it in assembler.
>
> That sounds terrible. (I am not very familiar with Rust.)
What's terrible about it? Rust doesn't particularly need pointer
arithmetic; unlike C, it's array indexing isn't defined in terms of
pointers.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Mel <mel@zzzzz.com> |
|---|---|
| Date | 2019-08-30 08:04 +0200 |
| Message-ID | <almarsoft.1419227881502422743@news.albasani.net> |
| In reply to | #145845 |
On Thu, 29 Aug 2019 13:29:11 -0700, Keith Thompson <kst-u@mib.org> wrote: > David Brown <david.brown@hesbynett.no> writes: > > On 29/08/2019 04:36, Melzzzzz wrote: > [...] > >> Rust is nowhere near C. Actually, nowhere near C++. It is nice language, > >> but not for low level programming. During years they ditched GC and most > >> of the things that cripples determinism and performance, it is ok, but > >> without pointer arithmetic and null pointers it is high level language. > >> Having to convert pointer to int and back in order to perform arithmetic > >> is worse that doing it in assembler. > > > > That sounds terrible. (I am not very familiar with Rust.) > What's terrible about it? Rust doesn't particularly need pointer > arithmetic; unlike C, it's array indexing isn't defined in terms of > pointers. You need pointers for low level things. In rust you need unsafe blocks for almost anything. -- Press any key to continue or any other to quit
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-08-29 23:11 -0700 |
| Message-ID | <ln8srbxjvh.fsf@kst-u.example.com> |
| In reply to | #145847 |
Mel <mel@zzzzz.com> writes:
> On Thu, 29 Aug 2019 13:29:11 -0700, Keith Thompson <kst-u@mib.org>
> wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> > On 29/08/2019 04:36, Melzzzzz wrote:
>> [...]
>> >> Rust is nowhere near C. Actually, nowhere near C++. It is nice
>> >> language, but not for low level programming. During years they
>> >> ditched GC and most of the things that cripples determinism and
>> >> performance, it is ok, but without pointer arithmetic and null
>> >> pointers it is high level language. Having to convert pointer to
>> >> int and back in order to perform arithmetic is worse that doing it
>> >> in assembler.
>> >
>> > That sounds terrible. (I am not very familiar with Rust.)
>
>> What's terrible about it? Rust doesn't particularly need pointer
>> arithmetic; unlike C, it's array indexing isn't defined in terms of
>> pointers.
>
> You need pointers for low level things.
You need pointer *arithmetic* for far fewer things than you need
pointers for.
> In rust you need unsafe
> blocks for almost anything.
So use unsafe blocks.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-30 10:14 +0200 |
| Message-ID | <qkalta$vtf$1@dont-email.me> |
| In reply to | #145845 |
On 29/08/2019 22:29, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 29/08/2019 04:36, Melzzzzz wrote: > [...] >>> Rust is nowhere near C. Actually, nowhere near C++. It is nice language, >>> but not for low level programming. During years they ditched GC and most >>> of the things that cripples determinism and performance, it is ok, but >>> without pointer arithmetic and null pointers it is high level language. >>> Having to convert pointer to int and back in order to perform arithmetic >>> is worse that doing it in assembler. >> >> That sounds terrible. (I am not very familiar with Rust.) > > What's terrible about it? Rust doesn't particularly need pointer > arithmetic; unlike C, it's array indexing isn't defined in terms of > pointers. > (Again, let me note that I know little about Rust - I've read some stuff, but never used it. So if I get things wrong about it, I hope to be corrected.) As you say in your other post, pointer arithmetic isn't actually used that much in C or C++, once you discount array access and iterators which would be handled in a more "high level" manner in a non-C language. But sometimes - even if it is only occasionally - it /is/ useful. This can be especially true in low-level and systems code, which apparently is a target for Rust. The whole idea of Rust is to be "safer" than C - it aims to turn logical errors such as misuse of pointers, confusion about owners, etc., into compiler errors. That is a great ambition. But to work properly, you have to follow the rules - workarounds that go outside those rules should be as limited as possible, and strongly discouraged if they can't be blocked by tools. The language seems to be saying "We guarantee your code will avoid null pointer dereferences, buffer overflows, use after free, memory leaks, and all the pointer-related problems that plague C programmers." So far, so good. Then it says "We realise that is too limiting sometimes, so here are the ways to cheat, hack, and mess about under the hood". Your guarantees are out the window, and you are back to /exactly/ the same situation as you have in C - design carefully, code carefully to keep your code safe, because the language and tools won't do it for you. So it is not so much the idea of doing pointer arithmetic manually as integer arithmetic that concerns me (though it might be a step lower level than C's pointer arithmetic). It is the idea that the language allows it and that it is considered an acceptable solution that bothers me.
[toc] | [prev] | [next] | [standalone]
| From | Mel <mel@zzzzz.com> |
|---|---|
| Date | 2019-08-30 07:42 +0200 |
| Message-ID | <almarsoft.2889963994277620868@news.albasani.net> |
| In reply to | #145835 |
On Thu, 29 Aug 2019 11:02:30 +0200, David Brown <david.brown@hesbynett.no> wrote: > One thing that I gather Rust does well, that C++ has trouble with, is > that when you do the Rust equivalent of std::move'ing something, any > attempt to use the moved-from object is flagged by the compiler. I > think that would be good to spot in C++. Rust move is built into language. Moved objects destructor is not called. -- Press any key to continue or any other to quit
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-29 14:54 +0200 |
| Message-ID | <qk8htr$ua3$2@news.albasani.net> |
| In reply to | #145834 |
> Rust is nowhere near C. Actually, nowhere near C++. It is nice language, > but not for low level programming. During years they ditched GC and most > of the things that cripples determinism and performance, ... Rust has no GC, but works with counted references.
[toc] | [prev] | [next] | [standalone]
| From | Mel <mel@zzzzz.com> |
|---|---|
| Date | 2019-08-30 08:07 +0200 |
| Message-ID | <almarsoft.954647121221868192@news.albasani.net> |
| In reply to | #145840 |
On Thu, 29 Aug 2019 14:54:18 +0200, Bonita Montero <Bonita.Montero@gmail.com> wrote: > > Rust is nowhere near C. Actually, nowhere near C++. It is nice language, > > but not for low level programming. During years they ditched GC and most > > of the things that cripples determinism and performance, ... > Rust has no GC, but works with counted references. Yes, but it is not much used. Box, owned reference is built in, i zhink that rc is not built in -- Press any key to continue or any other to quit
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2019-08-29 05:14 -0500 |
| Message-ID | <qk88hr$uju$1@dont-email.me> |
| In reply to | #145830 |
On 8/28/2019 4:11 PM, Lynn McGuire wrote: > "“Rust is the future of systems programming, C is the new Assembly”: > Intel principal engineer, Josh Triplett" > > https://hub.packtpub.com/rust-is-the-future-of-systems-programming-c-is-the-new-assembly-intel-principal-engineer-josh-triplett/ > > > "At Open Source Technology Summit (OSTS) 2019, Josh Triplett, a > Principal Engineer at Intel gave an insight into what Intel is > contributing to bring the most loved language, Rust to full parity with > C. In his talk titled Intel and Rust: the Future of Systems Programming, > he also spoke about the history of systems programming, how C became the > “default” systems programming language, what features of Rust gives it > an edge over C, and much more." > How about, instead: We take C; We add some features to support things like bounds-checked arrays and similar; We mostly call it done. Many past variants of bounds-checked arrays did funky things with the syntax, which is a problem if one wants to be able to make it work in a compiler without support for this feature (eg: via non-convoluted use of defines). My thought is, say: _BoundsCheck int *arr; Which behaves sorta like "int[] arr;" in Java or similar. Then it is given a shorthand in a header (eg: bounded), which becomes no-op if the compiler doesn't support it. Otherwise, it behaves mostly like a normal pointer, apart from potential runtime bounds checking, and a different internal representation. May decay into a normal pointer, potentially with a warning. While at it, something like a standardized header for accessing misaligned and explicit endianess values would be nice. eg: uint32_t getuint32le(void *ptr); void setint32le(void *ptr, int32_t val); ... Where: le: little endian, be: big endian, no suffix: native endian. And, these functions work regardless of alignment. This being semi-common boilerplate one either needs to copy around or reimplement fairly often (and for which the optimal way to do these varies between compilers; and with some dependence on target architecture). > Lynn >
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-08-29 15:00 +0100 |
| Message-ID | <sUQ9F.51380$qd4.29457@fx17.am4> |
| In reply to | #145836 |
On 29/08/2019 11:14, BGB wrote:
> On 8/28/2019 4:11 PM, Lynn McGuire wrote:
>> "“Rust is the future of systems programming, C is the new Assembly”:
>> Intel principal engineer, Josh Triplett"
>>
>> https://hub.packtpub.com/rust-is-the-future-of-systems-programming-c-is-the-new-assembly-intel-principal-engineer-josh-triplett/
>>
>>
>> "At Open Source Technology Summit (OSTS) 2019, Josh Triplett, a
>> Principal Engineer at Intel gave an insight into what Intel is
>> contributing to bring the most loved language, Rust to full parity
>> with C. In his talk titled Intel and Rust: the Future of Systems
>> Programming, he also spoke about the history of systems programming,
>> how C became the “default” systems programming language, what features
>> of Rust gives it an edge over C, and much more."
>>
>
> How about, instead:
> We take C;
> We add some features to support things like bounds-checked arrays and
> similar;
> We mostly call it done.
>
>
> Many past variants of bounds-checked arrays did funky things with the
> syntax, which is a problem if one wants to be able to make it work in a
> compiler without support for this feature (eg: via non-convoluted use of
> defines).
>
> My thought is, say:
> _BoundsCheck int *arr;
> Which behaves sorta like "int[] arr;" in Java or similar.
C doesn't properly have arrays, at least not how they are mostly coded
which are as T* rather than as (T*)[].
Using idioms such as int* to declare dynamic arrays or to pass arrays is
too widespread; people will not suddenly start writing '_BoundsCheck
int*. And it will cause tremendous problems trying to use libraries that
still use int*, but you want to pass it _Boundscheck int*, or vice versa
if you create a library that needs a _Boundscheck attribute.
So doing this in a newer language with less existing code and fewer
ingrained bad habits is better.
My own language, while still simple, has a somewhat better treatment of
arrays than C, which fall into three kinds:
[N]T A # T A[N] in C
slice[]T B # Similar to struct{T* P; size_t N;} B in C
ref[]T C # T (*C)[] in C (I think)
A has bounds known at compile-time; B at run-time, while C accesses are
unchecked. There are some conversions between them.
There are still raw pointers that also allow offset dereferences, but
mostly at a lower level of coding than arrays (eg. blocks):
ref T P # T* P in C
No indexing, such as P[i], is possible as in C. And this is not the
primary way of dealing with dynamic arrays and parameter passing as it
is in C.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2019-08-29 10:39 -0500 |
| Message-ID | <qk8rkb$hl5$1@dont-email.me> |
| In reply to | #145843 |
On 8/29/2019 9:00 AM, Bart wrote:
> On 29/08/2019 11:14, BGB wrote:
>> On 8/28/2019 4:11 PM, Lynn McGuire wrote:
>>> "“Rust is the future of systems programming, C is the new Assembly”:
>>> Intel principal engineer, Josh Triplett"
>>>
>>> https://hub.packtpub.com/rust-is-the-future-of-systems-programming-c-is-the-new-assembly-intel-principal-engineer-josh-triplett/
>>>
>>>
>>> "At Open Source Technology Summit (OSTS) 2019, Josh Triplett, a
>>> Principal Engineer at Intel gave an insight into what Intel is
>>> contributing to bring the most loved language, Rust to full parity
>>> with C. In his talk titled Intel and Rust: the Future of Systems
>>> Programming, he also spoke about the history of systems programming,
>>> how C became the “default” systems programming language, what
>>> features of Rust gives it an edge over C, and much more."
>>>
>>
>> How about, instead:
>> We take C;
>> We add some features to support things like bounds-checked arrays and
>> similar;
>> We mostly call it done.
>>
>>
>> Many past variants of bounds-checked arrays did funky things with the
>> syntax, which is a problem if one wants to be able to make it work in
>> a compiler without support for this feature (eg: via non-convoluted
>> use of defines).
>>
>> My thought is, say:
>> _BoundsCheck int *arr;
>> Which behaves sorta like "int[] arr;" in Java or similar.
>
> C doesn't properly have arrays, at least not how they are mostly coded
> which are as T* rather than as (T*)[].
>
> Using idioms such as int* to declare dynamic arrays or to pass arrays is
> too widespread; people will not suddenly start writing '_BoundsCheck
> int*. And it will cause tremendous problems trying to use libraries that
> still use int*, but you want to pass it _Boundscheck int*, or vice versa
> if you create a library that needs a _Boundscheck attribute.
>
Forcing people to use new features is "not the C way".
More so, wouldn't want to enforce something like this everywhere, as it
would come with a potentially significant performance overhead. For
cases where one cares about security, it makes some sense.
My idea here is:
_BoundsCheck arrays behave mostly like a normal / bare pointer, apart
from the bounds-checking part;
They can decay into bare pointers;
Casting a bare pointer to a bounds-checked pointer produces an
"unbounded pointer" (can point anywhere, with bounds-checking disabled).
But, this was mostly intended as an alternative to notations like "int
arr[*];" or "int ^arr;" or similar, which while more concise, violate
the rule of "extensions should be able to cleanly decay into a standard
C fallback whenever possible".
Or, IOW, one does something like:
#ifndef _HAS_BOUNDSCHECK
#define _BoundsCheck
#endif
And, suddenly, it still works on compilers without support for this
feature, apart from the loss of bounds-checking.
> So doing this in a newer language with less existing code and fewer
> ingrained bad habits is better.
>
I disagree in that, the time/effort/... to move everything over to a new
language, is a lot higher than "just using C with a few
compiler-specific extensions".
Moving to a new language requires effectively rewriting the existing
code, whereas extensions can be used when they are needed and/or
convenient (and, if designed well, without the "extension doesn't exist"
fallback cases needing a small mountain of ifdef's).
Granted, one could also do the syntax like
"__attribute__((bounds_checking))", or "__declspec(boundscheck)", but
the distinction doesn't matter too much in this case.
> My own language, while still simple, has a somewhat better treatment of
> arrays than C, which fall into three kinds:
>
> [N]T A # T A[N] in C
> slice[]T B # Similar to struct{T* P; size_t N;} B in C
> ref[]T C # T (*C)[] in C (I think)
>
> A has bounds known at compile-time; B at run-time, while C accesses are
> unchecked. There are some conversions between them.
>
> There are still raw pointers that also allow offset dereferences, but
> mostly at a lower level of coding than arrays (eg. blocks):
>
> ref T P # T* P in C
>
> No indexing, such as P[i], is possible as in C. And this is not the
> primary way of dealing with dynamic arrays and parameter passing as it
> is in C.
>
I also have my BS2 language, which does:
int[16] arr1; //array, fixed size
int[] arr2; //reference to array, runtime checks
*int ptr1; //bare pointer, base type is a pointer
int *ptr2; //bare pointer, variable is a pointer
So far, even for my own uses, its use has been fairly limited.
Using it still comes with a non-zero cost; even, in my case, with both
languages being supported by the same compiler, using the same backend,
and with the cross-language interfacing being mostly transparent at the
ABI level.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2019-08-30 04:24 -0700 |
| Message-ID | <8186a651-209b-4110-84e2-c918f6e5879a@googlegroups.com> |
| In reply to | #145836 |
On Thursday, August 29, 2019 at 7:14:28 AM UTC-3, BGB wrote:
> On 8/28/2019 4:11 PM, Lynn McGuire wrote:
> > "“Rust is the future of systems programming, C is the new Assembly”:
> > Intel principal engineer, Josh Triplett"
> >
> > https://hub.packtpub.com/rust-is-the-future-of-systems-programming-c-is-the-new-assembly-intel-principal-engineer-josh-triplett/
> >
> >
> > "At Open Source Technology Summit (OSTS) 2019, Josh Triplett, a
> > Principal Engineer at Intel gave an insight into what Intel is
> > contributing to bring the most loved language, Rust to full parity with
> > C. In his talk titled Intel and Rust: the Future of Systems Programming,
> > he also spoke about the history of systems programming, how C became the
> > “default” systems programming language, what features of Rust gives it
> > an edge over C, and much more."
> >
>
> How about, instead:
> We take C;
> We add some features to support things like bounds-checked arrays and
> similar;
> We mostly call it done.
Exactly.
Some syntax is already present in C with variability types.
void F(int n, int m, int a[n][m])
{
//compiler knows bounds of a
...
}
int n = 2;
int m = 3;
int (*p)[n][m] = malloc(sizeof * p);
//compiler knows bounds of p
The problem I see with the existing syntax is:
int (*)[n][m] Alloc(int n, int m);
How do I specify return types?
The fix could be something like a concept of closest
context.
Then
int (*)[n][m] Alloc(int n, int m);
n and m refers to the arguments.
The same could be applied here if the order is changed:
void F(int a[n][m], int n, int m);
and I would like to see this syntax applied to struct members.
struct X
{
int *[Size] pData;
int Size;
};
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-08-30 20:52 +0100 |
| Message-ID | <f8faF.127979$hJ3.25916@fx07.am4> |
| In reply to | #145864 |
On 30/08/2019 12:24, Thiago Adams wrote:
> On Thursday, August 29, 2019 at 7:14:28 AM UTC-3, BGB wrote:
>> How about, instead:
>> We take C;
>> We add some features to support things like bounds-checked arrays and
>> similar;
>> We mostly call it done.
>
>
> Exactly.
>
> Some syntax is already present in C with variability types.
>
> void F(int n, int m, int a[n][m])
> {
> //compiler knows bounds of a
This is a mechanism to be able to pass multi-dimensional flat (single
linear block) arrays, and make it possible for them to be indexed.
(Although the first dimension is not necessary for that, only
subsequence ones.)
It depends on the caller providing correct information, so that nothing
stops you doing this:
F(rand(), rand(), A);
or just: F(m,n,A) instead of F(n,m,A).
So, it's not quite as good as bounds which are properly known to the
language without relying on the correctness of the code.
[toc] | [prev] | [next] | [standalone]
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web