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 8 of 12 — ← Prev page 1 … 6 7 [8] 9 10 … 12 Next page →
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-07-24 21:16 +0000 |
| Message-ID | <105u7qu$1jpjo$1@dont-email.me> |
| In reply to | #69864 |
On Thu, 24 Jul 2025 14:42:56 GMT, Charlie Gibbs wrote: > https://en.wikipedia.org/wiki/Cargo_cult_programming Seems an apt description of, for example, those who say you must never write actual SQL code in your programs, always use an ORM or templating system or something.
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2025-07-24 23:21 +0000 |
| Message-ID | <meftgiFbbn6U5@mid.individual.net> |
| In reply to | #69872 |
On Thu, 24 Jul 2025 21:16:15 -0000 (UTC), Lawrence D'Oliveiro wrote: > On Thu, 24 Jul 2025 14:42:56 GMT, Charlie Gibbs wrote: > >> https://en.wikipedia.org/wiki/Cargo_cult_programming > > Seems an apt description of, for example, those who say you must never > write actual SQL code in your programs, always use an ORM or templating > system or something. https://en.wikipedia.org/wiki/ Object%E2%80%93relational_mapping#Comparison_with_traditional_data_access_techniques I've never used an ORM but I might learn to like it. I've done my share of database programming, both embedded and CLI, and it always seemed like shoveling shit against the tide with a lot of boilerplate to get where you're going particularly when a join won't do the trick.
[toc] | [prev] | [next] | [standalone]
| From | John Ames <commodorejohn@gmail.com> |
|---|---|
| Date | 2025-07-21 14:05 -0700 |
| Message-ID | <20250721140559.000002e1@gmail.com> |
| In reply to | #69818 |
On Mon, 21 Jul 2025 20:47:23 +0100 Richard Kettlewell <invalid@invalid.invalid> wrote: > 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. Additionally, if the system you're putting together is one where you might *ever* need to accept inputs of arbitrary size gracefully, you should *really* be asking yourself whether a fixed-length buffer is the right choice, or whether you should be looking at some more readily extensible structure. Even in languages where you don't get dynamic arrays or lists for "free," it is really not *that* hard to implement something more robust.
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2025-07-21 21:14 +0000 |
| Message-ID | <M4yfQ.942462$wybc.212609@fx17.iad> |
| In reply to | #69818 |
On 2025-07-21, Richard Kettlewell <invalid@invalid.invalid> wrote: > 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. The top entry in my list of Famous Last Words is "Oh, don't worry about that - it'll never happen." I had learned that "never" is usually about six months. At the very least, if your program issues an appropriate error message before aborting, you'll have a chance of finding and fixing the deficiency. These days, I've gotten into using realloc() to enlarge the area in question; if it works, I quietly continue, and if not I put out a nasty error message and quit. -- /~\ Charlie Gibbs | Growth for the sake of \ / <cgibbs@kltpzyxm.invalid> | growth is the ideology X I'm really at ac.dekanfrus | of the cancer cell. / \ if you read it the right way. | -- Edward Abbey
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2025-07-21 22:19 +0100 |
| Message-ID | <105maso$307ge$5@dont-email.me> |
| In reply to | #69824 |
On 21/07/2025 22:14, Charlie Gibbs wrote: > The top entry in my list of Famous Last Words is "Oh, don't worry > about that - it'll never happen." I had learned that "never" is > usually about six months. Funny you should say that..My friend who was at Acorn a little before the ARM years says they had an issue that very occasionally the micro they were working on would freeze up. I can't remember why, but the solution was to add a wait state. "This reduced the frequency to about one in every thousand years- And we reckoned the user would shrug, reboot and it would never happen to him again" -- I was brought up to believe that you should never give offence if you can avoid it; the new culture tells us you should always take offence if you can. There are now experts in the art of taking offence, indeed whole academic subjects, such as 'gender studies', devoted to it. Sir Roger Scruton
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2025-07-22 02:10 +0000 |
| Message-ID | <me8a7oF5erpU3@mid.individual.net> |
| In reply to | #69824 |
On Mon, 21 Jul 2025 21:14:20 GMT, Charlie Gibbs wrote: > The top entry in my list of Famous Last Words is "Oh, don't worry about > that - it'll never happen." I had learned that "never" is usually about > six months. At the very least, if your program issues an appropriate > error message before aborting, you'll have a chance of finding and > fixing the deficiency. These days, I've gotten into using realloc() to > enlarge the area in question; if it works, I quietly continue, and if > not I put out a nasty error message and quit. I test the return of malloc(), calloc(), and realloc() and attempt to log the error. I have caught a calloc() error whem the nmemb parameter was negative due to bad math but I'm not that optimistic about logging being successful when memory allocation is failing. Still, I tried...
[toc] | [prev] | [next] | [standalone]
| From | candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> |
|---|---|
| Date | 2025-06-27 06:00 +0000 |
| Message-ID | <slrn105sci1.1ibsg.candycanearter07@candydeb.host.invalid> |
| In reply to | #69069 |
Robert Riches <spamtrap42@jacob21819.net> wrote at 03:34 this Tuesday (GMT): > On 2025-06-22, candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> wrote: >> Robert Riches <spamtrap42@jacob21819.net> wrote at 03:43 this Saturday (GMT): >>> On 2025-06-21, rbowman <bowman@montana.com> wrote: >>>> On Fri, 20 Jun 2025 23:07:20 -0000 (UTC), Rich wrote: >>>> >>>>> Very likely, but the idea was to protect the typical programmer from >>>>> their own common mistakes (of not carefully checking error return codes >>>>> or buffer lengths, etc.). I.e. the typical 9-5 contract programmer, not >>>>> the Dennis Ritchie's of the world. >>>> >>>> I'm paranoid enough that I check the return of malloc and try to log the >>>> problem even though I'm probably screwed at that point. It has pointed out >>>> errors for calloc if you've manged to come up with a negative size. >>>> >>>> I have worked with programmers that assumed nothing bad would ever happen. >>>> Sadly, some had years of experience. >>> >>> Some years ago, I heard of a bug related to use of malloc. The >>> code had _intended_ to dynamically allocate storage for a string >>> and the terminating null byte. It was _intended_ to do this: >>> >>> dest = malloc(strlen(src)+1); >>> >>> Instead, a paren was misplaced: >>> >>> dest = malloc(strlen(src))+1; >>> >>> IIUC, the next line copied the src string into the newly- >>> allocated destination. >> >> Aren't you supposed to multiply by sizeof as well? > > Multiply by sizeof what? sizeof(char)? This was in the > pre-Unicode days. Even now with Unicode, IIUC sizeof(char) is > still always 1. I still multiply by sizeof(char), half because of habit and half to make it clear to myself I'm making a char array, even if its "redundant". I kinda thought that was the "cannonical" way to do that, since you could have a weird edge case with a system defining char as something else? >>> Those who had worked on that project longer said the bug had been >>> latent in the code for several years, most likely with alignment >>> padding masking the bug from being discovered. Curiously, the >>> bug made itself manifest immediately upon changing from a 32-bit >>> build environment to a 64-bit build environment. >> >> >> I'm more surprised it didn't segfault. Any idea what caused it to not? >> I know strlen doesn't account for the terminating character, but it >> seems like it should've been TWO bytes shorter... > > IIUC, heap-based malloc _usually_ returns a larger allocation > block than you really asked for. As long as malloc gave you at > least 2 extra bytes, you'd never see any misbehavior. Even if it > didn't give you 2 or more extra bytes, it's fairly likely you'd > just get lucky and never see the program crash or otherwise > misbehavior in a significant way. For example, if you stomped on > the header of the next allocation block, as long as nothing ever > read and acted upon the data in said header, you'd never see it. Oh, so it was some poorly written code being covered up by a weird quirk in the 32b version of the compiler? Always interesting hearing about "accidentilly working" programs. -- user <candycane> is generated from /dev/urandom
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <invalid@invalid.invalid> |
|---|---|
| Date | 2025-06-27 08:37 +0100 |
| Message-ID | <wwv4iw1bpor.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #69147 |
candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
writes:
> Robert Riches <spamtrap42@jacob21819.net> wrote at 03:34 this Tuesday (GMT):
>> <candycanearter07@candycanearter07.nomail.afraid> wrote:
>>> Aren't you supposed to multiply by sizeof as well?
>>
>> Multiply by sizeof what? sizeof(char)? This was in the
>> pre-Unicode days. Even now with Unicode, IIUC sizeof(char) is
>> still always 1.
>
> I still multiply by sizeof(char), half because of habit and half to
> make it clear to myself I'm making a char array, even if its
> "redundant". I kinda thought that was the "cannonical" way to do that,
> since you could have a weird edge case with a system defining char as
> something else?
Whatever the representation of char, sizeof(char)=1. That’s what the
definition of sizeof is - char is the unit it counts in.
From the language specification:
When sizeof is applied to an operand that has type char, unsigned
char, or signed char, (or a qualified version thereof) the result is
1. When applied to an operand that has array type, the result is the
total number of bytes in the array.) When applied to an operand that
has structure or union type, the result is the total number of bytes
in such an object, including internal and trailing padding.
A programmer can adopt a personal style of redundantly multiplying by 1
if they like, it’ll be a useful hint to anyone else reading the code
that the author didn’t know the language very well. But in no way is
anyone ‘supposed’ to do it.
--
https://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2025-06-27 08:45 +0100 |
| Message-ID | <103li77$111c$1@dont-email.me> |
| In reply to | #69148 |
On 27/06/2025 08:37, Richard Kettlewell wrote: > A programmer can adopt a personal style of redundantly multiplying by 1 > if they like, it’ll be a useful hint to anyone else reading the code > that the author didn’t know the language very well. Or a hint that the writer expected the maintainer would not know the language very well. > But in no way is > anyone ‘supposed’ to do it. Morality rarely enters into code writing, unless introduced by parties with 'political' aims. -- How fortunate for governments that the people they administer don't think. Adolf Hitler
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-06-27 08:14 +0000 |
| Message-ID | <103ljtc$1ggl$2@dont-email.me> |
| In reply to | #69149 |
On Fri, 27 Jun 2025 08:45:43 +0100, The Natural Philosopher wrote: > On 27/06/2025 08:37, Richard Kettlewell wrote: >> >> But in no way is anyone ‘supposed’ to do it. > > Morality rarely enters into code writing, unless introduced by parties > with 'political' aims. I must learn to use that as an excuse: the next time someone complains about the way I write my code, I can tell them that their criticism is “political”.
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2025-06-27 13:27 -0400 |
| Message-ID | <YB6cnbE8ns8zScP1nZ2dnZfqnPadnZ2d@giganews.com> |
| In reply to | #69150 |
On 6/27/25 4:14 AM, Lawrence D'Oliveiro wrote: > On Fri, 27 Jun 2025 08:45:43 +0100, The Natural Philosopher wrote: > >> On 27/06/2025 08:37, Richard Kettlewell wrote: >>> >>> But in no way is anyone ‘supposed’ to do it. >> >> Morality rarely enters into code writing, unless introduced by parties >> with 'political' aims. > > I must learn to use that as an excuse: the next time someone complains > about the way I write my code, I can tell them that their criticism is > “political”. Hey ... it could WORK ! :-) "Racist", "colonialist" and "gender-fascist" should work in some locales as well Alas, 'AI', that can and HAS been tampered with to achieve PC results for political reasons already.
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2025-06-27 19:13 +0100 |
| Message-ID | <103mmvr$9qr7$1@dont-email.me> |
| In reply to | #69152 |
On 27/06/2025 18:27, c186282 wrote: > On 6/27/25 4:14 AM, Lawrence D'Oliveiro wrote: >> On Fri, 27 Jun 2025 08:45:43 +0100, The Natural Philosopher wrote: >> >>> On 27/06/2025 08:37, Richard Kettlewell wrote: >>>> >>>> But in no way is anyone ‘supposed’ to do it. >>> >>> Morality rarely enters into code writing, unless introduced by parties >>> with 'political' aims. >> >> I must learn to use that as an excuse: the next time someone complains >> about the way I write my code, I can tell them that their criticism is >> “political”. > In your case it almost certainly will be. > Hey ... it could WORK ! :-) > > "Racist", "colonialist" and "gender-fascist" should work > in some locales as well > Byteist, wordist, and non-boolean... > Alas, 'AI', that can and HAS been tampered with to > achieve PC results for political reasons already. Indeed. -- Of what good are dead warriors? … Warriors are those who desire battle more than peace. Those who seek battle despite peace. Those who thump their spears on the ground and talk of honor. Those who leap high the battle dance and dream of glory … The good of dead warriors, Mother, is that they are dead. Sheri S Tepper: The Awakeners.
[toc] | [prev] | [next] | [standalone]
| From | Chris Ahlstrom <OFeem1987@teleworm.us> |
|---|---|
| Date | 2025-06-28 09:16 -0400 |
| Message-ID | <103opuq$s70b$1@dont-email.me> |
| In reply to | #69154 |
The Natural Philosopher wrote this post while blinking in Morse code: > On 27/06/2025 18:27, c186282 wrote: > > <snip> > >> Alas, 'AI', that can and HAS been tampered with to >> achieve PC results for political reasons already. > > Indeed. Not just "PC" (I assume that the aspie meant "politically correct" and not "personal computer"), but any point of view. It's who trains the AI that counts. -- Humor in the Court: Q: What can you tell us about the truthfulness and veracity of this defendant? A: Oh, she will tell the truth. She said she'd kill that sonofabitch--and she did!
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2025-06-27 13:24 -0400 |
| Message-ID | <fPmcnaKaU81_TsP1nZ2dnZfqn_adnZ2d@giganews.com> |
| In reply to | #69148 |
On 6/27/25 3:37 AM, Richard Kettlewell wrote: > candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> > writes: >> Robert Riches <spamtrap42@jacob21819.net> wrote at 03:34 this Tuesday (GMT): >>> <candycanearter07@candycanearter07.nomail.afraid> wrote: >>>> Aren't you supposed to multiply by sizeof as well? >>> >>> Multiply by sizeof what? sizeof(char)? This was in the >>> pre-Unicode days. Even now with Unicode, IIUC sizeof(char) is >>> still always 1. >> >> I still multiply by sizeof(char), half because of habit and half to >> make it clear to myself I'm making a char array, even if its >> "redundant". I kinda thought that was the "cannonical" way to do that, >> since you could have a weird edge case with a system defining char as >> something else? > > Whatever the representation of char, sizeof(char)=1. That’s what the > definition of sizeof is - char is the unit it counts in. > > From the language specification: > > When sizeof is applied to an operand that has type char, unsigned > char, or signed char, (or a qualified version thereof) the result is > 1. When applied to an operand that has array type, the result is the > total number of bytes in the array.) When applied to an operand that > has structure or union type, the result is the total number of bytes > in such an object, including internal and trailing padding. > > A programmer can adopt a personal style of redundantly multiplying by 1 > if they like, it’ll be a useful hint to anyone else reading the code > that the author didn’t know the language very well. But in no way is > anyone ‘supposed’ to do it. "Best practice" sometimes means a little bit of redundant/clarifying code. Some of us are old enough to remember when CPUs were not always 4/8/16/32/64 ... plus even now they've added a lot of new types like 128-bit ints. Simply ASSUMING an int is 16 bits is 'usually safe' but not necessarily 'best practice' and limits future (or past) compatibility. 'C' lets you fly free ... but that CAN be straight into a window pane :-)
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2025-06-27 17:40 +0000 |
| Message-ID | <mc83bhFcp3sU1@mid.individual.net> |
| In reply to | #69151 |
On Fri, 27 Jun 2025 13:24:06 -0400, c186282 wrote: > Some of us are old enough to remember when CPUs were > not always 4/8/16/32/64 ... plus even now they've added a lot of new > types like 128-bit ints. Simply ASSUMING an int is 16 bits is > 'usually safe' but not necessarily 'best practice' and limits future > (or past) compatibility. 'C' lets you fly free ... > but that CAN be straight into a window pane Assuming an int is 16 bits is not a good idea. I wouldn't even assume a short is 16 bits
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2025-06-27 18:20 +0000 |
| Message-ID | <103mndf$57lc$1@dont-email.me> |
| In reply to | #69153 |
On Fri, 27 Jun 2025 17:40:02 +0000, rbowman wrote: > On Fri, 27 Jun 2025 13:24:06 -0400, c186282 wrote: > >> Some of us are old enough to remember when CPUs were >> not always 4/8/16/32/64 ... plus even now they've added a lot of new >> types like 128-bit ints. Simply ASSUMING an int is 16 bits is >> 'usually safe' but not necessarily 'best practice' and limits future >> (or past) compatibility. 'C' lets you fly free ... >> but that CAN be straight into a window pane > > Assuming an int is 16 bits is not a good idea. I wouldn't even assume a > short is 16 bits It would depend on the programming language you use, it's conformance to standards, and which standard it conforms to. The ISO C standards, for instance, dictate that - a char is at least 8 bits wide, - an unsigned short int must be able to, at least, express values between 0 and 65535, and - an unsigned int must be able to, at least, express values between 0 and 65535 These last two imply that both unsigned short int and int are at least 16 bits wide. At least, according to the standard. Now, you /can/ have a C compiler that DOES NOT comply, PARTIALLY complies, or complies (WHEN REQUESTED) to the ISO C standard; for those compilers, "you pay your money, and you take your chances" HTH -- Lew Pitcher "In Skills We Trust"
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-06-27 23:03 +0000 |
| Message-ID | <103n7ve$dqtr$7@dont-email.me> |
| In reply to | #69155 |
On Fri, 27 Jun 2025 18:20:31 -0000 (UTC), Lew Pitcher wrote: > These last two imply that both unsigned short int and int are at least > 16 bits wide. At least, according to the standard. Or, you know, just rely on the explicit definitions in stdint.h.
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2025-06-28 01:13 -0400 |
| Message-ID | <nBCdnc6Kic6f58L1nZ2dnZfqnPhh4p2d@giganews.com> |
| In reply to | #69162 |
On 6/27/25 7:03 PM, Lawrence D'Oliveiro wrote: > On Fri, 27 Jun 2025 18:20:31 -0000 (UTC), Lew Pitcher wrote: > >> These last two imply that both unsigned short int and int are at least >> 16 bits wide. At least, according to the standard. > > Or, you know, just rely on the explicit definitions in stdint.h. sizeof() will give the right sizes. Simple, easy to write, 'best practice'.
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2025-06-28 06:10 +0000 |
| Message-ID | <mc9faoFj9okU4@mid.individual.net> |
| In reply to | #69165 |
On Sat, 28 Jun 2025 01:13:18 -0400, c186282 wrote:
> On 6/27/25 7:03 PM, Lawrence D'Oliveiro wrote:
>> On Fri, 27 Jun 2025 18:20:31 -0000 (UTC), Lew Pitcher wrote:
>>
>>> These last two imply that both unsigned short int and int are at least
>>> 16 bits wide. At least, according to the standard.
>>
>> Or, you know, just rely on the explicit definitions in stdint.h.
>
> sizeof() will give the right sizes.
>
> Simple, easy to write, 'best practice'.
#include <stdio.h>
#include <stdlib.h>
int main(void) {
printf("sizeof(char) %ld \n", sizeof(char));
printf("sizeof(short) %ld \n", sizeof(short));
printf("sizeof(int) %ld \n", sizeof(int));
printf("sizeof(long) %ld \n", sizeof(long));
return 0;
}
$ ./sizeof
sizeof(char) 1
sizeof(short) 2
sizeof(int) 4
sizeof(long) 8
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2025-06-27 18:16 -0400 |
| Message-ID | <vAmdnSM-9LvohcL1nZ2dnZfqnPGdnZ2d@giganews.com> |
| In reply to | #69153 |
On 6/27/25 1:40 PM, rbowman wrote: > On Fri, 27 Jun 2025 13:24:06 -0400, c186282 wrote: > >> Some of us are old enough to remember when CPUs were >> not always 4/8/16/32/64 ... plus even now they've added a lot of new >> types like 128-bit ints. Simply ASSUMING an int is 16 bits is >> 'usually safe' but not necessarily 'best practice' and limits future >> (or past) compatibility. 'C' lets you fly free ... >> but that CAN be straight into a window pane > > Assuming an int is 16 bits is not a good idea. I wouldn't even assume a > short is 16 bits Voice of experience for sure. Things have been represented/handled just SO many ways over the years. Using sizeof() is 'best practice' even if you're Just Sure how wide an int or whatever may be. 24 bits are still found in some DSPs and you MAY be asked someday to patch or port one of the old 12/18/24/36/48 programs. Ah ! Found a list of many CPUs, starting with the Babbage engine (50-bit words) : https://en.wikipedia.org/wiki/Word_(computer_architecture)#Table_of_word_sizes
[toc] | [prev] | [next] | [standalone]
Page 8 of 12 — ← Prev page 1 … 6 7 [8] 9 10 … 12 Next page →
Back to top | Article view | comp.os.linux.misc
csiph-web