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 7 of 12 — ← Prev page 1 … 5 6 [7] 8 9 … 12 Next page →
| From | Richard Harnden <richard.nospam@gmail.invalid> |
|---|---|
| Date | 2024-03-10 19:07 +0000 |
| Subject | Re: [OT] UTF-8 sig. |
| Message-ID | <usl0ds$347ev$1@dont-email.me> |
| In reply to | #383505 |
On 10/03/2024 14:03, Ben Bacarisse wrote: > Richard Harnden <richard.nospam@gmail.invalid> writes: > >> On 09/03/2024 10:40, Ben wrote: >>> [working sig] >> >> Since you have utf8/ipa working, I don't suppose you could say how to >> pronounce your surname? I know I get it wrong. I'm pretty sure I don't >> even get close. > > In English: 'bækəriːs, in French more like baka'ris. (IPA looks horrid > in most software because a mixture of fonts is often used.) > Thanks.
[toc] | [prev] | [next] | [standalone]
| From | Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> |
|---|---|
| Date | 2024-03-09 12:25 +0000 |
| Subject | Re: [OT] UTF-8 sig. |
| Message-ID | <pan$be9e9$95150fd$ee371059$7d065ee9@invalid.invalid> |
| In reply to | #383485 |
Ben wrote: > On Sat, 9 Mar 2024 06:27:44 -0000 (UTC), Blue-Maned_Hawk wrote: > >> Ben wrote: >> >>> On Thu, 7 Mar 2024 06:48:19 -0000 (UTC), Blue-Maned_Hawk wrote: >>> >>>> Ben Bacarisse wrote: >>>> >>>>> Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes: >>>>> <cut> >>>>> >>>>> Since you are clearly happy to post using UTF-8, can I urge you to >>>>> fix your sig so that it comes out looking right? >>>> >>>> Since it is my newsreader that is corrupting it, it is the fault of >>>> the newsreader, >>> >>> I don't think that's the case. Here is a test post using the same >>> newsreader and something that is probably close to what you want in >>> your sig. (Yours is too messed up for me to work out exactly what you >>> want it to look like.) I should have replied to this bit earlier: it intentionally does not use the polebar character because the spaces required on each side of each would make the first line not fit the standard format. >>> >>> >> It does not happen immediately; instead, the signature that the >> software saves gets more and more corrupted each time the software is >> opened. > > Do you mean the problem is not with Pan after all? "The software" is > deliberately vague and I don't know why Pan would be saving the > signature file. It just reads it as far as I can tell. No, the problem is definitely with Pan. I don't know why it would be saving the signature file either, but it is. -- Blue-Maned_HawkÃÃÃÃâshortens to HawkÃÃÃÃâ/ blu.mÃin.dÃÃÃÃÃðak/ ÃÃÃÃâhe/him/his/himself/Mr. blue-maned_hawk.srht.site a
[toc] | [prev] | [next] | [standalone]
| From | Richard Harnden <richard.nospam@gmail.invalid> |
|---|---|
| Date | 2024-03-09 13:11 +0000 |
| Subject | Re: [OT] UTF-8 sig. |
| Message-ID | <ushn58$2b111$1@dont-email.me> |
| In reply to | #383488 |
On 09/03/2024 12:25, Blue-Maned_Hawk wrote: > Ben wrote: > >> On Sat, 9 Mar 2024 06:27:44 -0000 (UTC), Blue-Maned_Hawk wrote: >> >>> Ben wrote: >>> >>>> On Thu, 7 Mar 2024 06:48:19 -0000 (UTC), Blue-Maned_Hawk wrote: >>>> >>>>> Ben Bacarisse wrote: >>>>> >>>>>> Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes: >>>>>> <cut> >>>>>> >>>>>> Since you are clearly happy to post using UTF-8, can I urge you to >>>>>> fix your sig so that it comes out looking right? >>>>> >>>>> Since it is my newsreader that is corrupting it, it is the fault of >>>>> the newsreader, >>>> >>>> I don't think that's the case. Here is a test post using the same >>>> newsreader and something that is probably close to what you want in >>>> your sig. (Yours is too messed up for me to work out exactly what you >>>> want it to look like.) > > I should have replied to this bit earlier: it intentionally does not use > the polebar character because the spaces required on each side of each > would make the first line not fit the standard format. Polebar? You mean pipe? You are being anal about kerning, but you are happy to post with a sig that no one can read and doesn't format correctly. > >>>> >>>> >>> It does not happen immediately; instead, the signature that the >>> software saves gets more and more corrupted each time the software is >>> opened. >> >> Do you mean the problem is not with Pan after all? "The software" is >> deliberately vague and I don't know why Pan would be saving the >> signature file. It just reads it as far as I can tell. > > No, the problem is definitely with Pan. I don't know why it would be > saving the signature file either, but it is. > I think Ben has shown that it doesn't.
[toc] | [prev] | [next] | [standalone]
| From | Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> |
|---|---|
| Date | 2024-03-09 23:13 +0000 |
| Subject | Re: [OT] UTF-8 sig. |
| Message-ID | <pan$93b45$a0fec3b2$4b634941$f22437e@invalid.invalid> |
| In reply to | #383490 |
Richard Harnden wrote: > On 09/03/2024 12:25, Blue-Maned_Hawk wrote: >> Ben wrote: >> >>> On Sat, 9 Mar 2024 06:27:44 -0000 (UTC), Blue-Maned_Hawk wrote: >>> >>>> Ben wrote: >>>> >>>>> On Thu, 7 Mar 2024 06:48:19 -0000 (UTC), Blue-Maned_Hawk wrote: >>>>> >>>>>> Ben Bacarisse wrote: >>>>>> >>>>>>> Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes: >>>>>>> <cut> >>>>>>> >>>>>>> Since you are clearly happy to post using UTF-8, can I urge you to >>>>>>> fix your sig so that it comes out looking right? >>>>>> >>>>>> Since it is my newsreader that is corrupting it, it is the fault of >>>>>> the newsreader, >>>>> >>>>> I don't think that's the case. Here is a test post using the same >>>>> newsreader and something that is probably close to what you want in >>>>> your sig. (Yours is too messed up for me to work out exactly what >>>>> you want it to look like.) >> >> I should have replied to this bit earlier: it intentionally does not >> use the polebar character because the spaces required on each side of >> each would make the first line not fit the standard format. > > Polebar? You mean pipe? > > You are being anal about kerning, but you are happy to post with a sig > that no one can read and doesn't format correctly. > The kerning 'round the polebar would have been my own fault instead of the fault of the software. >> >>>>> >>>> It does not happen immediately; instead, the signature that the >>>> software saves gets more and more corrupted each time the software is >>>> opened. >>> >>> Do you mean the problem is not with Pan after all? "The software" is >>> deliberately vague and I don't know why Pan would be saving the >>> signature file. It just reads it as far as I can tell. >> >> No, the problem is definitely with Pan. I don't know why it would be >> saving the signature file either, but it is. >> >> > I think Ben has shown that it doesn't. Well, that clearly isn't true. -- Blue-Maned_Hawk│shortens to Hawk│/blu.mɛin.dʰak/│he/him/his/himself/Mr. blue-maned_hawk.srht.site “Ding me.” “No!”
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2024-03-10 00:13 +0000 |
| Subject | Re: [OT] UTF-8 sig. |
| Message-ID | <87o7bngczx.fsf@bsb.me.uk> |
| In reply to | #383490 |
Richard Harnden <richard.nospam@gmail.invalid> writes: > On 09/03/2024 12:25, Blue-Maned_Hawk wrote: >> Ben wrote: ... >>>>> On Thu, 7 Mar 2024 06:48:19 -0000 (UTC), Blue-Maned_Hawk wrote: >>>> It does not happen immediately; instead, the signature that the >>>> software saves gets more and more corrupted each time the software is >>>> opened. >>> >>> Do you mean the problem is not with Pan after all? "The software" is >>> deliberately vague and I don't know why Pan would be saving the >>> signature file. It just reads it as far as I can tell. >> >> No, the problem is definitely with Pan. I don't know why it would be >> saving the signature file either, but it is. > > I think Ben has shown that it doesn't. I think BMH is not using a sig file. The bottom line is that pan can do what BMH wants, but he's doing something that does not work. Unfortunately his explanation is unhelpful because his sig (as posted) is not getting "more and more corrupted" so it's not at all clear what he's seeing. I've tried /not/ using a sig file and that also seems to work. The posting.xml configuration file /is/ written every time pan closes, but it appears not to be getting corrupted. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-03-10 10:17 +0200 |
| Subject | Re: [OT] UTF-8 sig. |
| Message-ID | <20240310101757.0000345c@yahoo.com> |
| In reply to | #383498 |
On Sun, 10 Mar 2024 00:13:38 +0000 Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > Richard Harnden <richard.nospam@gmail.invalid> writes: > > > On 09/03/2024 12:25, Blue-Maned_Hawk wrote: > >> Ben wrote: > ... > >>>>> On Thu, 7 Mar 2024 06:48:19 -0000 (UTC), Blue-Maned_Hawk wrote: > >>>>> > >>>> It does not happen immediately; instead, the signature that the > >>>> software saves gets more and more corrupted each time the > >>>> software is opened. > >>> > >>> Do you mean the problem is not with Pan after all? "The > >>> software" is deliberately vague and I don't know why Pan would be > >>> saving the signature file. It just reads it as far as I can > >>> tell. > >> > >> No, the problem is definitely with Pan. I don't know why it would > >> be saving the signature file either, but it is. > > > > I think Ben has shown that it doesn't. > > I think BMH is not using a sig file. The bottom line is that pan can > do what BMH wants, but he's doing something that does not work. > Unfortunately his explanation is unhelpful because his sig (as posted) > is not getting "more and more corrupted" so it's not at all clear what > he's seeing. > > I've tried /not/ using a sig file and that also seems to work. The > posting.xml configuration file /is/ written every time pan closes, but > it appears not to be getting corrupted. > According to my understanding, one of his requirements is automatic attachment of random rude phrase to the end of the signature. Does your solution handle that?
[toc] | [prev] | [next] | [standalone]
| From | Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> |
|---|---|
| Date | 2024-03-10 13:35 +0000 |
| Subject | Re: [OT] UTF-8 sig. |
| Message-ID | <pan$16cc$8518f248$b52c2230$c54d4506@invalid.invalid> |
| In reply to | #383501 |
Michael S wrote: > According to my understanding, one of his requirements is automatic > attachment of random rude phrase to the end of the signature. > Does your solution handle that? I do that manually, and i do not mean the phrases to be rude—if one of them's been, please let me know and i'll prune it from further selection. -- Blue-Maned_Hawk│shortens to Hawk│/blu.mɛin.dʰak/│he/him/his/himself/Mr. blue-maned_hawk.srht.site Ain't nobody's seen nothin' like that!
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-03-10 17:15 +0000 |
| Subject | Re: [OT] UTF-8 sig. |
| Message-ID | <20240310101349.261@kylheku.com> |
| In reply to | #383501 |
On 2024-03-10, Michael S <already5chosen@yahoo.com> wrote: > According to my understanding, one of his requirements is automatic > attachment of random rude phrase to the end of the signature. > Does your solution handle that? You can run a cron job that updates the signature file with random content once every so many minutes. Probably daily would be fine. -- 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 | vallor <vallor@cultnix.org> |
|---|---|
| Date | 2024-03-09 13:19 +0000 |
| Subject | avoiding strdup() (was: Re: [OT] UTF-8 sig.) |
| Message-ID | <ushnkb$1rnlb$4@dont-email.me> |
| In reply to | #383485 |
On Sat, 9 Mar 2024 10:40:07 -0000 (UTC), Ben <ben.usenet@bsb.me.uk> wrote
in <ushea7$28prq$2@dont-email.me>:
> On Sat, 9 Mar 2024 06:27:44 -0000 (UTC), Blue-Maned_Hawk wrote:
>
>> Ben wrote:
>>
>>> On Thu, 7 Mar 2024 06:48:19 -0000 (UTC), Blue-Maned_Hawk wrote:
>>>
>>>> Ben Bacarisse wrote:
>>>>
>>>>> Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
>>>>> <cut>
>>>>>
>>>>> Since you are clearly happy to post using UTF-8, can I urge you to
>>>>> fix your sig so that it comes out looking right?
>>>>
>>>> Since it is my newsreader that is corrupting it, it is the fault of
>>>> the newsreader,
>>>
>>> I don't think that's the case. Here is a test post using the same
>>> newsreader and something that is probably close to what you want in
>>> your sig. (Yours is too messed up for me to work out exactly what you
>>> want it to look like.)
>>>
>>>
>> It does not happen immediately; instead, the signature that the
>> software saves gets more and more corrupted each time the software is
>> opened.
>
> Do you mean the problem is not with Pan after all? "The software" is
> deliberately vague and I don't know why Pan would be saving the
> signature file. It just reads it as far as I can tell.
>
> --
> /blu.mɛin.dʰak/ | shortens to "Hawk" | he/him/his/himself/Mr.
Perhaps he is using a "Text" type signature, instead of a "Text File"
type signature?
(Would love to discuss it, but in news.software.readers.)
ObC:
Gradually being dragged into the new millenium, where I'm
comfortable with the following:
char something[] = "writable string initializer";
And gcc has -fsanitize=address -- a lovely thing to behold
if it fires off.
Meanwhile, saw someone in another group write:
char * something;
something = strdup("writable string etc.");
if( something == NULL ) { etc. }
But that won't work if --std=c99, does work for g99 and c2x.
The (Linux) man page says:
/* Since glibc 2.12: */ _POSIX_C_SOURCE >= 200809L
I asked Google about it being a POSIX extension
added at that late date, and it gave me an answer
about the C standard:
"C9X London meeting update"
https://groups.google.com/g/comp.std.c/c/pMaEU_8Rb7w
_ _ _ _ _
2. strsep and strdup are not being added. strsep() is out because
not enough people wanted it to vote it in; strdup() lost on the
grounds that it would be the *ONLY* function other than *alloc()
in the entire library whose return could be sanely passed to free(),
and this is surprising.
_ _ _ _ _
Also: <https://stackoverflow.com/questions/32944390/what-is-the-rationale-
for-not-including-strdup-in-the-c-standard>
Anyway, pointed out that they can just use an initializer, something
about which I was clued in by a friendly person in this very group.
--
-v
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2024-03-09 15:25 +0000 |
| Subject | Re: avoiding strdup() |
| Message-ID | <AvZ1AG=nEY26QTs5J@bongo-ra.co> |
| In reply to | #383491 |
On Sat, 9 Mar 2024 13:19:07 -0000 (UTC)
vallor <vallor@cultnix.org> wrote:
> Meanwhile, saw someone in another group write:
>
> char * something;
> something = strdup("writable string etc.");
> if( something == NULL ) { etc. }
>
> But that won't work if --std=c99, does work for g99 and c2x.
> The (Linux) man page says:
> /* Since glibc 2.12: */ _POSIX_C_SOURCE >= 200809L
>
> I asked Google about it being a POSIX extension
> added at that late date, and it gave me an answer
> about the C standard:
>
> "C9X London meeting update"
> https://groups.google.com/g/comp.std.c/c/pMaEU_8Rb7w
> _ _ _ _ _
> 2. strsep and strdup are not being added. strsep() is out because
> not enough people wanted it to vote it in; strdup() lost on the
> grounds that it would be the *ONLY* function other than *alloc()
> in the entire library whose return could be sanely passed to free(),
> and this is surprising.
The design of strsep() is poor. The reasoning for not adding strdup()
doesn't make any sense to me.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-03-09 16:37 -0800 |
| Subject | Re: avoiding strdup() |
| Message-ID | <87r0gizzuo.fsf@nosuchdomain.example.com> |
| In reply to | #383491 |
vallor <vallor@cultnix.org> writes:
[...]
> Meanwhile, saw someone in another group write:
>
> char * something;
> something = strdup("writable string etc.");
> if( something == NULL ) { etc. }
>
> But that won't work if --std=c99, does work for g99 and c2x.
> The (Linux) man page says:
> /* Since glibc 2.12: */ _POSIX_C_SOURCE >= 200809L
>
> I asked Google about it being a POSIX extension
> added at that late date, and it gave me an answer
> about the C standard:
>
> "C9X London meeting update"
> https://groups.google.com/g/comp.std.c/c/pMaEU_8Rb7w
> _ _ _ _ _
> 2. strsep and strdup are not being added. strsep() is out because
> not enough people wanted it to vote it in; strdup() lost on the
> grounds that it would be the *ONLY* function other than *alloc()
> in the entire library whose return could be sanely passed to free(),
> and this is surprising.
> _ _ _ _ _
>
> Also: <https://stackoverflow.com/questions/32944390/what-is-the-rationale-
> for-not-including-strdup-in-the-c-standard>
>
> Anyway, pointed out that they can just use an initializer, something
> about which I was clued in by a friendly person in this very group.
strdup() and strndup() are being added to the C23 standard.
--
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 | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-03-10 10:11 +0200 |
| Subject | Re: avoiding strdup() |
| Message-ID | <20240310101101.00001fd4@yahoo.com> |
| In reply to | #383499 |
On Sat, 09 Mar 2024 16:37:19 -0800
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> vallor <vallor@cultnix.org> writes:
> [...]
> > Meanwhile, saw someone in another group write:
> >
> > char * something;
> > something = strdup("writable string etc.");
> > if( something == NULL ) { etc. }
> >
> > But that won't work if --std=c99, does work for g99 and c2x.
> > The (Linux) man page says:
> > /* Since glibc 2.12: */ _POSIX_C_SOURCE >= 200809L
> >
> > I asked Google about it being a POSIX extension
> > added at that late date, and it gave me an answer
> > about the C standard:
> >
> > "C9X London meeting update"
> > https://groups.google.com/g/comp.std.c/c/pMaEU_8Rb7w
> > _ _ _ _ _
> > 2. strsep and strdup are not being added. strsep() is out because
> > not enough people wanted it to vote it in; strdup() lost on the
> > grounds that it would be the *ONLY* function other than *alloc()
> > in the entire library whose return could be sanely passed to free(),
> > and this is surprising.
> > _ _ _ _ _
> >
> > Also:
> > <https://stackoverflow.com/questions/32944390/what-is-the-rationale-
> > for-not-including-strdup-in-the-c-standard>
> >
> > Anyway, pointed out that they can just use an initializer, something
> > about which I was clued in by a friendly person in this very group.
> >
>
> strdup() and strndup() are being added to the C23 standard.
>
What is justification?
What strdup() can do better, for any chosen value of better, than
strlen()+malloc()+memcpy() ?
[toc] | [prev] | [next] | [standalone]
| From | Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> |
|---|---|
| Date | 2024-03-10 13:38 +0000 |
| Subject | Re: avoiding strdup() |
| Message-ID | <pan$3ee01$922a1812$90fc3f75$bda42845@invalid.invalid> |
| In reply to | #383500 |
Michael S wrote: > What strdup() can do better, for any chosen value of better, than > strlen()+malloc()+memcpy() ? It's shorter. -- Blue-Maned_Hawk│shortens to Hawk│/blu.mɛin.dʰak/│he/him/his/himself/Mr. blue-maned_hawk.srht.site The logical conclusion of “don't repeat yourself” is to never say anything.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-03-10 17:12 +0000 |
| Subject | Re: avoiding strdup() |
| Message-ID | <20240310100715.866@kylheku.com> |
| In reply to | #383500 |
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. -- 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-10 18:47 +0000 |
| Subject | Re: avoiding strdup() |
| Message-ID | <ifnHN.386274$vFZa.250421@fx13.iad> |
| In reply to | #383506 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Richard Harnden <richard.nospam@gmail.invalid> |
|---|---|
| Date | 2024-03-10 19:20 +0000 |
| Subject | Re: avoiding strdup() |
| Message-ID | <usl150$347ev$2@dont-email.me> |
| In reply to | #383508 |
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. The hidden use of malloc was one of the reasons it was left out of the standard library.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-03-11 16:23 +0000 |
| Subject | Re: avoiding strdup() |
| Message-ID | <usnb64$3n297$1@dont-email.me> |
| In reply to | #383508 |
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. -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-03-11 18:50 +0200 |
| Subject | Re: avoiding strdup() |
| Message-ID | <20240311185039.000066fc@yahoo.com> |
| In reply to | #383511 |
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.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-03-11 17:05 +0000 |
| Subject | Re: avoiding strdup() |
| Message-ID | <ERGHN.481215$PuZ9.417692@fx11.iad> |
| In reply to | #383512 |
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. 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.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-03-11 19:35 +0200 |
| Subject | Re: avoiding strdup() |
| Message-ID | <20240311193511.0000610f@yahoo.com> |
| In reply to | #383514 |
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. 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 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.
[toc] | [prev] | [next] | [standalone]
Page 7 of 12 — ← Prev page 1 … 5 6 [7] 8 9 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web