Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #383248 > unrolled thread
| Started by | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| First post | 2024-03-02 17:13 -0600 |
| Last post | 2024-03-12 16:00 -0300 |
| Articles | 20 on this page of 237 — 35 participants |
Back to article view | Back to comp.lang.c
"White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lynn McGuire <lynnmcguire5@gmail.com> - 2024-03-02 17:13 -0600
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-03 00:05 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-03 13:42 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" John McCue <jmccue@neutron.jmcunx.com> - 2024-03-03 02:10 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-03 02:23 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-03 11:11 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-03 03:30 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-03-03 08:54 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-03 20:11 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-03 13:49 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-03-03 22:11 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-03 23:27 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-03-07 06:46 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-03-03 08:52 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Michael S <already5chosen@yahoo.com> - 2024-03-03 11:10 +0200
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" David Brown <david.brown@hesbynett.no> - 2024-03-03 12:01 +0100
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-03 16:03 +0100
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-03 18:18 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" David Brown <david.brown@hesbynett.no> - 2024-03-03 21:23 +0100
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-03 14:01 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" David Brown <david.brown@hesbynett.no> - 2024-03-04 09:44 +0100
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-04 11:38 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-04 12:46 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-04 12:36 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-04 12:41 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" David Brown <david.brown@hesbynett.no> - 2024-03-05 10:01 +0100
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-05 12:51 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" David Brown <david.brown@hesbynett.no> - 2024-03-06 11:43 +0100
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-06 14:18 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-08 13:23 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" David Brown <david.brown@hesbynett.no> - 2024-03-09 13:25 +0100
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-09 14:16 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-09 14:18 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-03 23:31 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-04 17:05 +0100
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" David Brown <david.brown@hesbynett.no> - 2024-03-04 18:24 +0100
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-05 02:46 +0100
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" David Brown <david.brown@hesbynett.no> - 2024-03-05 11:23 +0100
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-03 20:10 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-03 14:06 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-03 23:29 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-03 15:53 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" bart <bc@freeuk.com> - 2024-03-04 01:00 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-04 11:44 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-04 21:07 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Michael S <already5chosen@yahoo.com> - 2024-03-05 00:59 +0200
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-05 01:54 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-04 22:18 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-05 07:06 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-04 23:10 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Michael S <already5chosen@yahoo.com> - 2024-03-05 11:11 +0200
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-05 22:58 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Michael S <already5chosen@yahoo.com> - 2024-03-06 14:02 +0200
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" bart <bc@freeuk.com> - 2024-03-06 12:28 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Michael S <already5chosen@yahoo.com> - 2024-03-07 00:00 +0200
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" David Brown <david.brown@hesbynett.no> - 2024-03-07 11:35 +0100
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Michael S <already5chosen@yahoo.com> - 2024-03-07 13:44 +0200
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" David Brown <david.brown@hesbynett.no> - 2024-03-07 16:36 +0100
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-07 17:18 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Paavo Helde <eesnimi@osa.pri.ee> - 2024-03-08 14:41 +0200
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" David Brown <david.brown@hesbynett.no> - 2024-03-08 15:07 +0100
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" bart <bc@freeuk.com> - 2024-03-08 15:15 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" David Brown <david.brown@hesbynett.no> - 2024-03-08 17:55 +0100
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-03-08 10:08 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-04-29 00:05 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-28 17:14 -0700
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Kaz Kylheku <643-408-1753@kylheku.com> - 2024-04-29 01:58 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-28 19:01 -0700
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Kaz Kylheku <643-408-1753@kylheku.com> - 2024-04-29 04:28 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-29 13:40 -0700
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" paavo512 <paavo@osa.pri.ee> - 2024-04-29 12:45 +0300
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-29 13:42 -0700
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" scott@slp53.sl.home (Scott Lurndal) - 2024-04-30 16:46 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-07 16:35 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" David Brown <david.brown@hesbynett.no> - 2024-03-08 08:25 +0100
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Michael S <already5chosen@yahoo.com> - 2024-03-08 12:57 +0200
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" David Brown <david.brown@hesbynett.no> - 2024-03-08 15:32 +0100
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Michael S <already5chosen@yahoo.com> - 2024-03-08 16:57 +0200
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-04-29 00:02 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" aph@littlepinkcloud.invalid - 2024-04-29 08:55 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-07 01:45 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" aph@littlepinkcloud.invalid - 2024-03-06 14:30 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-07 01:46 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-06 18:00 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-07 02:37 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-06 20:36 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-07 01:44 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-14 15:39 -0700
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" gazelle@shell.xmission.com (Kenny McCormack) - 2024-03-04 00:44 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-04 12:57 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-03 13:48 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" scott@slp53.sl.home (Scott Lurndal) - 2024-03-03 15:31 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lynn McGuire <lynnmcguire5@gmail.com> - 2024-03-05 00:09 -0600
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-05 07:07 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" scott@slp53.sl.home (Scott Lurndal) - 2024-03-05 14:56 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-03-03 22:14 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-03 14:15 -0800
[OT] UTF-8 sig. Was: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-03-04 16:39 +0000
Re: [OT] UTF-8 sig. Was: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" scott@slp53.sl.home (Scott Lurndal) - 2024-03-04 17:21 +0000
Re: [OT] UTF-8 sig. Was: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-03-07 06:48 +0000
Re: [OT] UTF-8 sig. Was: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-06 23:01 -0800
Re: [OT] UTF-8 sig. Was: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-03-07 08:15 +0000
Re: [OT] UTF-8 sig. Was: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-07 08:23 +0000
Re: [OT] UTF-8 sig. Was: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Richard Harnden <richard.nospam@gmail.invalid> - 2024-03-07 10:20 +0000
Re: [OT] UTF-8 sig. Was: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-03-09 06:23 +0000
Re: [OT] UTF-8 sig. Was: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-03-09 06:21 +0000
Re: [OT] UTF-8 sig. Was: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" scott@slp53.sl.home (Scott Lurndal) - 2024-03-07 14:34 +0000
Re: [OT] UTF-8 sig. Was: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-07 07:58 -0800
Re: [OT] UTF-8 sig. Was: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" gazelle@shell.xmission.com (Kenny McCormack) - 2024-03-07 18:09 +0000
Re: [OT] UTF-8 sig. Was: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-07 14:39 -0500
Re: [OT] UTF-8 sig. Was: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Ben <ben.usenet@bsb.me.uk> - 2024-03-07 11:23 +0000
Re: [OT] UTF-8 sig. Was: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-03-09 06:27 +0000
Re: [OT] UTF-8 sig. Was: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-08 23:27 -0800
Re: [OT] UTF-8 sig. Was: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-03-09 12:21 +0000
Re: [OT] UTF-8 sig. vallor <vallor@cultnix.org> - 2024-03-09 15:02 +0000
Re: [OT] UTF-8 sig. Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-03-09 23:11 +0000
Re: [OT] UTF-8 sig. Anton Shepelev <anton.txt@gmail.moc> - 2024-03-21 14:47 +0300
Re: [OT] UTF-8 sig. Ben <ben.usenet@bsb.me.uk> - 2024-03-09 10:40 +0000
Re: [OT] UTF-8 sig. Richard Harnden <richard.nospam@gmail.invalid> - 2024-03-09 11:56 +0000
Re: [OT] UTF-8 sig. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-03-10 14:03 +0000
Re: [OT] UTF-8 sig. Richard Harnden <richard.nospam@gmail.invalid> - 2024-03-10 19:07 +0000
Re: [OT] UTF-8 sig. Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-03-09 12:25 +0000
Re: [OT] UTF-8 sig. Richard Harnden <richard.nospam@gmail.invalid> - 2024-03-09 13:11 +0000
Re: [OT] UTF-8 sig. Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-03-09 23:13 +0000
Re: [OT] UTF-8 sig. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-03-10 00:13 +0000
Re: [OT] UTF-8 sig. Michael S <already5chosen@yahoo.com> - 2024-03-10 10:17 +0200
Re: [OT] UTF-8 sig. Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-03-10 13:35 +0000
Re: [OT] UTF-8 sig. Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-10 17:15 +0000
avoiding strdup() (was: Re: [OT] UTF-8 sig.) vallor <vallor@cultnix.org> - 2024-03-09 13:19 +0000
Re: avoiding strdup() Spiros Bousbouras <spibou@gmail.com> - 2024-03-09 15:25 +0000
Re: avoiding strdup() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-09 16:37 -0800
Re: avoiding strdup() Michael S <already5chosen@yahoo.com> - 2024-03-10 10:11 +0200
Re: avoiding strdup() Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-03-10 13:38 +0000
Re: avoiding strdup() Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-10 17:12 +0000
Re: avoiding strdup() scott@slp53.sl.home (Scott Lurndal) - 2024-03-10 18:47 +0000
Re: avoiding strdup() Richard Harnden <richard.nospam@gmail.invalid> - 2024-03-10 19:20 +0000
Re: avoiding strdup() Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-11 16:23 +0000
Re: avoiding strdup() Michael S <already5chosen@yahoo.com> - 2024-03-11 18:50 +0200
Re: avoiding strdup() scott@slp53.sl.home (Scott Lurndal) - 2024-03-11 17:05 +0000
Re: avoiding strdup() Michael S <already5chosen@yahoo.com> - 2024-03-11 19:35 +0200
Re: avoiding strdup() scott@slp53.sl.home (Scott Lurndal) - 2024-03-11 18:06 +0000
Re: avoiding strdup() Michael S <already5chosen@yahoo.com> - 2024-03-11 20:29 +0200
Re: avoiding strdup() Spiros Bousbouras <spibou@gmail.com> - 2024-03-11 19:57 +0000
Re: avoiding strdup() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-11 10:13 -0700
Re: avoiding strdup() Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-11 17:58 +0000
Re: avoiding strdup() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-11 11:28 -0700
Re: avoiding strdup() scott@slp53.sl.home (Scott Lurndal) - 2024-03-11 17:58 +0000
Re: avoiding strdup() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-11 11:30 -0700
Re: avoiding strdup() Spiros Bousbouras <spibou@gmail.com> - 2024-03-11 19:45 +0000
Re: avoiding strdup() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-11 13:11 -0700
Re: avoiding strdup() scott@slp53.sl.home (Scott Lurndal) - 2024-03-11 17:00 +0000
Re: avoiding strdup() Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-11 17:52 +0000
Re: avoiding strdup() scott@slp53.sl.home (Scott Lurndal) - 2024-03-11 18:10 +0000
Re: avoiding strdup() Richard Kettlewell <invalid@invalid.invalid> - 2024-03-11 19:11 +0000
Re: avoiding strdup() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-11 12:34 -0700
Re: avoiding strdup() Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-12 01:12 +0000
Re: avoiding strdup() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-11 18:20 -0700
Re: avoiding strdup() Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-12 15:40 +0000
Re: avoiding strdup() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-12 15:31 -0700
Re: avoiding strdup() Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-13 09:50 +0000
Re: avoiding strdup() scott@slp53.sl.home (Scott Lurndal) - 2024-03-12 15:55 +0000
Re: avoiding strdup() Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-12 22:44 +0000
Re: avoiding strdup() scott@slp53.sl.home (Scott Lurndal) - 2024-03-12 23:50 +0000
Re: avoiding strdup() James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-13 03:46 -0400
Re: avoiding strdup() David Brown <david.brown@hesbynett.no> - 2024-03-13 16:08 +0100
Re: avoiding strdup() Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-04-29 00:53 +0000
Re: avoiding strdup() i@fuzy.me - 2024-04-29 22:38 +0800
Re: avoiding strdup() steve <sgonedes1977@gmail.com> - 2024-04-30 23:36 -0400
Re: avoiding strdup() Richard Harnden <richard.nospam@gmail.invalid> - 2024-03-10 10:02 +0000
Re: [OT] UTF-8 sig. Was: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" yeti <yeti@tilde.institute> - 2024-03-07 17:52 +0042
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lynn McGuire <lynnmcguire5@gmail.com> - 2024-03-05 00:02 -0600
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" David LaRue <huey.dll@tampabay.rr.com> - 2024-03-03 23:59 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-03 16:06 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-04 05:43 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-04 13:15 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-04 21:26 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-04 13:28 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-04 13:29 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-05 02:46 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-04 19:40 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-05 04:43 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-04 21:23 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-05 07:07 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-05 13:48 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-06 00:25 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-05 22:01 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-07 23:42 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-07 16:21 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-05 03:32 +0100
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-04 19:42 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lynn McGuire <lynnmcguire5@gmail.com> - 2024-03-05 00:03 -0600
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-05 07:08 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" David Brown <david.brown@hesbynett.no> - 2024-03-05 11:27 +0100
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-05 13:01 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-05 21:24 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-05 13:44 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-05 14:11 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-05 14:34 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" David Brown <david.brown@hesbynett.no> - 2024-03-06 14:31 +0100
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" bart <bc@freeuk.com> - 2024-03-06 13:50 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Michael S <already5chosen@yahoo.com> - 2024-03-06 16:18 +0200
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" bart <bc@freeuk.com> - 2024-03-06 14:38 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" bart <bc@freeuk.com> - 2024-03-06 19:46 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" scott@slp53.sl.home (Scott Lurndal) - 2024-03-06 19:50 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-06 14:14 -0500
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-06 19:50 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" David Brown <david.brown@hesbynett.no> - 2024-03-06 21:13 +0100
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-03-08 21:36 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-12 00:07 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-03-11 20:05 -0700
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-06 19:27 -0500
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-07 03:06 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-07 14:28 -0500
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-07 23:44 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-06 07:42 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-06 14:14 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-05 13:58 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-05 14:02 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" David Brown <david.brown@hesbynett.no> - 2024-03-06 14:34 +0100
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-06 14:13 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-07 23:43 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" David Brown <david.brown@hesbynett.no> - 2024-03-08 09:01 +0100
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-12 00:03 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-04 11:54 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" David Brown <david.brown@hesbynett.no> - 2024-03-04 15:41 +0100
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" scott@slp53.sl.home (Scott Lurndal) - 2024-03-04 15:28 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-04 18:51 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-04 21:11 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" David Brown <david.brown@hesbynett.no> - 2024-03-05 11:31 +0100
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-06 00:25 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" David Brown <david.brown@hesbynett.no> - 2024-03-06 14:40 +0100
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Derek <derek-nospam@shape-of-code.com> - 2024-03-04 12:18 +0000
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-04 12:52 -0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2024-03-05 21:51 +0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2024-03-06 15:43 +0800
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Thiago Adams <thiago.adams@gmail.com> - 2024-03-12 15:54 -0300
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Thiago Adams <thiago.adams@gmail.com> - 2024-03-12 16:00 -0300
Page 1 of 12 [1] 2 3 … 12 Next page →
| From | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| Date | 2024-03-02 17:13 -0600 |
| Subject | "White House to Developers: Using C or C++ Invites Cybersecurity Risks" |
| Message-ID | <us0brl$246bf$1@dont-email.me> |
"White House to Developers: Using C or C++ Invites Cybersecurity Risks" https://www.pcmag.com/news/white-house-to-developers-using-c-plus-plus-invites-cybersecurity-risks "The Biden administration backs a switch to more memory-safe programming languages. The tech industry sees their point, but it won't be easy." No. The feddies want to regulate software development very much. They have been talking about it for at least 20 years now. This is a very bad thing. Lynn
[toc] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-03-03 00:05 +0000 |
| Message-ID | <us0es8$24khf$4@dont-email.me> |
| In reply to | #383248 |
On Sat, 2 Mar 2024 17:13:56 -0600, Lynn McGuire wrote: > The feddies want to regulate software development very much. Given the high occurrence of embarrassing mistakes companies have been making with their code, and continue to make, it’s quite clear they’re not capable of regulating this issue themselves. I wouldn’t worry about companies tripping over and hurting themselves, but when the consequences are security leaks, not of information belonging to those companies, but to their innocent customers/users who are often unaware that those companies even had that information, then it’s quite clear that Government has to step in. Because if they don’t, then who will?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-03-03 13:42 -0800 |
| Message-ID | <us2qrf$2n6hm$1@dont-email.me> |
| In reply to | #383249 |
On 3/2/2024 4:05 PM, Lawrence D'Oliveiro wrote: > On Sat, 2 Mar 2024 17:13:56 -0600, Lynn McGuire wrote: > >> The feddies want to regulate software development very much. > > Given the high occurrence of embarrassing mistakes companies have been > making with their code, and continue to make, it’s quite clear they’re not > capable of regulating this issue themselves. Oh my. C/C++ compilers are banned world wide. They even have reeducation camps that they will confine you to. You know, to learn the one true way... If you make a bug using the one true way, you risk a firing squad? lol. ;^) > > I wouldn’t worry about companies tripping over and hurting themselves, but > when the consequences are security leaks, not of information belonging to > those companies, but to their innocent customers/users who are often > unaware that those companies even had that information, then it’s quite > clear that Government has to step in. > > Because if they don’t, then who will? lol.
[toc] | [prev] | [next] | [standalone]
| From | John McCue <jmccue@neutron.jmcunx.com> |
|---|---|
| Date | 2024-03-03 02:10 +0000 |
| Message-ID | <us0m5r$25tj3$1@dont-email.me> |
| In reply to | #383248 |
trimmed followups to comp.lang.c
In comp.lang.c Lynn McGuire <lynnmcguire5@gmail.com> wrote:
<snip>
>
> "The Biden administration backs a switch to more memory-safe programming
> languages. The tech industry sees their point, but it won't be easy."
>
> No. The feddies want to regulate software development very much. They
> have been talking about it for at least 20 years now. This is a very
> bad thing.
Well to be fair, the feds regulations in the 60s made COBOL and
FORTRAN very popular, plus POSIX later on. All they did was
say "we will not buy anything unless ... rules".
From "The C Programming Language Quotes by Brian W. Kernighan".
> Nevertheless, C retains the basic philosophy that
> programmers know what they are doing; it only requires
> that they state their intentions explicitly.
If programmers were given time to test and develop, many
issues would not exist. Anyone who has ever worked for a
large company knows the pressure that exists to get things
done quickly instead of right. So all these issues I blame
on management.
How many times have we heard "ship it now, you can fix later"
and "later" never comes. :)
Rust will never fix policy issues, just different and maybe worst
issues will happen.
> Lynn
--
[t]csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-03-03 02:23 +0000 |
| Message-ID | <20240302181317.269@kylheku.com> |
| In reply to | #383250 |
On 2024-03-03, John McCue <jmccue@neutron.jmcunx.com> wrote: >> Nevertheless, C retains the basic philosophy that >> programmers know what they are doing; it only requires >> that they state their intentions explicitly. fflush(stdin); // my explicit intention is to discard unread input A lot of what programmers intend is nonportable or undefined, without their nowledge. Pretty much all imperative languages require that programmer state their intentions explicitly. PL/I, Algol, Modula, ... You can't, for instance, just declare some facts and write a query against them. All languages have implicit behaviors. For instance in C you can write x + y, without having to express a detailed intention about what happens with every bit. It's a tautology that you have to be explicit about declaring your intent using the documented knobs and levers that are available, using the semantics of the paradigm they control, while not being able declare intent about the inner mechanism that underlies them. Using any language whatsoever.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-03-03 11:11 -0800 |
| Message-ID | <86v863rv00.fsf@linuxsc.com> |
| In reply to | #383251 |
Kaz Kylheku <433-929-6894@kylheku.com> writes: > On 2024-03-03, John McCue <jmccue@neutron.jmcunx.com> wrote: > >>> Nevertheless, C retains the basic philosophy that >>> programmers know what they are doing; it only requires >>> that they state their intentions explicitly. > > fflush(stdin); // my explicit intention is to discard unread input > > A lot of what programmers intend is nonportable or undefined, > without their nowledge. > > Pretty much all imperative languages require that programmer > state their intentions explicitly. PL/I, Algol, Modula, ... > > You can't, for instance, just declare some facts and write a query > against them. > > All languages have implicit behaviors. For instance in C you can > write x + y, without having to express a detailed intention about > what happens with every bit. > > It's a tautology that you have to be explicit about declaring your > intent using the documented knobs and levers that are available, > using the semantics of the paradigm they control, while not being able > declare intent about the inner mechanism that underlies them. Using > any language whatsoever. Are you really so clueless that you don't understand the point of the quoted paragraph? Or are you just being deliberately obtuse as part of a general contrarian affect?
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-03-03 03:30 +0000 |
| Message-ID | <us0qs9$2adp7$2@dont-email.me> |
| In reply to | #383250 |
On Sun, 3 Mar 2024 02:10:03 -0000 (UTC), John McCue wrote: > Well to be fair, the feds regulations in the 60s made COBOL and FORTRAN > very popular, plus POSIX later on. The US Government purchasing rules on POSIX were sufficiently sketchy that Microsoft was able to satisfy them easily with Windows NT, while supplying a “POSIX” subsystem that was essentially unusable. And then Microsoft went on to render POSIX largely irrelevant by eating all the proprietary “Unix” vendors alive. Nowadays, POSIX (and *nix generally) is undergoing a resurgence because of Linux and Open Source. Developers are discovering that the Linux ecosystem offers a much more productive development environment for a code-sharing, code-reusing, Web-centric world than anything Microsoft can offer.
[toc] | [prev] | [next] | [standalone]
| From | Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> |
|---|---|
| Date | 2024-03-03 08:54 +0000 |
| Message-ID | <pan$65c41$a9839f31$d08c6b33$ea3463ce@invalid.invalid> |
| In reply to | #383252 |
Lawrence D'Oliveiro wrote: > Nowadays, POSIX (and *nix generally) is undergoing a resurgence because > of Linux and Open Source. Developers are discovering that the Linux > ecosystem offers a much more productive development environment for a > code-sharing, code-reusing, Web-centric world than anything Microsoft > can offer. I do not want to live in a web-centric world. I would much rather see other, better uses of the internet become widespread. -- Blue-Maned_HawkÃÃÃâshortens to HawkÃÃÃâ/ blu.mÃin.dÃÃÃÃðak/ ÃÃÃâhe/him/his/himself/Mr. blue-maned_hawk.srht.site Special thanks to misinformed hipsters!
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-03-03 20:11 +0000 |
| Message-ID | <us2lh2$2ltj3$6@dont-email.me> |
| In reply to | #383254 |
On Sun, 3 Mar 2024 08:54:36 -0000 (UTC), Blue-Maned_Hawk wrote: > Lawrence D'Oliveiro wrote: > >> Nowadays, POSIX (and *nix generally) is undergoing a resurgence because >> of Linux and Open Source. Developers are discovering that the Linux >> ecosystem offers a much more productive development environment for a >> code-sharing, code-reusing, Web-centric world than anything Microsoft >> can offer. > > I do not want to live in a web-centric world. You already do.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-03-03 13:49 -0800 |
| Message-ID | <us2r8r$2n6h3$2@dont-email.me> |
| In reply to | #383275 |
On 3/3/2024 12:11 PM, Lawrence D'Oliveiro wrote: > On Sun, 3 Mar 2024 08:54:36 -0000 (UTC), Blue-Maned_Hawk wrote: > >> Lawrence D'Oliveiro wrote: >> >>> Nowadays, POSIX (and *nix generally) is undergoing a resurgence because >>> of Linux and Open Source. Developers are discovering that the Linux >>> ecosystem offers a much more productive development environment for a >>> code-sharing, code-reusing, Web-centric world than anything Microsoft >>> can offer. >> >> I do not want to live in a web-centric world. > > You already do. You are not an ai, right? ;^)
[toc] | [prev] | [next] | [standalone]
| From | Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> |
|---|---|
| Date | 2024-03-03 22:11 +0000 |
| Message-ID | <pan$34b38$e07da3d7$ec6829a6$737b9404@invalid.invalid> |
| In reply to | #383275 |
Lawrence D'Oliveiro wrote: > On Sun, 3 Mar 2024 08:54:36 -0000 (UTC), Blue-Maned_Hawk wrote: > >> Lawrence D'Oliveiro wrote: >> >>> Nowadays, POSIX (and *nix generally) is undergoing a resurgence >>> because of Linux and Open Source. Developers are discovering that the >>> Linux ecosystem offers a much more productive development environment >>> for a code-sharing, code-reusing, Web-centric world than anything >>> Microsoft can offer. >> >> I do not want to live in a web-centric world. > > You already do. That does not change the veracity of my statement. -- Blue-Maned_HawkÃÃÃÃâshortens to HawkÃÃÃÃâ/ blu.mÃin.dÃÃÃÃÃðak/ ÃÃÃÃâhe/him/his/himself/Mr. blue-maned_hawk.srht.site Every time!
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-03-03 23:27 +0000 |
| Message-ID | <us311p$2of1i$2@dont-email.me> |
| In reply to | #383282 |
On Sun, 3 Mar 2024 22:11:14 -0000 (UTC), Blue-Maned_Hawk wrote: > Lawrence D'Oliveiro wrote: > >> On Sun, 3 Mar 2024 08:54:36 -0000 (UTC), Blue-Maned_Hawk wrote: >> >>> I do not want to live in a web-centric world. >> >> You already do. > > That does not change the veracity of my statement. That doesn’t change the veracity of mine.
[toc] | [prev] | [next] | [standalone]
| From | Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> |
|---|---|
| Date | 2024-03-07 06:46 +0000 |
| Message-ID | <pan$a70d8$87691c69$40a7ae82$e9e5d0cd@invalid.invalid> |
| In reply to | #383285 |
Lawrence D'Oliveiro wrote: > On Sun, 3 Mar 2024 22:11:14 -0000 (UTC), Blue-Maned_Hawk wrote: > >> Lawrence D'Oliveiro wrote: >> >>> On Sun, 3 Mar 2024 08:54:36 -0000 (UTC), Blue-Maned_Hawk wrote: >>> >>>> I do not want to live in a web-centric world. >>> >>> You already do. >> >> That does not change the veracity of my statement. > > That doesn’t change the veracity of mine. Then our collective fingertips have done nothing in their plasticsmacking. -- Blue-Maned_HawkÃÃÃÃâshortens to HawkÃÃÃÃâ/ blu.mÃin.dÃÃÃÃÃðak/ ÃÃÃÃâhe/him/his/himself/Mr. blue-maned_hawk.srht.site FORE!
[toc] | [prev] | [next] | [standalone]
| From | Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> |
|---|---|
| Date | 2024-03-03 08:52 +0000 |
| Message-ID | <pan$7c635$8df1683c$82c11c30$637245ac@invalid.invalid> |
| In reply to | #383248 |
Any attempt to displace C will require total replacement of the modern computing ecosystem. Frankly, i'd be fine with that if pulled off well, but i wouldn't be fine with a half-baked solution nor trying to force out C without thinking about the whole rest of everything. -- Blue-Maned_HawkÃÃÃâshortens to HawkÃÃÃâ/ blu.mÃin.dÃÃÃÃðak/ ÃÃÃâhe/him/his/himself/Mr. blue-maned_hawk.srht.site Mac and Cheese, Horrifying Quality, Prepared by Barack Obama
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-03-03 11:10 +0200 |
| Message-ID | <20240303111022.0000051c@yahoo.com> |
| In reply to | #383248 |
On Sat, 2 Mar 2024 17:13:56 -0600 Lynn McGuire <lynnmcguire5@gmail.com> wrote: > They have been talking about it for at least 20 years now. More like 48-49 years. https://en.wikipedia.org/wiki/High_Order_Language_Working_Group
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-03-03 12:01 +0100 |
| Message-ID | <us1lb5$2f4n4$1@dont-email.me> |
| In reply to | #383248 |
On 03/03/2024 00:13, Lynn McGuire wrote: > "White House to Developers: Using C or C++ Invites Cybersecurity Risks" > > https://www.pcmag.com/news/white-house-to-developers-using-c-plus-plus-invites-cybersecurity-risks > > "The Biden administration backs a switch to more memory-safe programming > languages. The tech industry sees their point, but it won't be easy." > > No. The feddies want to regulate software development very much. They > have been talking about it for at least 20 years now. This is a very > bad thing. > > Lynn It's the wrong solution to the wrong problem. It is not languages like C and C++ that are "unsafe". It is the programmers that write the code for them. As long as the people programming in Rust or other modern languages are the more capable and qualified developers - the ones who think about memory safety, correct code, testing, and quality software development - then code written in Rust will be better quality and safer than the average C, C++, Java and C# code. But if it gets popular enough for schools and colleges to teach Rust programming course to the masses, and it gets used by developers who are paid per KLoC, given responsibilities well beyond their abilities and experience, lead by incompetent managers, untrained in good development practices and pushed to impossible deadlines, then the average quality of programs in Rust will drop to that of average C and C++ code. Good languages and good tools help, but they are not the root cause of poor quality software in the world.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-03-03 16:03 +0100 |
| Message-ID | <us23fg$2i0j2$1@dont-email.me> |
| In reply to | #383257 |
On 03.03.2024 12:01, David Brown wrote: > On 03/03/2024 00:13, Lynn McGuire wrote: >> "White House to Developers: Using C or C++ Invites Cybersecurity Risks" >> >> https://www.pcmag.com/news/white-house-to-developers-using-c-plus-plus-invites-cybersecurity-risks >> >> "The Biden administration backs a switch to more memory-safe >> programming languages. [...]" >> [...] > > It's the wrong solution to the wrong problem. > > It is not languages like C and C++ that are "unsafe". It is the > programmers that write the code for them. [...] > > [...] > > Good languages and good tools help, but they are not the root cause of > poor quality software in the world. I agree about the necessity of having good programmers. But a lot more factors are important, and there's factors that influence programmers. Languages may have a design that makes it possible to produce safer software, or to be error prone and require a lot more attention from the programmers (and also from management). Tools may help a bit to work around the problems that languages inherently add. Good project management may also help to increase software quality. But it's much more costly in case of using inferior (or unsuited) languages. Janis
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-03-03 18:18 +0000 |
| Message-ID | <20240303092938.43@kylheku.com> |
| In reply to | #383257 |
On 2024-03-03, David Brown <david.brown@hesbynett.no> wrote: > On 03/03/2024 00:13, Lynn McGuire wrote: >> "White House to Developers: Using C or C++ Invites Cybersecurity Risks" >> >> https://www.pcmag.com/news/white-house-to-developers-using-c-plus-plus-invites-cybersecurity-risks >> >> "The Biden administration backs a switch to more memory-safe programming >> languages. The tech industry sees their point, but it won't be easy." >> >> No. The feddies want to regulate software development very much. They >> have been talking about it for at least 20 years now. This is a very >> bad thing. >> >> Lynn > > It's the wrong solution to the wrong problem. > > It is not languages like C and C++ that are "unsafe". It is the > programmers that write the code for them. As long as the people > programming in Rust or other modern languages are the more capable and > qualified developers - the ones who think about memory safety, correct > code, testing, and quality software development - then code written in > Rust will be better quality and safer than the average C, C++, Java and > C# code. Programmers who think about safety, correctness and quality and all that have way fewer diagnostics and more footguns if they are coding in C compared to Rust. I think, you can't just wave away the characteristics of Rust as making no difference in this regard. > But if it gets popular enough for schools and colleges to teach Rust > programming course to the masses, and it gets used by developers who are > paid per KLoC, given responsibilities well beyond their abilities and > experience, lead by incompetent managers, untrained in good development > practices and pushed to impossible deadlines, then the average quality > of programs in Rust will drop to that of average C and C++ code. The rhetoric you hear from Rust people about this is that coders taking a safety shortcut to make something work have to explicitly ask for that in Rust. It leaves a visible trace. If something goes wrong because of an unsafe block, you can trace that to the commit which added it. The rhetoric all sounds good. However, like you, I also believe it boils down to people, in a somewhat different way. To use Rust productively, you have to be one of the rare idiot savants who are smart enough to use it *and* numb to all the inconveniences. The reason the average programmer won't make any safety boo-boos using Rust is that the average programmer either isn't smart enough to use it at all, or else doesn't want to put up with the fuss: they will opt for some safe language which is easy to use. Rust's problem is that we have safe languages in which you can almost crank out working code with your eyes closed. (Or if not working, then at least code in which the only uncaught bugs are your logic bugs, not some undefined behavior from integer overflow or array out of bounds.) This is why Rust people are desperately pitching Rust as an alternative for C and whatnot, and showcasing it being used in the kernel and whatnot. Trying to be both safe and efficient to be able to serve as a "C replacement" is a clumsy hedge that makes Rust an awkward language. You know the parable about the fox that tries to chase two rabbits. The alternative to Rust in application development is pretty much any convenient, "easy" high level language, plus a little bit of C. You can get a small quantity of C right far more easily than a large quantity of C. It's almost immaterial. An important aspect of Rust is the ownership-based memory management. The problem is, the "garbage collection is bad" era is /long/ behind us. Scoped ownership is a half-baked solution to the object lifetime problem, that gets in the way of the programmer and isn't appropriate for the vast majority of software tasks. Embedded systems often need custom memory management, not something that the language imposes. C has malloc, yet even that gets disused in favor of something else. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-03-03 21:23 +0100 |
| Message-ID | <us2m8u$2m9mm$1@dont-email.me> |
| In reply to | #383267 |
On 03/03/2024 19:18, Kaz Kylheku wrote: > On 2024-03-03, David Brown <david.brown@hesbynett.no> wrote: >> On 03/03/2024 00:13, Lynn McGuire wrote: >>> "White House to Developers: Using C or C++ Invites Cybersecurity Risks" >>> >>> https://www.pcmag.com/news/white-house-to-developers-using-c-plus-plus-invites-cybersecurity-risks >>> >>> "The Biden administration backs a switch to more memory-safe programming >>> languages. The tech industry sees their point, but it won't be easy." >>> >>> No. The feddies want to regulate software development very much. They >>> have been talking about it for at least 20 years now. This is a very >>> bad thing. >>> >>> Lynn >> >> It's the wrong solution to the wrong problem. >> >> It is not languages like C and C++ that are "unsafe". It is the >> programmers that write the code for them. As long as the people >> programming in Rust or other modern languages are the more capable and >> qualified developers - the ones who think about memory safety, correct >> code, testing, and quality software development - then code written in >> Rust will be better quality and safer than the average C, C++, Java and >> C# code. > > Programmers who think about safety, correctness and quality and all that > have way fewer diagnostics and more footguns if they are coding in C > compared to Rust. > > I think, you can't just wave away the characteristics of Rust as making > no difference in this regard. I did not. I said that the /root/ problem is not the language, but the programmers and the way they work. Of course some languages make some things harder and other things easier. And even the most careful programmers will occasionally make mistakes. So having a language that helps reduce the risk of some kinds of errors is a helpful thing. But consider this. When programming in modern C++, you can be risk-free from buffer overruns and most kinds of memory leak - use container classes, string classes, and the like, rather than C-style arrays and malloc/free or new/delete. You can use the C++ coding guideline libraries to mark ownership of pointers. You can use compiler sanitizers to catch many kinds undefined behaviour. You can use all sorts of static analysis tools, from free to very costly, to help find problems. And yet there are armies of programmers writing bad C++ code. PHP and Javascript have automatic memory management and garbage collection eliminating many of the possible problems seen in C and C++ code, yet armies of programmers write PHP and Javascript code full of bugs and security faults. Better languages, better libraries, and better tools certainly help. There are not many tasks for which C is the best choice of language. But none of that will deal with the root of the problem. Good programmers, with good training, in good development departments with good managers and good resources, will write correct code more efficiently in a better language, but they can write correct code in pretty much /any/ language. Similarly, the bulk of programmers will write bad code in any language. > >> But if it gets popular enough for schools and colleges to teach Rust >> programming course to the masses, and it gets used by developers who are >> paid per KLoC, given responsibilities well beyond their abilities and >> experience, lead by incompetent managers, untrained in good development >> practices and pushed to impossible deadlines, then the average quality >> of programs in Rust will drop to that of average C and C++ code. > > The rhetoric you hear from Rust people about this is that coders taking > a safety shortcut to make something work have to explicitly ask for that > in Rust. It leaves a visible trace. If something goes wrong because of > an unsafe block, you can trace that to the commit which added it. > > The rhetoric all sounds good. You can't trace the commit for programmers who don't use version control software - and that is a /lot/ of them. Leaving visible traces does not help when no one else looks at the code. Shortcuts are taken because the sales people need the code by tomorrow morning, and there are only so many hours in the night to get it working. Rust makes it possible to have some safety checks for a few things that are much harder to do in C++. It does not stop people writing bad code using bad development practices. > > However, like you, I also believe it boils down to people, in a > somewhat different way. To use Rust productively, you have to be one of > the rare idiot savants who are smart enough to use it *and* numb to all > the inconveniences. And you have to have managers who are smart enough to believe it when their programmers say they need to train in a new language, re-write lots of existing code, and accept longer development times as a tradeoff for fewer bugs in shipped code. (I personally have a very good manager, but I know a great many programmers do not.) > > The reason the average programmer won't make any safety > boo-boos using Rust is that the average programmer either isn't smart > enough to use it at all, or else doesn't want to put up with the fuss: > they will opt for some safe language which is easy to use. > > Rust's problem is that we have safe languages in which you can almost > crank out working code with your eyes closed. (Or if not working, > then at least code in which the only uncaught bugs are your logic bugs, > not some undefined behavior from integer overflow or array out of > bounds.) > > This is why Rust people are desperately pitching Rust as an alternative > for C and whatnot, and showcasing it being used in the kernel and > whatnot. > I personally think it is madness to have Rust in a project like the Linux kernel. I used to see C++ as a rapidly changing language with its 3 year cycle - Rust seems to have a 3 week cycle for updates, with no formal standardisation and "work in progress" attitude. That's fine for a new language under development, but /not/ something you want for a project that spans decades. > Trying to be both safe and efficient to be able to serve as a "C > replacement" is a clumsy hedge that makes Rust an awkward language. > > You know the parable about the fox that tries to chase two rabbits. > > The alternative to Rust in application development is pretty much any > convenient, "easy" high level language, plus a little bit of C. > You can get a small quantity of C right far more easily than a large > quantity of C. It's almost immaterial. > There are lots of alternatives to Rust for application development. But in general, higher level languages mean you do less manual work, and write fewer lines of code for the same amount of functionality. And that means a lower risk of errors. > An important aspect of Rust is the ownership-based memory management. > > The problem is, the "garbage collection is bad" era is /long/ behind us. > > Scoped ownership is a half-baked solution to the object lifetime > problem, that gets in the way of the programmer and isn't appropriate > for the vast majority of software tasks. > > Embedded systems often need custom memory management, not something that > the language imposes. C has malloc, yet even that gets disused in favor > of something else. > For safe embedded systems, you don't want memory management at all. Avoiding dynamic memory is an important aspect of safety-critical embedded development.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-03-03 14:01 -0800 |
| Message-ID | <us2s0i$2n6h3$5@dont-email.me> |
| In reply to | #383276 |
On 3/3/2024 12:23 PM, David Brown wrote: > On 03/03/2024 19:18, Kaz Kylheku wrote: >> On 2024-03-03, David Brown <david.brown@hesbynett.no> wrote: >>> On 03/03/2024 00:13, Lynn McGuire wrote: >>>> "White House to Developers: Using C or C++ Invites Cybersecurity Risks" >>>> >>>> https://www.pcmag.com/news/white-house-to-developers-using-c-plus-plus-invites-cybersecurity-risks >>>> >>>> "The Biden administration backs a switch to more memory-safe >>>> programming >>>> languages. The tech industry sees their point, but it won't be easy." >>>> >>>> No. The feddies want to regulate software development very much. They >>>> have been talking about it for at least 20 years now. This is a very >>>> bad thing. >>>> >>>> Lynn >>> >>> It's the wrong solution to the wrong problem. >>> >>> It is not languages like C and C++ that are "unsafe". It is the >>> programmers that write the code for them. As long as the people >>> programming in Rust or other modern languages are the more capable and >>> qualified developers - the ones who think about memory safety, correct >>> code, testing, and quality software development - then code written in >>> Rust will be better quality and safer than the average C, C++, Java and >>> C# code. >> >> Programmers who think about safety, correctness and quality and all that >> have way fewer diagnostics and more footguns if they are coding in C >> compared to Rust. >> >> I think, you can't just wave away the characteristics of Rust as making >> no difference in this regard. > > I did not. > > I said that the /root/ problem is not the language, but the programmers > and the way they work. > > Of course some languages make some things harder and other things > easier. And even the most careful programmers will occasionally make > mistakes. So having a language that helps reduce the risk of some kinds > of errors is a helpful thing. > > But consider this. When programming in modern C++, you can be risk-free > from buffer overruns and most kinds of memory leak - use container > classes, string classes, and the like, rather than C-style arrays and > malloc/free or new/delete. You can use the C++ coding guideline > libraries to mark ownership of pointers. You can use compiler > sanitizers to catch many kinds undefined behaviour. You can use all > sorts of static analysis tools, from free to very costly, to help find > problems. And yet there are armies of programmers writing bad C++ code. > PHP and Javascript have automatic memory management and garbage > collection eliminating many of the possible problems seen in C and C++ > code, yet armies of programmers write PHP and Javascript code full of > bugs and security faults. > > Better languages, better libraries, and better tools certainly help. > There are not many tasks for which C is the best choice of language. But > none of that will deal with the root of the problem. Good programmers, > with good training, in good development departments with good managers > and good resources, will write correct code more efficiently in a better > language, but they can write correct code in pretty much /any/ > language. Similarly, the bulk of programmers will write bad code in any > language. > >> >>> But if it gets popular enough for schools and colleges to teach Rust >>> programming course to the masses, and it gets used by developers who are >>> paid per KLoC, given responsibilities well beyond their abilities and >>> experience, lead by incompetent managers, untrained in good development >>> practices and pushed to impossible deadlines, then the average quality >>> of programs in Rust will drop to that of average C and C++ code. >> >> The rhetoric you hear from Rust people about this is that coders taking >> a safety shortcut to make something work have to explicitly ask for that >> in Rust. It leaves a visible trace. If something goes wrong because of >> an unsafe block, you can trace that to the commit which added it. >> >> The rhetoric all sounds good. > > You can't trace the commit for programmers who don't use version control > software - and that is a /lot/ of them. Leaving visible traces does not > help when no one else looks at the code. Shortcuts are taken because > the sales people need the code by tomorrow morning, and there are only > so many hours in the night to get it working. > > Rust makes it possible to have some safety checks for a few things that > are much harder to do in C++. It does not stop people writing bad code > using bad development practices. > >> >> However, like you, I also believe it boils down to people, in a >> somewhat different way. To use Rust productively, you have to be one of >> the rare idiot savants who are smart enough to use it *and* numb to all >> the inconveniences. > > And you have to have managers who are smart enough to believe it when > their programmers say they need to train in a new language, re-write > lots of existing code, and accept longer development times as a tradeoff > for fewer bugs in shipped code. > > (I personally have a very good manager, but I know a great many > programmers do not.) > >> >> The reason the average programmer won't make any safety >> boo-boos using Rust is that the average programmer either isn't smart >> enough to use it at all, or else doesn't want to put up with the fuss: >> they will opt for some safe language which is easy to use. >> >> Rust's problem is that we have safe languages in which you can almost >> crank out working code with your eyes closed. (Or if not working, >> then at least code in which the only uncaught bugs are your logic bugs, >> not some undefined behavior from integer overflow or array out of >> bounds.) >> >> This is why Rust people are desperately pitching Rust as an alternative >> for C and whatnot, and showcasing it being used in the kernel and >> whatnot. >> > > I personally think it is madness to have Rust in a project like the > Linux kernel. I used to see C++ as a rapidly changing language with its > 3 year cycle - Rust seems to have a 3 week cycle for updates, with no > formal standardisation and "work in progress" attitude. That's fine for > a new language under development, but /not/ something you want for a > project that spans decades. > >> Trying to be both safe and efficient to be able to serve as a "C >> replacement" is a clumsy hedge that makes Rust an awkward language. >> >> You know the parable about the fox that tries to chase two rabbits. >> >> The alternative to Rust in application development is pretty much any >> convenient, "easy" high level language, plus a little bit of C. >> You can get a small quantity of C right far more easily than a large >> quantity of C. It's almost immaterial. >> > > There are lots of alternatives to Rust for application development. But > in general, higher level languages mean you do less manual work, and > write fewer lines of code for the same amount of functionality. And > that means a lower risk of errors. > >> An important aspect of Rust is the ownership-based memory management. >> >> The problem is, the "garbage collection is bad" era is /long/ behind us. >> >> Scoped ownership is a half-baked solution to the object lifetime >> problem, that gets in the way of the programmer and isn't appropriate >> for the vast majority of software tasks. >> >> Embedded systems often need custom memory management, not something that >> the language imposes. C has malloc, yet even that gets disused in favor >> of something else. >> > > For safe embedded systems, you don't want memory management at all. > Avoiding dynamic memory is an important aspect of safety-critical > embedded development. > You still have to think about memory management even if you avoid any dynamic memory? How are you going to mange this memory wrt your various data structures needs....
[toc] | [prev] | [next] | [standalone]
Page 1 of 12 [1] 2 3 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web