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 8 of 12 — ← Prev page 1 … 6 7 [8] 9 10 … 12 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-03-11 18:06 +0000 |
| Subject | Re: avoiding strdup() |
| Message-ID | <VKHHN.125447$TSTa.32477@fx47.iad> |
| In reply to | #383516 |
Michael S <already5chosen@yahoo.com> writes: >On Mon, 11 Mar 2024 17:05:40 GMT >scott@slp53.sl.home (Scott Lurndal) wrote: > >> Michael S <already5chosen@yahoo.com> writes: >> >On Mon, 11 Mar 2024 16:23:32 +0000 >> >Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: >> > >> >> On 10/03/2024 18:47, Scott Lurndal wrote: >> >> > Kaz Kylheku <433-929-6894@kylheku.com> writes: >> >> >> On 2024-03-10, Michael S <already5chosen@yahoo.com> wrote: >> >> >>> On Sat, 09 Mar 2024 16:37:19 -0800 >> >> >>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >> >> >>>> strdup() and strndup() are being added to the C23 standard. >> >> >>>> >> >> >>> >> >> >>> What is justification? >> >> >> >> >> >> strdup is required by POSIX already and thus widely implemented. >> >> >> Many programmers who are not into standards already assume it's >> >> >> in C. >> >> >> >> >> >> For decades, portable programs have been doing things like this: >> >> >> >> >> >> #if HAVE_STRDUP >> >> >> #define xstrdup(s) strdup(s) >> >> >> #else >> >> >> char *xstrdup(const char *); // own definition >> >> >> #endif >> >> >> >> >> >>> What strdup() can do better, for any chosen value of better, >> >> >>> than strlen()+malloc()+memcpy() ? >> >> >> >> >> >> Not take up space in every application for a common library >> >> >> routine. >> >> > >> >> > It's a form of lazy programming. I've seen a lot of open source >> >> > code that uses strdup without checking for failure and frequently >> >> > "forgetting" to free the result. >> >> >> >> And it is probably more likely that machine with many gigabytes of >> >> RAM will develop an electrical fault than that that call for a >> >> short string will be the point where it runs out of memory. >> > >> >Is there any chance at all that on typical Linux machine (i.e. the >> >one configured to overcommit virtual memory) strdup() returns NULL? >> >If it was malloc() I'd say - no chance. For strdup() I'm less sure. >> > >> >> An unanswerable question. But, consider that not all allocations >> in an application use strdup as the only memory allocator (the >> majority don't, and other allocations may be much larger), yet both >> use the same pool of address space and host memory. >> >> Consider also that on unix and linux, there are a number of resource >> limits intended to prevent a single application from consuming all of >> memory, which a call to strdup may encounter even with plenty of RAM >> available. >> >> Toy applications may not have an issue with strdup. Real >> applications on the other hand might, and an unexpected SIGSEGV is >> extremely user-unfriendly and could have catastrophic results. >> > > >According to my understanding, on Linux with overcommit enabled, >typical behavior would be that allocation (of non-extravagant size, >say, no more than 100 MB) always succeeds. OOM is called later, on >access. It seems, that most commonly OOM does not hit application that >is allocating right now. Much more likely that it will kill app that >user opened hours ago, then put aside and then tried to use again. > >> And on the gripping hand, not testing for a potential catastrophic >> failure condition, no matter how unlikely isn't the sign of a good >> programmer. > >Some people would say that writing code (a handler for allocation >returning NULL) that either can't be tested in principle or can be >tested only in principle, but most certainly not tested in >practice, isn't a sign of a good programmer. 1) It is certainly possible to test in practice (unit test, or random error-injection). 2) I've never heard anyone say that. >Myself, I still tend to code this checks, but >(1) my main targets are not Linux with overcommit, so the >chance of allocation returning NULL could be estimated like "not going >to happen" rather than "can't happen". >(2) I am old full that like his unreasonable old habits I consider software that can cause a SIGSEGV when run by a customer to be broken. The programmer(s) should take every reasonable precaution to ensure that doesn't happen. If the OOM killer (in any system where overcommit is enabled) must run, the system is by definition unstable. > >At least, I stopped checking return value of fclose() after being told, >with facts, how stupid it is. So, may be, one day I'd convince myself to >stop checking return value of malloc() as well. An application that cares will fsync(2) the file descriptor before closing it with close(2) and will check the fsync return value and take appropriate action if it fails. While I personally eschew fopen/fclose and their ilk due to performance overhead generally, were I to use it for data which is required to be valid, I'd always check the results of fflush before closing with fclose(). It really depends on the application and the importance of the data (ephemeral data, e.g. terminal output from ps(1), may not require the same level of scrutiny as a database, for example).
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-03-11 20:29 +0200 |
| Subject | Re: avoiding strdup() |
| Message-ID | <20240311202914.00005cab@yahoo.com> |
| In reply to | #383520 |
> > An application that cares will fsync(2) the file descriptor before > closing it with close(2) and will check the fsync return value and > take appropriate action if it fails. > > While I personally eschew fopen/fclose and their ilk due to > performance overhead generally, were I to use it for data which > is required to be valid, I'd always check the results of fflush > before closing with fclose(). Last I looked at it, and it was several years ago, so can misremember, fflush() is only slightly better, if at all better, than fclose(). It also does not guarantee that my data propagated beyond filesystem write cache. For fsync() there are problems as well. (1) - it is not part of C Standard. (2) - even on systems where it is implemented, like Linux, BSD and Mac, it is likely to not do the same things. (3) - if done in UI thread, it's likely to negatively affect responsiveness of UI. If not done in UI thread, it's too much of error-prone code to write. > > It really depends on the application and the importance of the > data (ephemeral data, e.g. terminal output from ps(1), may not > require the same level of scrutiny as a database, for example).
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2024-03-11 19:57 +0000 |
| Subject | Re: avoiding strdup() |
| Message-ID | <YkhvH0ibt4fqZu1NS@bongo-ra.co> |
| In reply to | #383516 |
On Mon, 11 Mar 2024 19:35:11 +0200
Michael S <already5chosen@yahoo.com> wrote:
> Some people would say that writing code (a handler for allocation
> returning NULL) that either can't be tested in principle or can be
> tested only in principle, but most certainly not tested in
> practice, isn't a sign of a good programmer.
It can be tested in practice by explicitly inserting failure code , perhaps
activated by a macro :
pointer = malloc(...) ;
if (pointer == 0 || testN) { ... handle error ... } ;
It clutters the code but it's testable.
> Myself, I still tend to code this checks, but
> (1) my main targets are not Linux with overcommit, so the
> chance of allocation returning NULL could be estimated like "not going
> to happen" rather than "can't happen".
> (2) I am old full that like his unreasonable old habits
What's the practical difference between "not going to happen" and
"can't happen" ? Practically , you can never know that it can't happen
because overcommit is a matter of configuration of the Linux system.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-03-11 10:13 -0700 |
| Subject | Re: avoiding strdup() |
| Message-ID | <87edcgzo7r.fsf@nosuchdomain.example.com> |
| In reply to | #383512 |
Michael S <already5chosen@yahoo.com> writes:
[...]
> Is there any chance at all that on typical Linux machine (i.e. the one
> configured to overcommit virtual memory) strdup() returns NULL?
> If it was malloc() I'd say - no chance. For strdup() I'm less sure.
strdup() calls malloc(), so strdup() can return NULL if and only if
malloc() can return NULL -- but with the additional constraint that you
first need to have a string argument to strdup() that's long enough to
cause a suffiently large argument to be passed to malloc().
One data point: On my Ubuntu system, malloc(SIZE_MAX) returns NULL for
very large arguments (over about 23 GiB in my quick and dirty test).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-03-11 17:58 +0000 |
| Subject | Re: avoiding strdup() |
| Message-ID | <20240311105508.215@kylheku.com> |
| In reply to | #383515 |
On 2024-03-11, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > Michael S <already5chosen@yahoo.com> writes: > [...] >> Is there any chance at all that on typical Linux machine (i.e. the one >> configured to overcommit virtual memory) strdup() returns NULL? >> If it was malloc() I'd say - no chance. For strdup() I'm less sure. > > strdup() calls malloc(), so strdup() can return NULL if and only if > malloc() can return NULL -- but with the additional constraint that you > first need to have a string argument to strdup() that's long enough to > cause a suffiently large argument to be passed to malloc(). > > One data point: On my Ubuntu system, malloc(SIZE_MAX) returns NULL for > very large arguments (over about 23 GiB in my quick and dirty test). I'm guessing that might be only be because of the overcommit_ratio value; i.e that allowing a 23 GiB increment in the allocated address space would bring the system over the currently configured overcommit ratio. -- 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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-03-11 11:28 -0700 |
| Subject | Re: avoiding strdup() |
| Message-ID | <87msr4aaio.fsf@nosuchdomain.example.com> |
| In reply to | #383518 |
Kaz Kylheku <433-929-6894@kylheku.com> writes:
> On 2024-03-11, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Michael S <already5chosen@yahoo.com> writes:
>> [...]
>>> Is there any chance at all that on typical Linux machine (i.e. the one
>>> configured to overcommit virtual memory) strdup() returns NULL?
>>> If it was malloc() I'd say - no chance. For strdup() I'm less sure.
>>
>> strdup() calls malloc(), so strdup() can return NULL if and only if
>> malloc() can return NULL -- but with the additional constraint that you
>> first need to have a string argument to strdup() that's long enough to
>> cause a suffiently large argument to be passed to malloc().
>>
>> One data point: On my Ubuntu system, malloc(SIZE_MAX) returns NULL for
>> very large arguments (over about 23 GiB in my quick and dirty test).
>
> I'm guessing that might be only be because of the overcommit_ratio
> value; i.e that allowing a 23 GiB increment in the allocated address
> space would bring the system over the currently configured overcommit
> ratio.
Good guess, but I don't think so.
$ cat /proc/sys/vm/overcommit_memory
0
$ cat /proc/sys/vm/overcommit_ratio
50
(These are the default values.) If I'm reading the proc(5) man page
correctly (which is questionable), 0 means "heuristic overcommit", and
overcommit_ratio is ignored unless the mode is set to 2.
I have 12 GB of physical memory.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-03-11 17:58 +0000 |
| Subject | Re: avoiding strdup() |
| Message-ID | <UCHHN.125446$TSTa.5399@fx47.iad> |
| In reply to | #383515 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >Michael S <already5chosen@yahoo.com> writes: >[...] >> Is there any chance at all that on typical Linux machine (i.e. the one >> configured to overcommit virtual memory) strdup() returns NULL? >> If it was malloc() I'd say - no chance. For strdup() I'm less sure. > >strdup() calls malloc(), so strdup() can return NULL if and only if >malloc() can return NULL -- but with the additional constraint that you >first need to have a string argument to strdup() that's long enough to >cause a suffiently large argument to be passed to malloc(). > >One data point: On my Ubuntu system, malloc(SIZE_MAX) returns NULL for >very large arguments (over about 23 GiB in my quick and dirty test). That may be due to resource limits (setrlimit/getrlimit/ulimit) on the size of the address space.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-03-11 11:30 -0700 |
| Subject | Re: avoiding strdup() |
| Message-ID | <87il1saaev.fsf@nosuchdomain.example.com> |
| In reply to | #383519 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>Michael S <already5chosen@yahoo.com> writes:
>>[...]
>>> Is there any chance at all that on typical Linux machine (i.e. the one
>>> configured to overcommit virtual memory) strdup() returns NULL?
>>> If it was malloc() I'd say - no chance. For strdup() I'm less sure.
>>
>>strdup() calls malloc(), so strdup() can return NULL if and only if
>>malloc() can return NULL -- but with the additional constraint that you
>>first need to have a string argument to strdup() that's long enough to
>>cause a suffiently large argument to be passed to malloc().
>>
>>One data point: On my Ubuntu system, malloc(SIZE_MAX) returns NULL for
>>very large arguments (over about 23 GiB in my quick and dirty test).
>
> That may be due to resource limits (setrlimit/getrlimit/ulimit) on
> the size of the address space.
I don't see anything relevant in the output of `ulimit -a`. In
particular, "data seg size" is unlimited.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2024-03-11 19:45 +0000 |
| Subject | Re: avoiding strdup() |
| Message-ID | <caIp5UwudOJvMTdVb@bongo-ra.co> |
| In reply to | #383515 |
On Mon, 11 Mar 2024 10:13:12 -0700 Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > One data point: On my Ubuntu system, malloc(SIZE_MAX) returns NULL for > very large arguments (over about 23 GiB in my quick and dirty test). You lost me there.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-03-11 13:11 -0700 |
| Subject | Re: avoiding strdup() |
| Message-ID | <871q8ga5rd.fsf@nosuchdomain.example.com> |
| In reply to | #383527 |
Spiros Bousbouras <spibou@gmail.com> writes:
> On Mon, 11 Mar 2024 10:13:12 -0700
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> One data point: On my Ubuntu system, malloc(SIZE_MAX) returns NULL for
>> very large arguments (over about 23 GiB in my quick and dirty test).
>
> You lost me there.
Sorry, editing error. I initially tried malloc(SIZE_MAX) and got a NULL
result. I then tried smaller values to try to find out where the cutoff
is, and didn't correctly edit the post.
Corrected version:
One data point: On my Ubuntu system, malloc() returns NULL for
very large arguments (over about 23 GiB in my quick and dirty test).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-03-11 17:00 +0000 |
| Subject | Re: avoiding strdup() |
| Message-ID | <yMGHN.481214$PuZ9.381006@fx11.iad> |
| In reply to | #383511 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >On 10/03/2024 18:47, Scott Lurndal wrote: >> Kaz Kylheku <433-929-6894@kylheku.com> writes: >>> On 2024-03-10, Michael S <already5chosen@yahoo.com> wrote: >>>> On Sat, 09 Mar 2024 16:37:19 -0800 >>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >>>>> strdup() and strndup() are being added to the C23 standard. >>>>> >>>> >>>> What is justification? >>> >>> strdup is required by POSIX already and thus widely implemented. >>> Many programmers who are not into standards already assume it's in C. >>> >>> For decades, portable programs have been doing things like this: >>> >>> #if HAVE_STRDUP >>> #define xstrdup(s) strdup(s) >>> #else >>> char *xstrdup(const char *); // own definition >>> #endif >>> >>>> What strdup() can do better, for any chosen value of better, than >>>> strlen()+malloc()+memcpy() ? >>> >>> Not take up space in every application for a common library routine. >> >> It's a form of lazy programming. I've seen a lot of open source >> code that uses strdup without checking for failure and frequently >> "forgetting" to free the result. > >And it is probably more likely that machine with many gigabytes of RAM Actually, your assumptions that: 1) strdup is the only allocation function used by an application 2) all strings are "short" are both flawed. >will develop an electrical fault than that that call for a short string >will be the point where it runs out of memory.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-03-11 17:52 +0000 |
| Subject | Re: avoiding strdup() |
| Message-ID | <20240311104527.444@kylheku.com> |
| In reply to | #383513 |
On 2024-03-11, Scott Lurndal <scott@slp53.sl.home> wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>On 10/03/2024 18:47, Scott Lurndal wrote: >>> Kaz Kylheku <433-929-6894@kylheku.com> writes: >>>> Not take up space in every application for a common library routine. >>> >>> It's a form of lazy programming. I've seen a lot of open source >>> code that uses strdup without checking for failure and frequently >>> "forgetting" to free the result. >> >>And it is probably more likely that machine with many gigabytes of RAM > > Actually, your assumptions that: > 1) strdup is the only allocation function used by an application > 2) all strings are "short" Even if a string is long enough to need its own mmap request, that will still return valid memory that later fails to commit. Under overcommit conditions, you will only reliably get null return out of a large strdup if you've exhausted your local address space (of which you have lots under 64 bits). -- 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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-03-11 18:10 +0000 |
| Subject | Re: avoiding strdup() |
| Message-ID | <3OHHN.125448$TSTa.103211@fx47.iad> |
| In reply to | #383517 |
Kaz Kylheku <433-929-6894@kylheku.com> writes: >On 2024-03-11, Scott Lurndal <scott@slp53.sl.home> wrote: >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>>On 10/03/2024 18:47, Scott Lurndal wrote: >>>> Kaz Kylheku <433-929-6894@kylheku.com> writes: >>>>> Not take up space in every application for a common library routine. >>>> >>>> It's a form of lazy programming. I've seen a lot of open source >>>> code that uses strdup without checking for failure and frequently >>>> "forgetting" to free the result. >>> >>>And it is probably more likely that machine with many gigabytes of RAM >> >> Actually, your assumptions that: >> 1) strdup is the only allocation function used by an application >> 2) all strings are "short" > >Even if a string is long enough to need its own mmap request, >that will still return valid memory that later fails to commit. Production linux systems generally disable overcommit. Developing applications that count on overcommit is a flawed idea. > >Under overcommit conditions, you will only reliably get null return out >of a large strdup if you've exhausted your local address space >(of which you have lots under 64 bits). Under overcommit, your application will likely be killed by the operating system OOM killer, or some other process may be killed. That is unacceptable in a production environment. The local address space is limited in unix and linux on a per-process basis. (setrlimit/getrlimit). The administrator sets system-wide limits, which can be overridden on a per UID basis via PAM.
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <invalid@invalid.invalid> |
|---|---|
| Date | 2024-03-11 19:11 +0000 |
| Subject | Re: avoiding strdup() |
| Message-ID | <wwv7ci837oa.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #383517 |
Kaz Kylheku <433-929-6894@kylheku.com> writes: > Scott Lurndal <scott@slp53.sl.home> wrote: >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>>On 10/03/2024 18:47, Scott Lurndal wrote: >>>> Kaz Kylheku <433-929-6894@kylheku.com> writes: >>>>> Not take up space in every application for a common library routine. >>>> >>>> It's a form of lazy programming. I've seen a lot of open source >>>> code that uses strdup without checking for failure and frequently >>>> "forgetting" to free the result. >>> >>>And it is probably more likely that machine with many gigabytes of RAM >> >> Actually, your assumptions that: >> 1) strdup is the only allocation function used by an application >> 2) all strings are "short" > > Even if a string is long enough to need its own mmap request, > that will still return valid memory that later fails to commit. Since strdup necessarily writes to almost all the memory it allocates, you’d expect the failure to be immediate. -- https://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-03-11 12:34 -0700 |
| Subject | Re: avoiding strdup() |
| Message-ID | <875xxsa7gk.fsf@nosuchdomain.example.com> |
| In reply to | #383525 |
Richard Kettlewell <invalid@invalid.invalid> writes:
> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>> Scott Lurndal <scott@slp53.sl.home> wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>On 10/03/2024 18:47, Scott Lurndal wrote:
>>>>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>>>>> Not take up space in every application for a common library routine.
>>>>>
>>>>> It's a form of lazy programming. I've seen a lot of open source
>>>>> code that uses strdup without checking for failure and frequently
>>>>> "forgetting" to free the result.
>>>>
>>>>And it is probably more likely that machine with many gigabytes of RAM
>>>
>>> Actually, your assumptions that:
>>> 1) strdup is the only allocation function used by an application
>>> 2) all strings are "short"
>>
>> Even if a string is long enough to need its own mmap request,
>> that will still return valid memory that later fails to commit.
>
> Since strdup necessarily writes to almost all the memory it allocates,
> you’d expect the failure to be immediate.
Yes, but that write happens *after* the malloc() call, so it won't
necessarily be reflected in the value returned by strdup(). It could
crash the current program, or in the worst case it could cause the OoM
killer to kill some other process.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-03-12 01:12 +0000 |
| Subject | Re: avoiding strdup() |
| Message-ID | <usoa6a$3tqji$1@dont-email.me> |
| In reply to | #383513 |
On 11/03/2024 17:00, Scott Lurndal wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >> On 10/03/2024 18:47, Scott Lurndal wrote: >>> Kaz Kylheku <433-929-6894@kylheku.com> writes: >>>> On 2024-03-10, Michael S <already5chosen@yahoo.com> wrote: >>>>> On Sat, 09 Mar 2024 16:37:19 -0800 >>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >>>>>> strdup() and strndup() are being added to the C23 standard. >>>>>> >>>>> >>>>> What is justification? >>>> >>>> strdup is required by POSIX already and thus widely implemented. >>>> Many programmers who are not into standards already assume it's in C. >>>> >>>> For decades, portable programs have been doing things like this: >>>> >>>> #if HAVE_STRDUP >>>> #define xstrdup(s) strdup(s) >>>> #else >>>> char *xstrdup(const char *); // own definition >>>> #endif >>>> >>>>> What strdup() can do better, for any chosen value of better, than >>>>> strlen()+malloc()+memcpy() ? >>>> >>>> Not take up space in every application for a common library routine. >>> >>> It's a form of lazy programming. I've seen a lot of open source >>> code that uses strdup without checking for failure and frequently >>> "forgetting" to free the result. >> >> And it is probably more likely that machine with many gigabytes of RAM > > Actually, your assumptions that: > 1) strdup is the only allocation function used by an application > 2) all strings are "short" > > are both flawed. > The bank has many billions. But there is a banking crisis on and it is about to fail. And someone, somewhere, will be that man who tries to withdraw some money and is told "no". But how likely is that man to be you with your 20 pounds at the cashpoint? How likely is it to be another bank making a cash call for a 100 million or so? And how often do banks fail, actually, and how often does government take action when it's heading that way, but nowhere near failing yet? -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-03-11 18:20 -0700 |
| Subject | Re: avoiding strdup() |
| Message-ID | <87sf0w8cux.fsf@nosuchdomain.example.com> |
| In reply to | #383533 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On 11/03/2024 17:00, Scott Lurndal wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>> On 10/03/2024 18:47, Scott Lurndal wrote:
>>>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>>>> On 2024-03-10, Michael S <already5chosen@yahoo.com> wrote:
>>>>>> On Sat, 09 Mar 2024 16:37:19 -0800
>>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>>>> strdup() and strndup() are being added to the C23 standard.
>>>>>>>
>>>>>>
>>>>>> What is justification?
>>>>>
>>>>> strdup is required by POSIX already and thus widely implemented.
>>>>> Many programmers who are not into standards already assume it's in C.
>>>>>
>>>>> For decades, portable programs have been doing things like this:
>>>>>
>>>>> #if HAVE_STRDUP
>>>>> #define xstrdup(s) strdup(s)
>>>>> #else
>>>>> char *xstrdup(const char *); // own definition
>>>>> #endif
>>>>>
>>>>>> What strdup() can do better, for any chosen value of better, than
>>>>>> strlen()+malloc()+memcpy() ?
>>>>>
>>>>> Not take up space in every application for a common library routine.
>>>>
>>>> It's a form of lazy programming. I've seen a lot of open source
>>>> code that uses strdup without checking for failure and frequently
>>>> "forgetting" to free the result.
>>>
>>> And it is probably more likely that machine with many gigabytes of RAM
>> Actually, your assumptions that:
>> 1) strdup is the only allocation function used by an application
>> 2) all strings are "short"
>> are both flawed.
>>
> The bank has many billions. But there is a banking crisis on and it is
> about to fail. And someone, somewhere, will be that man who tries to
> withdraw some money and is told "no". But how likely is that man to be
> you with your 20 pounds at the cashpoint? How likely is it to be
> another bank making a cash call for a 100 million or so?
If I withdraw 20 pounds from my bank, I'll bet you that 20 pounds that
the bank still checks whether it has the money.
I'd rather write correct code than code that almost certainly happens to
work. Sure, strdup() is unlikely to fail-- but I'm going to check the
result.
> And how often do banks fail, actually, and how often does government
> take action when it's heading that way, but nowhere near failing yet?
The government isn't going to intervene when your laptop is running low
on memory.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-03-12 15:40 +0000 |
| Subject | Re: avoiding strdup() |
| Message-ID | <uspt19$c2he$1@dont-email.me> |
| In reply to | #383535 |
On 12/03/2024 01:20, Keith Thompson wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >> On 11/03/2024 17:00, Scott Lurndal wrote: >>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>>> On 10/03/2024 18:47, Scott Lurndal wrote: >>>>> Kaz Kylheku <433-929-6894@kylheku.com> writes: >>>>>> On 2024-03-10, Michael S <already5chosen@yahoo.com> wrote: >>>>>>> On Sat, 09 Mar 2024 16:37:19 -0800 >>>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >>>>>>>> strdup() and strndup() are being added to the C23 standard. >>>>>>>> >>>>>>> >>>>>>> What is justification? >>>>>> >>>>>> strdup is required by POSIX already and thus widely implemented. >>>>>> Many programmers who are not into standards already assume it's in C. >>>>>> >>>>>> For decades, portable programs have been doing things like this: >>>>>> >>>>>> #if HAVE_STRDUP >>>>>> #define xstrdup(s) strdup(s) >>>>>> #else >>>>>> char *xstrdup(const char *); // own definition >>>>>> #endif >>>>>> >>>>>>> What strdup() can do better, for any chosen value of better, than >>>>>>> strlen()+malloc()+memcpy() ? >>>>>> >>>>>> Not take up space in every application for a common library routine. >>>>> >>>>> It's a form of lazy programming. I've seen a lot of open source >>>>> code that uses strdup without checking for failure and frequently >>>>> "forgetting" to free the result. >>>> >>>> And it is probably more likely that machine with many gigabytes of RAM >>> Actually, your assumptions that: >>> 1) strdup is the only allocation function used by an application >>> 2) all strings are "short" >>> are both flawed. >>> >> The bank has many billions. But there is a banking crisis on and it is >> about to fail. And someone, somewhere, will be that man who tries to >> withdraw some money and is told "no". But how likely is that man to be >> you with your 20 pounds at the cashpoint? How likely is it to be >> another bank making a cash call for a 100 million or so? > > If I withdraw 20 pounds from my bank, I'll bet you that 20 pounds that > the bank still checks whether it has the money. > > I'd rather write correct code than code that almost certainly happens to > work. Sure, strdup() is unlikely to fail-- but I'm going to check the > result. > >> And how often do banks fail, actually, and how often does government >> take action when it's heading that way, but nowhere near failing yet? > > The government isn't going to intervene when your laptop is running low > on memory. > No, it's an analogy. You run lots of apps gobbling lots of memory, and maybe a program won't launch or thngs start to slow or a warning comes up, and you realise that soon the program of interest might run out of memory, and so you shut other things down so that that doesn't happen. And so it's pretty rare to actually run out of memory unless the program isn't correct and there is a leak. -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-03-12 15:31 -0700 |
| Subject | Re: avoiding strdup() |
| Message-ID | <87cyrz84l0.fsf@nosuchdomain.example.com> |
| In reply to | #383550 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On 12/03/2024 01:20, Keith Thompson wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
>> If I withdraw 20 pounds from my bank, I'll bet you that 20 pounds
>> that the bank still checks whether it has the money. I'd rather
>> write correct code than code that almost certainly happens to work.
>> Sure, strdup() is unlikely to fail-- but I'm going to check the
>> result.
>>
>>> And how often do banks fail, actually, and how often does government
>>> take action when it's heading that way, but nowhere near failing yet?
>> The government isn't going to intervene when your laptop is running
>> low on memory.
>>
> No, it's an analogy. You run lots of apps gobbling lots of memory, and
> maybe a program won't launch or thngs start to slow or a warning comes
> up, and you realise that soon the program of interest might run out of
> memory, and so you shut other things down so that that doesn't happen.
> And so it's pretty rare to actually run out of memory unless the
> program isn't correct and there is a leak.
Are you relying in a person sitting in front of the computer and
noticing that memory is running low? The vast majority of software
doesn't have someone watching it.
I agree that an allocation failure in strdup() is unlikely. Are you
suggesting that that means you needn't bother checking the result?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-03-13 09:50 +0000 |
| Subject | Re: avoiding strdup() |
| Message-ID | <usrst4$sqrc$1@dont-email.me> |
| In reply to | #383562 |
On 12/03/2024 22:31, Keith Thompson wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >> On 12/03/2024 01:20, Keith Thompson wrote: >>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > [...] >>> If I withdraw 20 pounds from my bank, I'll bet you that 20 pounds >>> that the bank still checks whether it has the money. I'd rather >>> write correct code than code that almost certainly happens to work. >>> Sure, strdup() is unlikely to fail-- but I'm going to check the >>> result. >>> >>>> And how often do banks fail, actually, and how often does government >>>> take action when it's heading that way, but nowhere near failing yet? >>> The government isn't going to intervene when your laptop is running >>> low on memory. >>> >> No, it's an analogy. You run lots of apps gobbling lots of memory, and >> maybe a program won't launch or thngs start to slow or a warning comes >> up, and you realise that soon the program of interest might run out of >> memory, and so you shut other things down so that that doesn't happen. >> And so it's pretty rare to actually run out of memory unless the >> program isn't correct and there is a leak. > > Are you relying in a person sitting in front of the computer and > noticing that memory is running low? The vast majority of software > doesn't have someone watching it. > The server runs out of memory once. Sometimes yes, it's "these things happen, just get it back up". But more often. it's "Can't have that happening again. Shut something else down we don;t really need, or maybe buy an extra 2GB. Only ten dollars after all." > I agree that an allocation failure in strdup() is unlikely. Are you > suggesting that that means you needn't bother checking the result? > If it's genuinely the case that an electrical faiure is more likely, is there a really a point? But for my code, the test would go in, because it usually is intended to last for a very long time, and small memory machines might come back into fashion (eg smaller but very cheap and very fast, or maybe it will be used in an embedded system) -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
Page 8 of 12 — ← Prev page 1 … 6 7 [8] 9 10 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web