Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.misc > #68776 > unrolled thread
| Started by | c186282 <c186282@nnada.net> |
|---|---|
| First post | 2025-06-14 01:15 -0400 |
| Last post | 2025-06-19 06:36 +0000 |
| Articles | 20 on this page of 230 — 17 participants |
Back to article view | Back to comp.os.linux.misc
VMS c186282 <c186282@nnada.net> - 2025-06-14 01:15 -0400
Re: VMS Bobbie Sellers <bliss-sf4ever@dslextreme.com> - 2025-06-14 10:05 -0700
Re: VMS Andreas Eder <a_eder_muc@web.de> - 2025-06-14 20:30 +0200
Re: VMS Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-14 23:27 +0000
Re: VMS rbowman <bowman@montana.com> - 2025-06-15 00:57 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-06-14 23:32 -0400
Re: VMS The Natural Philosopher <tnp@invalid.invalid> - 2025-06-15 08:26 +0100
Re: VMS c186282 <c186282@nnada.net> - 2025-06-15 21:12 -0400
Re: VMS Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2025-06-16 18:15 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-06-17 23:20 -0400
Re: VMS rbowman <bowman@montana.com> - 2025-06-18 04:14 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-06-18 02:34 -0400
Re: VMS rbowman <bowman@montana.com> - 2025-06-15 18:49 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-06-15 22:45 -0400
Re: VMS rbowman <bowman@montana.com> - 2025-06-16 04:35 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-06-16 01:35 -0400
Re: VMS c186282 <c186282@nnada.net> - 2025-06-14 23:03 -0400
Re: VMS candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-06-18 05:30 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-06-18 02:09 -0400
Re: VMS candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-06-18 19:00 +0000
Re: VMS Rich <rich@example.invalid> - 2025-06-18 20:23 +0000
Re: VMS Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2025-06-18 20:30 +0000
Re: VMS rbowman <bowman@montana.com> - 2025-06-18 23:09 +0000
Re: VMS Richard Kettlewell <invalid@invalid.invalid> - 2025-06-19 08:40 +0100
Re: VMS c186282 <c186282@nnada.net> - 2025-06-20 00:43 -0400
Re: VMS Richard Kettlewell <invalid@invalid.invalid> - 2025-06-20 09:00 +0100
Re: VMS The Natural Philosopher <tnp@invalid.invalid> - 2025-06-20 10:19 +0100
Re: VMS Richard Kettlewell <invalid@invalid.invalid> - 2025-06-20 15:15 +0100
Re: VMS Rich <rich@example.invalid> - 2025-06-20 13:36 +0000
Re: VMS The Natural Philosopher <tnp@invalid.invalid> - 2025-06-20 16:15 +0100
Re: VMS Rich <rich@example.invalid> - 2025-06-20 23:07 +0000
Re: VMS The Natural Philosopher <tnp@invalid.invalid> - 2025-06-21 01:07 +0100
Re: VMS rbowman <bowman@montana.com> - 2025-06-21 03:09 +0000
Re: VMS Robert Riches <spamtrap42@jacob21819.net> - 2025-06-21 03:43 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-06-21 01:36 -0400
Re: VMS rbowman <bowman@montana.com> - 2025-06-21 05:53 +0000
Re: VMS candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-06-22 13:50 +0000
Re: VMS Richard Kettlewell <invalid@invalid.invalid> - 2025-06-22 15:27 +0100
Re: VMS The Natural Philosopher <tnp@invalid.invalid> - 2025-06-22 15:56 +0100
Re: VMS c186282 <c186282@nnada.net> - 2025-06-23 00:18 -0400
Re: VMS rbowman <bowman@montana.com> - 2025-06-22 19:23 +0000
Re: VMS candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-06-23 18:10 +0000
Re: VMS rbowman <bowman@montana.com> - 2025-06-23 19:27 +0000
Re: VMS Robert Riches <spamtrap42@jacob21819.net> - 2025-06-24 03:34 +0000
Re: VMS Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2025-06-24 04:52 +0000
Re: VMS rbowman <bowman@montana.com> - 2025-06-24 05:14 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-06-24 01:36 -0400
Re: VMS rbowman <bowman@montana.com> - 2025-06-24 06:49 +0000
Re: VMS The Natural Philosopher <tnp@invalid.invalid> - 2025-06-24 10:31 +0100
Re: VMS c186282 <c186282@nnada.net> - 2025-06-25 01:36 -0400
Re: VMS The Natural Philosopher <tnp@invalid.invalid> - 2025-06-25 07:31 +0100
Re: VMS c186282 <c186282@nnada.net> - 2025-06-25 03:08 -0400
Re: VMS Richard Kettlewell <invalid@invalid.invalid> - 2025-06-24 08:56 +0100
Re: VMS Robert Riches <spamtrap42@jacob21819.net> - 2025-06-25 03:01 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-06-25 01:59 -0400
Re: VMS rbowman <bowman@montana.com> - 2025-06-25 06:52 +0000
Re: VMS Rich <rich@example.invalid> - 2025-07-20 14:31 +0000
Re: VMS John Ames <commodorejohn@gmail.com> - 2025-06-25 09:32 -0700
Re: VMS John Ames <commodorejohn@gmail.com> - 2025-06-25 09:44 -0700
Re: VMS c186282 <c186282@nnada.net> - 2025-06-25 19:01 -0400
Re: VMS Rich <rich@example.invalid> - 2025-07-20 14:37 +0000
Re: VMS Richard Kettlewell <invalid@invalid.invalid> - 2025-07-21 08:42 +0100
Re: VMS John Ames <commodorejohn@gmail.com> - 2025-07-21 09:12 -0700
Re: VMS Pancho <Pancho.Jones@protonmail.com> - 2025-07-21 18:44 +0100
Re: VMS Richard Kettlewell <invalid@invalid.invalid> - 2025-07-21 20:47 +0100
Re: VMS John Ames <commodorejohn@gmail.com> - 2025-07-21 13:31 -0700
Re: VMS Pancho <Pancho.Jones@protonmail.com> - 2025-07-23 07:22 +0100
Re: VMS John Ames <commodorejohn@gmail.com> - 2025-07-23 08:04 -0700
Re: VMS John Ames <commodorejohn@gmail.com> - 2025-07-23 08:44 -0700
Re: VMS The Natural Philosopher <tnp@invalid.invalid> - 2025-07-23 20:04 +0100
Re: VMS rbowman <bowman@montana.com> - 2025-07-23 22:47 +0000
Re: VMS The Natural Philosopher <tnp@invalid.invalid> - 2025-07-24 09:56 +0100
Re: VMS Pancho <Pancho.Jones@protonmail.com> - 2025-07-23 21:53 +0100
Re: VMS John Ames <commodorejohn@gmail.com> - 2025-07-23 14:28 -0700
Re: VMS Pancho <Pancho.Jones@protonmail.com> - 2025-07-24 00:29 +0100
Re: VMS John Ames <commodorejohn@gmail.com> - 2025-07-24 08:05 -0700
Re: VMS Richard Kettlewell <invalid@invalid.invalid> - 2025-07-24 21:51 +0100
Re: VMS John Ames <commodorejohn@gmail.com> - 2025-07-24 15:06 -0700
Re: VMS Pancho <Pancho.Jones@protonmail.com> - 2025-07-25 07:06 +0100
Re: VMS John Ames <commodorejohn@gmail.com> - 2025-07-25 10:39 -0700
Re: VMS Pancho <Pancho.Jones@protonmail.com> - 2025-07-26 17:54 +0100
Re: VMS The Natural Philosopher <tnp@invalid.invalid> - 2025-07-26 18:02 +0100
Re: VMS Robert Riches <spamtrap42@jacob21819.net> - 2025-07-27 04:04 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-07-27 01:50 -0400
Re: VMS The Natural Philosopher <tnp@invalid.invalid> - 2025-07-27 12:07 +0100
Re: VMS Pancho <Pancho.Jones@protonmail.com> - 2025-07-27 10:23 +0100
Re: VMS Richard Kettlewell <invalid@invalid.invalid> - 2025-07-27 10:55 +0100
Re: VMS c186282 <c186282@nnada.net> - 2025-07-27 21:23 -0400
Re: VMS rbowman <bowman@montana.com> - 2025-07-28 04:45 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-07-28 02:14 -0400
Re: VMS The Natural Philosopher <tnp@invalid.invalid> - 2025-07-28 13:48 +0100
Re: VMS rbowman <bowman@montana.com> - 2025-07-28 20:38 +0000
Re: VMS rbowman <bowman@montana.com> - 2025-07-28 20:32 +0000
Re: VMS Bobbie Sellers <bliss-sf4ever@dslextreme.com> - 2025-07-28 14:17 -0700
Re: VMS rbowman <bowman@montana.com> - 2025-07-29 05:08 +0000
Re: VMS The Natural Philosopher <tnp@invalid.invalid> - 2025-07-28 13:44 +0100
Re: VMS The Natural Philosopher <tnp@invalid.invalid> - 2025-07-28 13:39 +0100
Re: VMS Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-07-29 01:03 +0000
Re: VMS rbowman <bowman@montana.com> - 2025-07-29 05:29 +0000
Re: VMS The Natural Philosopher <tnp@invalid.invalid> - 2025-07-29 11:42 +0100
Re: VMS rbowman <bowman@montana.com> - 2025-07-29 19:16 +0000
Re: VMS Pancho <Pancho.Jones@protonmail.com> - 2025-07-29 12:10 +0100
Re: VMS The Natural Philosopher <tnp@invalid.invalid> - 2025-07-29 13:08 +0100
Re: VMS Bobbie Sellers <bliss-sf4ever@dslextreme.com> - 2025-07-29 09:51 -0700
Re: VMS rbowman <bowman@montana.com> - 2025-07-29 18:53 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-07-29 04:51 -0400
Re: VMS Rich <rich@example.invalid> - 2025-07-29 13:32 +0000
Re: VMS John Ames <commodorejohn@gmail.com> - 2025-07-28 09:22 -0700
Re: VMS The Natural Philosopher <tnp@invalid.invalid> - 2025-07-27 12:11 +0100
Re: VMS Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-07-27 22:02 +0000
Re: VMS rbowman <bowman@montana.com> - 2025-07-28 04:58 +0000
Re: VMS Stéphane CARPENTIER <sc@fiat-linux.fr> - 2025-08-01 19:13 +0000
Re: VMS Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2025-08-01 20:38 +0000
Re: VMS Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-02 00:01 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-08-02 02:24 -0400
Re: VMS Pancho <Pancho.Jones@protonmail.com> - 2025-08-02 11:34 +0100
Re: VMS c186282 <c186282@nnada.net> - 2025-08-02 21:02 -0400
Re: VMS Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-03 02:08 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-08-03 01:00 -0400
Re: VMS Stéphane CARPENTIER <sc@fiat-linux.fr> - 2025-08-09 10:26 +0000
Re: VMS rbowman <bowman@montana.com> - 2025-08-09 20:00 +0000
Re: VMS Stéphane CARPENTIER <sc@fiat-linux.fr> - 2025-08-09 10:19 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-07-27 21:31 -0400
Re: VMS rbowman <bowman@montana.com> - 2025-07-28 05:03 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-07-28 02:19 -0400
Re: VMS c186282 <c186282@nnada.net> - 2025-07-27 21:09 -0400
Re: VMS John Ames <commodorejohn@gmail.com> - 2025-07-28 10:17 -0700
Re: VMS rbowman <bowman@montana.com> - 2025-07-28 20:46 +0000
Re: VMS John Ames <commodorejohn@gmail.com> - 2025-07-28 14:34 -0700
Re: VMS Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2025-07-28 16:34 +0000
Re: VMS rbowman <bowman@montana.com> - 2025-07-28 20:48 +0000
Re: VMS Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-07-29 01:00 +0000
Re: VMS Pancho <Pancho.Jones@protonmail.com> - 2025-07-29 10:07 +0100
Re: VMS Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-07-29 23:05 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-07-30 02:43 -0400
Re: VMS Andreas Eder <a_eder_muc@web.de> - 2025-08-02 18:11 +0200
Re: VMS Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2025-07-24 14:42 +0000
Re: VMS rbowman <bowman@montana.com> - 2025-07-24 18:05 +0000
Re: VMS John Ames <commodorejohn@gmail.com> - 2025-07-24 11:14 -0700
Re: VMS rbowman <bowman@montana.com> - 2025-07-24 23:10 +0000
Re: VMS Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-07-24 21:16 +0000
Re: VMS rbowman <bowman@montana.com> - 2025-07-24 23:21 +0000
Re: VMS John Ames <commodorejohn@gmail.com> - 2025-07-21 14:05 -0700
Re: VMS Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2025-07-21 21:14 +0000
Re: VMS The Natural Philosopher <tnp@invalid.invalid> - 2025-07-21 22:19 +0100
Re: VMS rbowman <bowman@montana.com> - 2025-07-22 02:10 +0000
Re: VMS candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-06-27 06:00 +0000
Re: VMS Richard Kettlewell <invalid@invalid.invalid> - 2025-06-27 08:37 +0100
Re: VMS The Natural Philosopher <tnp@invalid.invalid> - 2025-06-27 08:45 +0100
Re: VMS Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-27 08:14 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-06-27 13:27 -0400
Re: VMS The Natural Philosopher <tnp@invalid.invalid> - 2025-06-27 19:13 +0100
Re: VMS Chris Ahlstrom <OFeem1987@teleworm.us> - 2025-06-28 09:16 -0400
Re: VMS c186282 <c186282@nnada.net> - 2025-06-27 13:24 -0400
Re: VMS rbowman <bowman@montana.com> - 2025-06-27 17:40 +0000
Re: VMS Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2025-06-27 18:20 +0000
Re: VMS Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-27 23:03 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-06-28 01:13 -0400
Re: VMS rbowman <bowman@montana.com> - 2025-06-28 06:10 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-06-27 18:16 -0400
Re: VMS Richard Kettlewell <invalid@invalid.invalid> - 2025-06-28 08:52 +0100
Re: VMS c186282 <c186282@nnada.net> - 2025-06-28 23:16 -0400
Re: VMS Richard Kettlewell <invalid@invalid.invalid> - 2025-06-29 08:18 +0100
Re: VMS c186282 <c186282@nnada.net> - 2025-06-29 19:09 -0400
Re: VMS The Natural Philosopher <tnp@invalid.invalid> - 2025-06-30 08:36 +0100
Re: VMS Richard Kettlewell <invalid@invalid.invalid> - 2025-06-30 08:51 +0100
Re: VMS The Natural Philosopher <tnp@invalid.invalid> - 2025-06-30 08:59 +0100
Re: VMS Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-30 08:33 +0000
Re: VMS John Ames <commodorejohn@gmail.com> - 2025-06-30 09:08 -0700
Re: VMS jayjwa <jayjwa@atr2.ath.cx.invalid> - 2025-06-30 22:18 -0400
Re: VMS Richard Kettlewell <invalid@invalid.invalid> - 2025-06-30 09:00 +0100
Re: VMS The Natural Philosopher <tnp@invalid.invalid> - 2025-06-30 09:24 +0100
Re: VMS Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-30 08:34 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-06-30 23:30 -0400
Re: VMS c186282 <c186282@nnada.net> - 2025-06-30 23:26 -0400
Re: VMS The Natural Philosopher <tnp@invalid.invalid> - 2025-07-01 10:49 +0100
Re: VMS Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2025-07-01 12:44 +0000
Re: VMS Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2025-07-02 01:13 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-07-01 21:46 -0400
Re: VMS Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2025-07-02 16:03 +0000
Re: VMS Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-30 07:54 +0000
Re: VMS rbowman <bowman@montana.com> - 2025-06-30 18:10 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-06-30 23:12 -0400
Re: VMS rbowman <bowman@montana.com> - 2025-07-01 04:02 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-07-01 12:42 -0400
Re: VMS Richard Kettlewell <invalid@invalid.invalid> - 2025-06-30 08:56 +0100
Re: VMS Rich <rich@example.invalid> - 2025-07-20 14:42 +0000
Re: VMS Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2025-07-20 14:54 +0000
Re: VMS The Natural Philosopher <tnp@invalid.invalid> - 2025-07-20 16:51 +0100
Re: VMS Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2025-07-20 16:15 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-07-25 00:31 -0400
Re: VMS rbowman <bowman@montana.com> - 2025-07-25 05:53 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-07-25 05:05 -0400
Re: VMS The Natural Philosopher <tnp@invalid.invalid> - 2025-07-25 10:59 +0100
Re: VMS candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-07-25 16:20 +0000
Re: VMS Richard Kettlewell <invalid@invalid.invalid> - 2025-07-25 08:43 +0100
Re: VMS c186282 <c186282@nnada.net> - 2025-07-25 04:39 -0400
Re: VMS Richard Kettlewell <invalid@invalid.invalid> - 2025-07-20 21:18 +0100
Re: VMS Rich <rich@example.invalid> - 2025-06-27 19:40 +0000
Re: VMS Richard Kettlewell <invalid@invalid.invalid> - 2025-06-20 21:19 +0100
Re: VMS Rich <rich@example.invalid> - 2025-06-20 23:17 +0000
Re: VMS Richard Kettlewell <invalid@invalid.invalid> - 2025-06-21 08:42 +0100
Re: VMS Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-21 07:02 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-06-21 03:23 -0400
Re: VMS c186282 <c186282@nnada.net> - 2025-06-21 01:27 -0400
Re: VMS c186282 <c186282@nnada.net> - 2025-06-21 01:10 -0400
Re: VMS rbowman <bowman@montana.com> - 2025-06-21 05:59 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-06-21 02:10 -0400
Re: VMS The Natural Philosopher <tnp@invalid.invalid> - 2025-06-20 10:12 +0100
Re: VMS Rich <rich@example.invalid> - 2025-06-20 13:39 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-06-21 01:23 -0400
Re: VMS Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-21 06:57 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-06-21 03:07 -0400
Re: VMS Richard Kettlewell <invalid@invalid.invalid> - 2025-06-21 08:45 +0100
Re: VMS c186282 <c186282@nnada.net> - 2025-06-22 02:32 -0400
Re: VMS Rich <rich@example.invalid> - 2025-06-20 13:30 +0000
Re: VMS The Natural Philosopher <tnp@invalid.invalid> - 2025-06-20 16:14 +0100
Re: VMS Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-20 08:57 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-06-21 01:17 -0400
Re: VMS c186282 <c186282@nnada.net> - 2025-06-14 22:57 -0400
Re: VMS Rich <rich@example.invalid> - 2025-06-15 14:24 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-06-15 22:26 -0400
Re: VMS rbowman <bowman@montana.com> - 2025-06-16 04:30 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-06-16 01:31 -0400
Re: VMS Rich <rich@example.invalid> - 2025-06-18 17:40 +0000
Re: VMS rbowman <bowman@montana.com> - 2025-06-18 23:06 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-06-18 19:43 -0400
Re: VMS Rich <rich@example.invalid> - 2025-06-19 01:08 +0000
Re: VMS c186282 <c186282@nnada.net> - 2025-06-19 00:46 -0400
Re: VMS rbowman <bowman@montana.com> - 2025-06-19 06:36 +0000
Page 4 of 12 — ← Prev page 1 2 3 [4] 5 6 … 12 Next page →
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2025-07-20 14:37 +0000 |
| Message-ID | <105iv02$3cuhr$2@dont-email.me> |
| In reply to | #69145 |
c186282 <c186282@nnada.net> wrote: > On 6/25/25 12:44 PM, John Ames wrote: >> On Wed, 25 Jun 2025 09:32:13 -0700 >> John Ames <commodorejohn@gmail.com> wrote: >> >>>> Regardless, easy fix - always allocate at least one byte/word/ >>>> whatever more than you THINK you need. Minimal penalty - possibly >>>> BIG gains. >>> >>> That strikes me as a terrible strategy - allocating N elements extra >>> won't save you from overstepping into N+1 if and when you finally do >> >> (Additionally, it won't save you from whatever weird undefined behavior >> may result from reading an element N which isn't even part of the >> "true" range and may have uninitialized/invalid data.) > > I've had good luck doing it that way since K&R. > Doesn't hurt to null the entire space after > allocating. Leave a speck of extra space and > it covers a lot of potential little write > issues. You still have to take care when reading. The problem, which John correctly pointed out, is that if the programmer is sloppy enough that this little extra "saves" them today, then it is still a ticking time bomb waiting to go off when someone futzes the code later and instead of the expected entry of a "serial number" of 8 digits and a buffer of 16 bytes, the futzer inserts 9, 10, 11, 12, 13, 14, 15, 16, 17 (boom). Allocating "a little extra" is a feel good way to presume one is avoiding buffer overflow issues, but it does nothing to actually prevent them from going boom. And note, that 'futzing' might not be by an actual code futzer. It might just be a normal every day user who picked up the wrong invoice that had a 17 digit serial on it instead of the correct invoice that had the expected 8 digit serial.
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <invalid@invalid.invalid> |
|---|---|
| Date | 2025-07-21 08:42 +0100 |
| Message-ID | <wwvzfcy0z3n.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #69776 |
Rich <rich@example.invalid> writes: > The problem, which John correctly pointed out, is that if the > programmer is sloppy enough that this little extra "saves" them today, > then it is still a ticking time bomb waiting to go off when someone > futzes the code later and instead of the expected entry of a "serial > number" of 8 digits and a buffer of 16 bytes, the futzer inserts 9, 10, > 11, 12, 13, 14, 15, 16, 17 (boom). > > Allocating "a little extra" is a feel good way to presume one is > avoiding buffer overflow issues, but it does nothing to actually > prevent them from going boom. Conservative upper bounds of this kind address two issues: 1) The possibility that you made a mistake in working out the upper bound. Off-by-one errors are such a common category that they get their own name; adding even 1 byte of headroom neutralizes them. If you think only “sloppy” programmers make this kind of mistake then you’re deluded. A more competent programmer may make fewer mistakes but no human is perfect. 2) Approximation can make analysis easier. Why spend an hour proving that the maximum size something can be is 37 bytes if a few seconds mental arithmetic will prove it’s at most 64 bytes? (Unless you have 1980s quantities of RAM, of course.) -- https://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | John Ames <commodorejohn@gmail.com> |
|---|---|
| Date | 2025-07-21 09:12 -0700 |
| Message-ID | <20250721091242.00007573@gmail.com> |
| In reply to | #69802 |
On Mon, 21 Jul 2025 08:42:04 +0100 Richard Kettlewell <invalid@invalid.invalid> wrote: > Conservative upper bounds of this kind address two issues: > > 1) The possibility that you made a mistake in working out the upper > bound. Off-by-one errors are such a common category that they get > their own name; adding even 1 byte of headroom neutralizes them. > > If you think only “sloppy” programmers make this kind of mistake > then you’re deluded. A more competent programmer may make fewer > mistakes but no human is perfect. > > 2) Approximation can make analysis easier. Why spend an hour proving > that the maximum size something can be is 37 bytes if a few seconds > mental arithmetic will prove it’s at most 64 bytes? (Unless you > have 1980s quantities of RAM, of course.) Sure, memory is cheap and we can often afford reasonably over-specced buffer sizes in Our Modern Age - but the fundamental problem remains. Treating "a little extra just to be on the safe side" as a ward against buffer overruns or other boundary errors is pretty much guaranteed to run into trouble down the line, and no amount of "nobody's perfect...!" will change that. If you're not working in a language that does bounds- checking for you, and your design is not one where you can say with *100% certainty* that boundary errors are literally impossible, CHECK YER DANG BOUNDS. Simple as that.
[toc] | [prev] | [next] | [standalone]
| From | Pancho <Pancho.Jones@protonmail.com> |
|---|---|
| Date | 2025-07-21 18:44 +0100 |
| Message-ID | <105lu95$2a92$1@dont-email.me> |
| In reply to | #69811 |
On 7/21/25 17:12, John Ames wrote: > On Mon, 21 Jul 2025 08:42:04 +0100 > Richard Kettlewell <invalid@invalid.invalid> wrote: > >> Conservative upper bounds of this kind address two issues: >> >> 1) The possibility that you made a mistake in working out the upper >> bound. Off-by-one errors are such a common category that they get >> their own name; adding even 1 byte of headroom neutralizes them. >> >> If you think only “sloppy” programmers make this kind of mistake >> then you’re deluded. A more competent programmer may make fewer >> mistakes but no human is perfect. >> >> 2) Approximation can make analysis easier. Why spend an hour proving >> that the maximum size something can be is 37 bytes if a few seconds >> mental arithmetic will prove it’s at most 64 bytes? (Unless you >> have 1980s quantities of RAM, of course.) > > Sure, memory is cheap and we can often afford reasonably over-specced > buffer sizes in Our Modern Age - but the fundamental problem remains. > Treating "a little extra just to be on the safe side" as a ward against > buffer overruns or other boundary errors is pretty much guaranteed to > run into trouble down the line, and no amount of "nobody's perfect...!" > will change that. If you're not working in a language that does bounds- > checking for you, and your design is not one where you can say with > *100% certainty* that boundary errors are literally impossible, CHECK > YER DANG BOUNDS. Simple as that. > An upper bound is certain. It is a fundamental concept in mathematical proofs. It is not just giving a bit extra and hoping for the best.
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <invalid@invalid.invalid> |
|---|---|
| Date | 2025-07-21 20:47 +0100 |
| Message-ID | <wwvms8x5nsk.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #69811 |
John Ames <commodorejohn@gmail.com> writes: > On Mon, 21 Jul 2025 08:42:04 +0100 > Richard Kettlewell <invalid@invalid.invalid> wrote: > >> Conservative upper bounds of this kind address two issues: >> >> 1) The possibility that you made a mistake in working out the upper >> bound. Off-by-one errors are such a common category that they get >> their own name; adding even 1 byte of headroom neutralizes them. >> >> If you think only “sloppy” programmers make this kind of mistake >> then you’re deluded. A more competent programmer may make fewer >> mistakes but no human is perfect. >> >> 2) Approximation can make analysis easier. Why spend an hour proving >> that the maximum size something can be is 37 bytes if a few seconds >> mental arithmetic will prove it’s at most 64 bytes? (Unless you >> have 1980s quantities of RAM, of course.) > > Sure, memory is cheap and we can often afford reasonably over-specced > buffer sizes in Our Modern Age - but the fundamental problem remains. > Treating "a little extra just to be on the safe side" as a ward against > buffer overruns or other boundary errors is pretty much guaranteed to > run into trouble down the line, and no amount of "nobody's perfect...!" > will change that. If you're not working in a language that does bounds- > checking for you, and your design is not one where you can say with > *100% certainty* that boundary errors are literally impossible, CHECK > YER DANG BOUNDS. Simple as that. In real life a buffer overrun is not the only outcome to be avoided. If you need 20 bytes and you’ve only got 10, _something_ is going to go wrong. A bounds check will avoid the outcome being a buffer overrun, but you’re still going to have to report an error, or exit the program, or some other undesired behaviour, when what you actually wanted was the full 20-byte result. That’s what a conservative bound helps you with. -- https://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | John Ames <commodorejohn@gmail.com> |
|---|---|
| Date | 2025-07-21 13:31 -0700 |
| Message-ID | <20250721133148.00007cc6@gmail.com> |
| In reply to | #69818 |
On Mon, 21 Jul 2025 20:47:23 +0100 Richard Kettlewell <invalid@invalid.invalid> wrote: > In real life a buffer overrun is not the only outcome to be avoided. > If you need 20 bytes and you’ve only got 10, _something_ is going to > go wrong. A bounds check will avoid the outcome being a buffer > overrun, but you’re still going to have to report an error, or exit > the program, or some other undesired behaviour, when what you > actually wanted was the full 20-byte result. That’s what a > conservative bound helps you with. Sure - there's nothing wrong with "reserve a bit more than you think you'll need" in and of itself. But what's been at issue from the start of this branch discussion is specifically the practice (as was being advocated) of doing this *as a safeguard* against buffer overruns - a problem that it does not actually *solve,* just forestalls long enough for some buggy solution to get embedded and only discovered 20 yrs. later at some Godforsaken field installation deep in the Pottsylvanian hinterlands* rather than being caught during development/testing or in some early deployment. * (At which point, the field-service tech having finally arrived back at the office with a pack of hyenas and the curse of Baba Yaga on his/her heels, every other install in the world will abruptly start breaking.)
[toc] | [prev] | [next] | [standalone]
| From | Pancho <Pancho.Jones@protonmail.com> |
|---|---|
| Date | 2025-07-23 07:22 +0100 |
| Message-ID | <105pv2t$77mv$1@dont-email.me> |
| In reply to | #69821 |
On 7/21/25 21:31, John Ames wrote: > On Mon, 21 Jul 2025 20:47:23 +0100 > Richard Kettlewell <invalid@invalid.invalid> wrote: > >> In real life a buffer overrun is not the only outcome to be avoided. >> If you need 20 bytes and you’ve only got 10, _something_ is going to >> go wrong. A bounds check will avoid the outcome being a buffer >> overrun, but you’re still going to have to report an error, or exit >> the program, or some other undesired behaviour, when what you >> actually wanted was the full 20-byte result. That’s what a >> conservative bound helps you with. > > Sure - there's nothing wrong with "reserve a bit more than you think > you'll need" in and of itself. But what's been at issue from the start > of this branch discussion is specifically the practice (as was being > advocated) of doing this *as a safeguard* against buffer overruns - a > problem that it does not actually *solve,* just forestalls long enough > for some buggy solution to get embedded and only discovered 20 yrs. > later at some Godforsaken field installation deep in the Pottsylvanian > hinterlands* rather than being caught during development/testing or in > some early deployment. > > * (At which point, the field-service tech having finally arrived back > at the office with a pack of hyenas and the curse of Baba Yaga on > his/her heels, every other install in the world will abruptly start > breaking.) > You appear to be advocating for using an "assert" type paradigm. This doesn't need to be coupled to actual reservation size.
[toc] | [prev] | [next] | [standalone]
| From | John Ames <commodorejohn@gmail.com> |
|---|---|
| Date | 2025-07-23 08:04 -0700 |
| Message-ID | <20250723080407.00004a8a@gmail.com> |
| In reply to | #69853 |
On Wed, 23 Jul 2025 07:22:21 +0100 Pancho <Pancho.Jones@protonmail.com> wrote: > You appear to be advocating for using an "assert" type paradigm. This > doesn't need to be coupled to actual reservation size. I'm not so much advocating for any specific coding practice in any specific language - asserts work, but so does designing algorithms such that bounds violations can never happen (e.g. #define BUFFER_BOUND and then loop from 0 to BUFFER_BOUND - if there's no other indexing, it will never go off the end, unless the compiler is just broken,) where possible. My point is simply that, unless you're using a language where bounds- checking is provided for "free" behind the scenes, boundary errors will *always* be a hazard, and working in conscious recognition of that is a far more responsible approach than relying on superstitious warding practices - even if the practices in question may be valid design choices for other reasons.
[toc] | [prev] | [next] | [standalone]
| From | John Ames <commodorejohn@gmail.com> |
|---|---|
| Date | 2025-07-23 08:44 -0700 |
| Message-ID | <20250723084425.00007d9e@gmail.com> |
| In reply to | #69854 |
On Wed, 23 Jul 2025 08:04:07 -0700 John Ames <commodorejohn@gmail.com> wrote: > but so does designing algorithms such that bounds violations can > never happen (e.g. #define BUFFER_BOUND and then loop from 0 to > BUFFER_BOUND - if there's no other indexing, it will never go off the > end, unless the compiler is just broken,) where possible. (And, as if it needed saying, where one can be certain that some ape won't come along later and meddle with it - but nothing is truly proof against Future Ape Maintenance.)
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2025-07-23 20:04 +0100 |
| Message-ID | <105rbne$dp0l$2@dont-email.me> |
| In reply to | #69854 |
On 23/07/2025 16:04, John Ames wrote: > My point is simply that, unless you're using a language where bounds- > checking is provided for "free" behind the scenes, boundary errors will > *always* be a hazard, and working in conscious recognition of that is a > far more responsible approach than relying on superstitious warding > practices - even if the practices in question may be valid design > choices for other reasons. I have to agree, and philosophically it is a criticism of our whole 'kindergarten' approach to life In Europe. If people expect all potential hazards to have been removed, they will neither recognise nor respond appropriately when they meet one. Darwin might have a theory about that. -- “when things get difficult you just have to lie” ― Jean Claud Jüncker
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2025-07-23 22:47 +0000 |
| Message-ID | <med73mFdseU5@mid.individual.net> |
| In reply to | #69858 |
On Wed, 23 Jul 2025 20:04:14 +0100, The Natural Philosopher wrote: > On 23/07/2025 16:04, John Ames wrote: >> My point is simply that, unless you're using a language where bounds- >> checking is provided for "free" behind the scenes, boundary errors will >> *always* be a hazard, and working in conscious recognition of that is >> a far more responsible approach than relying on superstitious warding >> practices - even if the practices in question may be valid design >> choices for other reasons. > > I have to agree, and philosophically it is a criticism of our whole > 'kindergarten' approach to life In Europe. > > If people expect all potential hazards to have been removed, they will > neither recognise nor respond appropriately when they meet one. > > Darwin might have a theory about that. Your favorite philosopher, Nietzasche, did. "Was mich nicht umbringt, macht mich stärker."
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2025-07-24 09:56 +0100 |
| Message-ID | <105ssfp$kqms$3@dont-email.me> |
| In reply to | #69861 |
On 23/07/2025 23:47, rbowman wrote: > On Wed, 23 Jul 2025 20:04:14 +0100, The Natural Philosopher wrote: > >> On 23/07/2025 16:04, John Ames wrote: >>> My point is simply that, unless you're using a language where bounds- >>> checking is provided for "free" behind the scenes, boundary errors will >>> *always* be a hazard, and working in conscious recognition of that is >>> a far more responsible approach than relying on superstitious warding >>> practices - even if the practices in question may be valid design >>> choices for other reasons. >> >> I have to agree, and philosophically it is a criticism of our whole >> 'kindergarten' approach to life In Europe. >> >> If people expect all potential hazards to have been removed, they will >> neither recognise nor respond appropriately when they meet one. >> >> Darwin might have a theory about that. > > Your favorite philosopher, Nietzasche, did. "Was mich nicht umbringt, > macht mich stärker." Nietzsche is hardly my favourite philosopher. By and large Nietzsche was a total cunt. A misogynist, a racist, a white supremacist, just the man to bring out your inner Nazi. Along with Karl Marx responsible for most of the problems of the 20th century. -- “Those who can make you believe absurdities, can make you commit atrocities.” ― Voltaire, Questions sur les Miracles à M. Claparede, Professeur de Théologie à Genève, par un Proposant: Ou Extrait de Diverses Lettres de M. de Voltaire
[toc] | [prev] | [next] | [standalone]
| From | Pancho <Pancho.Jones@protonmail.com> |
|---|---|
| Date | 2025-07-23 21:53 +0100 |
| Message-ID | <105ri4r$ed5t$1@dont-email.me> |
| In reply to | #69854 |
On 7/23/25 16:04, John Ames wrote: > On Wed, 23 Jul 2025 07:22:21 +0100 > Pancho <Pancho.Jones@protonmail.com> wrote: > >> You appear to be advocating for using an "assert" type paradigm. This >> doesn't need to be coupled to actual reservation size. > > I'm not so much advocating for any specific coding practice in any > specific language - asserts work, but so does designing algorithms such > that bounds violations can never happen (e.g. #define BUFFER_BOUND and > then loop from 0 to BUFFER_BOUND - if there's no other indexing, it > will never go off the end, unless the compiler is just broken,) where > possible. > > My point is simply that, unless you're using a language where bounds- > checking is provided for "free" behind the scenes, boundary errors will > *always* be a hazard, and working in conscious recognition of that is a > far more responsible approach than relying on superstitious warding > practices - even if the practices in question may be valid design > choices for other reasons. > This isn't about bounds checking. I haven't used a non-bounds checked language for decades. The difference between a bounds checked language and a non-bounds checked language is that the bounds check produces a clear deterministic error. They are still both errors. The discussion is about good codling practice. Perhaps it would be clearer if we discussed a specific case: how much memory is needed to store the elements of a symmetric n-square matrix? In practice, you might not wish to check that the matrix will always be symmetric, or you may want to implement a simple indexing scheme. If n is small, it probably isn't worth the time thinking about it, so you just allocate n^2 elements. There is nothing superstitious or dangerous about this. It just recognises that the extra coding time is not worth the memory cost.
[toc] | [prev] | [next] | [standalone]
| From | John Ames <commodorejohn@gmail.com> |
|---|---|
| Date | 2025-07-23 14:28 -0700 |
| Message-ID | <20250723142845.000033ee@gmail.com> |
| In reply to | #69859 |
On Wed, 23 Jul 2025 21:53:47 +0100 Pancho <Pancho.Jones@protonmail.com> wrote: > If n is small, it probably isn't worth the time thinking about it, so > you just allocate n^2 elements. There is nothing superstitious or > dangerous about this. It just recognises that the extra coding time > is not worth the memory cost. That's fair enough - but it's also not what was being discussed. This branch of the discussion started off, specifically, with the suggestion that allocating extra was a helpful ward against running off the end of a buffer/array and stomping on the next allocation, which it really, really isn't.
[toc] | [prev] | [next] | [standalone]
| From | Pancho <Pancho.Jones@protonmail.com> |
|---|---|
| Date | 2025-07-24 00:29 +0100 |
| Message-ID | <105rr9k$fslf$1@dont-email.me> |
| In reply to | #69860 |
On 7/23/25 22:28, John Ames wrote: > On Wed, 23 Jul 2025 21:53:47 +0100 > Pancho <Pancho.Jones@protonmail.com> wrote: > >> If n is small, it probably isn't worth the time thinking about it, so >> you just allocate n^2 elements. There is nothing superstitious or >> dangerous about this. It just recognises that the extra coding time >> is not worth the memory cost. > > That's fair enough - but it's also not what was being discussed. This > branch of the discussion started off, specifically, with the suggestion > that allocating extra was a helpful ward against running off the end of > a buffer/array and stomping on the next allocation, which it really, > really isn't. > Yes, I understand that. That is what using n^2 for a symmetric matrix is doing. That is what using the maximum of fence posts and fence panels is doing. Allocating n+1 instead of n is the same trick as the matrix, just simpler. Programming is about good enough, we have no particular reason to think programmers can specify an equality more reliably than an inequality. Indeed, an awful lot of the time inequalities are much easier to specify reliably. How many prime numbers less than 2n? I'm very sure that it is less than n + 1. I can prove it. If I use an array bound of n+1, it is good, it won't go wrong with time. In 20 years time, it will still be good. I could give a smaller upper bound, but it would take more time and be less reliable. You appear to have a prejudice for equality. A prejudice that programmers should think hard about every problem they encounter. A prejudice that a simple, but good enough answer is lazy. Given programming time is limited, you are not explaining how this strategy improves code reliability, in general.
[toc] | [prev] | [next] | [standalone]
| From | John Ames <commodorejohn@gmail.com> |
|---|---|
| Date | 2025-07-24 08:05 -0700 |
| Message-ID | <20250724080540.00004f57@gmail.com> |
| In reply to | #69862 |
On Thu, 24 Jul 2025 00:29:55 +0100 Pancho <Pancho.Jones@protonmail.com> wrote: > You appear to have a prejudice for equality. A prejudice that > programmers should think hard about every problem they encounter. A > prejudice that a simple, but good enough answer is lazy. I'm not advocating for approaching every aspect of development with a monomania for absolute ideal design and optimal implementation, and I have no idea where you're getting that from. What I *am* saying is that dealing with a certain class of bug-hazards is inevitable when using tools that don't include built-in safeguards against them, and that you ignore that - or ward against it via magical thinking - at your peril. Over-speccing because it's simpler than working out the Most Optimum answer is one thing; over-speccing because you hope it'll save you from dealing with genuine bugs is superstitious folly. > Given programming time is limited, you are not explaining how this > strategy improves code reliability, in general. I wouldn't think I'd *have* to, given how many major security flaws in the last couple decades have come down to sloppy handling of boundary issues (Heartbleed, anyone?) - to say nothing of day-to-day foul-ups.
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <invalid@invalid.invalid> |
|---|---|
| Date | 2025-07-24 21:51 +0100 |
| Message-ID | <wwvh5z1z50z.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #69865 |
John Ames <commodorejohn@gmail.com> writes: > Pancho <Pancho.Jones@protonmail.com> wrote: >> You appear to have a prejudice for equality. A prejudice that >> programmers should think hard about every problem they encounter. A >> prejudice that a simple, but good enough answer is lazy. > > I'm not advocating for approaching every aspect of development with a > monomania for absolute ideal design and optimal implementation, and I > have no idea where you're getting that from. > > What I *am* saying is that dealing with a certain class of bug-hazards > is inevitable when using tools that don't include built-in safeguards > against them, and that you ignore that - or ward against it via magical > thinking - at your peril. Over-speccing because it's simpler than > working out the Most Optimum answer is one thing; over-speccing because > you hope it'll save you from dealing with genuine bugs is superstitious > folly. One person might have been arguing for that, though I’m not even confident of that since their posts have expired here; they’ve been out of this thread for that long. You don’t have to argue that point with everyone else. -- https://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | John Ames <commodorejohn@gmail.com> |
|---|---|
| Date | 2025-07-24 15:06 -0700 |
| Message-ID | <20250724150625.00005a29@gmail.com> |
| In reply to | #69871 |
On Thu, 24 Jul 2025 21:51:24 +0100 Richard Kettlewell <invalid@invalid.invalid> wrote: > One person might have been arguing for that, though I’m not even > confident of that since their posts have expired here; they’ve been > out of this thread for that long. You don’t have to argue that point > with everyone else. I wouldn't be, if people didn't keep responding to what they *think* I said, as opposed to what I actually *did* say.
[toc] | [prev] | [next] | [standalone]
| From | Pancho <Pancho.Jones@protonmail.com> |
|---|---|
| Date | 2025-07-25 07:06 +0100 |
| Message-ID | <105v6t4$1rec2$1@dont-email.me> |
| In reply to | #69875 |
On 7/24/25 23:06, John Ames wrote: > On Thu, 24 Jul 2025 21:51:24 +0100 > Richard Kettlewell <invalid@invalid.invalid> wrote: > >> One person might have been arguing for that, though I’m not even >> confident of that since their posts have expired here; they’ve been >> out of this thread for that long. You don’t have to argue that point >> with everyone else. > > I wouldn't be, if people didn't keep responding to what they *think* I > said, as opposed to what I actually *did* say. > You keep making overly dogmatic comments about over speccing in order to avoid errors. I have been using reliable over speccing in order to counter this, because it is an easy argument to make. However, I could also defend unreliable over speccing. Taking a chance something is good enough and not checking properly. The type of design decision that does lead to bugs. The fundamental metric to judge software is usefulness. That is why we have so much buggy code, people want code that does stuff rather than code that is perfectly bug free but doesn't do as much. In my career, a lot of time I have not been given the budget to develop quality code, so I cut corners. Fortunately I don't develop SSL, chip microcode or aircraft controllers. People accept my code falls over occasionally. However, it is better if code falls over less often. Over speccing and hoping for the best is an economical way of achieving code that falls over less than code only using expected allocation requirements, that is why people do it. If we aren't honest with ourselves and use ivory tower arguments, it is harder to tackle problems. This is the way structural engineering works. Bridge building etc.
[toc] | [prev] | [next] | [standalone]
| From | John Ames <commodorejohn@gmail.com> |
|---|---|
| Date | 2025-07-25 10:39 -0700 |
| Message-ID | <20250725103940.0000789d@gmail.com> |
| In reply to | #69885 |
On Fri, 25 Jul 2025 07:06:27 +0100 Pancho <Pancho.Jones@protonmail.com> wrote: > You keep making overly dogmatic comments about over speccing in order > to avoid errors. Yes, because that was the root of this conversation, the argument that over-speccing *in hopes of warding off bounds errors* is a *good idea,* an argument with which I *fervently* disagree. Disregard for & magical thinking wrt. to this specific issue has *always* been a cause of mayhem, and it's not an exaggeration to say that the majority of catastrophic IT failures in the last few decades, from the Morris worm to the CrowdStrike outage, are due to carelessness on *this specific issue.* It is not outside the realm of possibility that people have *died* as a consequence. I have zero shame in being dogmatic here - BOUNDS-CHECK YOUR DAMN BUFFERS. (Or design such that boundary errors are a 101% can't-happen thing, if you can - but for the love of all that is good and holy, *don't* just leave yourself extra room to appease the fairies and figure "eh, it'll be fine," especially with anything network-facing.) > The fundamental metric to judge software is usefulness. That is why > we have so much buggy code, people want code that does stuff rather > than code that is perfectly bug free but doesn't do as much. I can to a certain extent appreciate the worse-is-better mindset, in that it is often (but not *always*) better to have an imperfect solution than no solution at all. But *far* too many developers treat that as an excuse to not really bother in the first place. The HN story linked elsewhere in the thread is a perfect example of where that kind of thinking can lead: personal information on hundreds or thousands of users, *including live GPS data,* accessible to anyone with a modest knowledge of exploit tactics and a couple free afternoons, because some dingbat newbie cared more about Just Shipping than assessing his own *rampant* design vulnerabilities. While I have no doubt that every single person here is more competent than the "vibe coder" in that story, that still doesn't excuse careless thinking; and while the potential for harm is less catastrophic in some personal project or business-specific utility than a public-facing social-networking whichijig, it's easy to underestimate the lifespan and reach of any piece of code - especially in the freenix world, where it's actually incredibly common for larger, more widely-used libraries and tools to be built on the back of what were originally small private projects. For the love of Mike, the last decade saw breaking changes to *ncurses,* a Clinton-era update of a package birthed the same year the Gipper rolled into the White House. > Fortunately I don't develop SSL, chip microcode or aircraft > controllers. People accept my code falls over occasionally. To be perfectly frank, it's *very* fortunate that you don't develop aircraft controllers. > This is the way structural engineering works. Bridge building etc. Funny you should cite bridge-building. As a friend once observed: "The Romans made their architects stand under the arches they designed while the keystone was put in place and the supports removed. The Romans built bridges that stayed the #&@! up."
[toc] | [prev] | [next] | [standalone]
Page 4 of 12 — ← Prev page 1 2 3 [4] 5 6 … 12 Next page →
Back to top | Article view | comp.os.linux.misc
csiph-web