Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #393426 > unrolled thread
| Started by | "Paul Edwards" <mutazilah@gmail.com> |
|---|---|
| First post | 2025-05-20 16:06 +1000 |
| Last post | 2025-05-24 22:10 -0700 |
| Articles | 20 on this page of 343 — 23 participants |
Back to article view | Back to comp.lang.c
encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-20 16:06 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-20 07:27 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-20 19:33 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 00:10 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 10:23 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 03:37 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 20:00 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-22 06:49 +0000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-22 07:02 +0000
Re: encapsulating directory operations Jakob Bohm <egenagwemdimtapsar@jbohm.dk> - 2025-08-17 21:04 +0200
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-08-18 00:30 +0000
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-08-19 18:09 -0400
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-21 19:51 -0400
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-22 05:04 +0000
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-22 14:13 -0400
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-22 22:46 +0000
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-22 19:07 -0400
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-22 23:15 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-23 09:26 +1000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-23 00:44 +0000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-24 02:26 +0000
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-22 20:10 -0400
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-23 02:08 +0000
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-23 19:29 -0400
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-24 00:08 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-05-31 08:20 +0200
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-31 21:42 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-01 07:58 +0200
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-01 07:43 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-02 09:35 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-02 15:24 +0000
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-06-02 19:14 -0400
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-02 23:54 +0000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-06-03 01:02 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-03 19:41 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-03 18:25 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-06 10:29 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-06 14:10 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-06 19:10 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-06 17:24 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-06 19:26 +0200
Re: encapsulating directory operations wij <wyniijj5@gmail.com> - 2025-06-07 04:04 +0800
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-07 06:24 +0200
Re: encapsulating directory operations wij <wyniijj5@gmail.com> - 2025-06-07 19:58 +0800
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-07 18:31 +0200
Re: encapsulating directory operations wij <wyniijj5@gmail.com> - 2025-06-08 02:43 +0800
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-07 21:22 +0200
Re: encapsulating directory operations wij <wyniijj5@gmail.com> - 2025-06-08 03:56 +0800
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-07 23:57 +0200
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-08 10:06 +0200
Re: encapsulating directory operations Muttley@DastardlyHQ.org - 2025-06-08 08:55 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-08 17:02 +0200
Re: encapsulating directory operations Muttley@DastardlyHQ.org - 2025-06-08 15:08 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-08 17:18 +0200
Re: encapsulating directory operations Muttley@DastardlyHQ.org - 2025-06-09 09:20 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-09 12:58 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-08 16:55 +0000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-06-08 17:45 +0000
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-06-10 03:21 -0700
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-08 22:07 +0200
Re: encapsulating directory operations wij <wyniijj5@gmail.com> - 2025-06-09 07:13 +0800
Re: encapsulating directory operations Muttley@DastardlyHQ.org - 2025-06-09 10:21 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-09 13:01 +0200
Re: encapsulating directory operations wij <wyniijj5@gmail.com> - 2025-06-08 22:52 +0800
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-08 17:06 +0200
Re: encapsulating directory operations wij <wyniijj5@gmail.com> - 2025-06-09 00:28 +0800
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-08 22:05 +0200
Re: encapsulating directory operations wij <wyniijj5@gmail.com> - 2025-06-09 06:51 +0800
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-09 07:59 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-09 13:04 +0200
Re: encapsulating directory operations Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-06-07 23:12 +0200
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-08 17:11 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-08 16:58 +0000
Re: encapsulating directory operations "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-08 11:48 -0700
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-08 22:09 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-09 14:01 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-09 17:24 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-09 15:53 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-09 19:45 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-09 18:33 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-09 20:39 +0200
Re: encapsulating directory operations Muttley@DastardlyHQ.org - 2025-06-10 07:21 +0000
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-10 13:19 +0000
Re: encapsulating directory operations Muttley@DastardlyHQ.org - 2025-06-10 14:46 +0000
Re: encapsulating directory operations "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-10 12:08 -0700
Re: encapsulating directory operations antispam@fricas.org (Waldek Hebisch) - 2025-06-10 20:22 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-06-09 19:22 +0100
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-06-09 18:59 -0700
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-10 09:51 +0200
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-03 00:37 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-10 14:07 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-10 14:36 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-10 16:40 +0200
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-06-10 16:52 +0000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-10 23:33 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-11 07:07 +0200
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-11 05:34 +0000
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-11 13:41 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-11 17:33 +0200
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-12 01:33 +0000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-20 02:18 -0700
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-20 10:33 +0100
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-20 19:45 +1000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-20 13:42 +0200
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-20 13:55 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-20 15:05 +0100
Re: encapsulating directory operations Muttley@DastardlyHQ.org - 2025-05-20 14:09 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 00:15 +1000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 00:48 +1000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-20 16:02 +0100
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 01:28 +1000
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-23 05:43 -0700
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-23 14:27 +0100
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-23 22:32 -0700
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-24 06:54 +0100
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-28 05:41 -0700
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-28 14:10 +0100
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-06-11 20:15 -0700
Re: encapsulating directory operations Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> - 2025-05-26 15:19 +1000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-27 16:23 +0200
Re: encapsulating directory operations Michael S <already5chosen@yahoo.com> - 2025-05-27 18:10 +0300
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-27 19:24 +0200
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-27 16:16 -0700
Re: encapsulating directory operations Michael S <already5chosen@yahoo.com> - 2025-05-28 16:04 +0300
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-28 22:54 +0000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-29 10:21 +0200
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-06-06 17:16 -0700
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-06-06 17:26 -0700
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-27 16:18 -0700
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-20 19:36 +1000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-20 14:23 +0200
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-20 23:47 +1000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-20 15:37 +0100
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 01:11 +1000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-20 16:43 +0100
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 07:15 +1000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-20 22:50 +0000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 01:11 +0000
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-20 22:40 -0400
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-21 05:50 +0100
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-21 10:06 +0200
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-21 09:27 +0100
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-20 18:19 +0200
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-20 17:43 +0100
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-20 17:14 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-20 18:20 +0100
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-20 17:51 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-20 19:50 +0100
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-20 19:34 +0000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-21 10:09 +0200
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-20 16:51 +0000
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-20 16:58 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-20 18:09 +0100
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-20 17:48 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-20 19:34 +0100
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 07:51 +1000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-21 05:31 +0100
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 20:08 +1000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-21 11:28 +0100
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-21 17:00 +0200
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-21 16:37 +0100
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-21 16:03 +0000
Re: encapsulating directory operations Michael S <already5chosen@yahoo.com> - 2025-05-21 20:21 +0300
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-22 06:37 -0400
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-22 17:53 +0000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-21 10:27 +0200
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 20:46 +1000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-21 16:46 +0200
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 07:41 +1000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-20 15:02 -0700
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 01:05 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 19:23 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-29 07:21 +0000
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-29 15:06 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-30 18:41 +1000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 08:09 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 00:12 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 10:25 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 01:03 +0000
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-06 17:58 -0800
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-20 13:53 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 00:12 +1000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-20 14:41 -0700
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 08:38 +1000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 09:09 +1000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-20 16:22 -0700
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-21 00:18 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 10:31 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 01:02 +0000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-20 16:18 -0700
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 09:57 +1000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-20 22:41 -0700
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 20:41 +1000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-21 11:06 -0700
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-21 11:22 -0700
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-21 20:58 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-23 07:10 +1000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-22 15:32 -0700
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-23 09:16 +1000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-22 18:38 -0700
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-26 08:12 +1000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-25 15:34 -0700
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-26 09:01 +1000
Re: encapsulating directory operations gazelle@shell.xmission.com (Kenny McCormack) - 2025-05-25 23:25 +0000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-23 02:28 +0000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-22 21:27 -0700
Re: encapsulating directory operations Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-23 07:08 +0200
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-22 22:20 -0700
Re: encapsulating directory operations Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-23 07:43 +0200
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-26 07:54 +1000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-25 15:29 -0700
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-26 08:40 +1000
Re: encapsulating directory operations Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-26 03:29 +0200
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-26 11:46 +1000
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-26 09:43 -0400
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-26 17:16 +0000
Re: encapsulating directory operations vallor <vallor@cultnix.org> - 2025-05-26 04:05 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-26 08:31 +1000
Re: encapsulating directory operations Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-26 03:37 +0200
Re: encapsulating directory operations Richard Harnden <richard.harnden@gmail.invalid> - 2025-05-23 16:09 +0100
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-23 17:50 +0100
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-23 16:57 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-23 18:00 +0100
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-23 17:22 +0000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-23 11:10 -0700
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-23 20:27 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-23 21:35 +0100
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-23 21:10 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-23 23:13 +0100
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-23 22:22 -0700
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-24 06:46 +0100
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-29 07:27 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-29 09:39 +0100
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-29 09:37 +0000
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-29 06:11 -0400
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-29 13:41 +0100
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-29 15:08 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-29 17:36 +0100
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-29 17:18 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-29 18:51 +0100
Re: encapsulating directory operations "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-29 14:31 -0700
Re: encapsulating directory operations "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-29 14:29 -0700
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-29 13:38 +0100
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-29 12:55 -0400
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-29 18:48 +0100
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-30 03:10 +0000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-30 11:20 +0200
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-30 11:54 +0100
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-30 16:02 +0200
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-30 16:26 +0100
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-30 17:42 +0200
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-30 17:39 +0100
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-07-01 10:09 -0700
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-30 18:04 +0000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-29 21:24 +0200
Re: encapsulating directory operations Michael S <already5chosen@yahoo.com> - 2025-05-29 23:24 +0300
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-29 21:27 +0100
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-29 13:45 -0700
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-29 22:09 +0100
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-29 21:19 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-29 22:40 +0100
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-30 18:18 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-30 22:10 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-06-04 19:23 +1000
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-04 13:05 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-06-05 00:00 +1000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-06-04 17:30 +0200
Re: encapsulating directory operations Josef Möllers <josef@invalid.invalid> - 2025-06-04 20:48 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-04 21:09 +0000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-06-05 08:18 +0200
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-06-05 04:58 +1000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-06-04 19:19 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-06-05 05:24 +1000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-06-04 21:30 +0000
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-04 22:38 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-06-05 19:31 +1000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-06-05 08:32 +0200
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-06-05 19:28 +1000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-06-05 20:25 +1000
Re: encapsulating directory operations antispam@fricas.org (Waldek Hebisch) - 2025-06-06 03:26 +0000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-04 23:22 +0000
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-04 23:48 +0000
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-06-10 07:18 -0700
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-29 14:50 -0700
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-30 00:05 +0100
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-30 17:37 +0200
Re: encapsulating directory operations Richard Harnden <richard.nospam@gmail.invalid> - 2025-05-30 17:25 +0100
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-30 17:39 +0100
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-30 17:32 +0100
Re: encapsulating directory operations antispam@fricas.org (Waldek Hebisch) - 2025-05-30 02:46 +0000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-30 03:42 +0000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-30 07:34 +0000
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-23 21:10 +0000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-23 21:31 +0000
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-23 22:05 -0700
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-24 01:27 -0700
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-06-10 08:52 -0700
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-06-10 13:35 -0700
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-06-10 21:34 +0000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-06-10 15:09 -0700
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-06-11 01:16 +0000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-06-10 19:11 -0700
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-06-11 15:23 +0000
Re: encapsulating directory operations "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-11 11:57 -0700
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-06-11 15:32 +0000
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-03 04:39 -0800
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-23 08:44 +1000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-23 08:06 +1000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-22 18:24 -0700
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-23 02:19 +0000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-21 19:31 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-23 07:45 +1000
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-21 13:59 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-23 07:52 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-23 01:18 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-26 09:48 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-26 00:15 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-26 11:50 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-29 07:26 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-30 18:47 +1000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-21 02:21 +0000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-20 22:49 -0700
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 20:44 +1000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-21 12:06 +0100
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-21 11:15 -0700
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-21 21:02 +0000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-21 19:49 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 19:38 +1000
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-20 22:26 -0400
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 03:32 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 19:50 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-22 00:03 +0000
Re: encapsulating directory operations Jakob Bohm <egenagwemdimtapsar@jbohm.dk> - 2025-05-22 02:20 +0200
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-22 02:53 +0000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-21 22:14 -0700
Re: encapsulating directory operations Jakob Bohm <egenagwemdimtapsar@jbohm.dk> - 2025-08-17 22:34 +0200
Re: encapsulating directory operations antispam@fricas.org (Waldek Hebisch) - 2025-05-21 21:19 +0000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-23 01:17 +0000
Re: encapsulating directory operations Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-21 04:35 +0200
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 19:45 +1000
Re: encapsulating directory operations Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-21 17:07 +0200
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-05-22 20:34 +0200
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-24 22:10 -0700
Page 4 of 18 — ← Prev page 1 2 3 [4] 5 6 … 18 Next page →
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2025-06-09 07:13 +0800 |
| Message-ID | <467f98d97cb424ee7ec5c56a630ec96d44799a95.camel@gmail.com> |
| In reply to | #393757 |
On Sun, 2025-06-08 at 16:55 +0000, Scott Lurndal wrote:
>
> For example:
>
> c_file_card_unit::c_file_card_unit(ulong channel, ulong unit, const char *name,
> c_logger *lp, c_card_dlp *dlp, bool punch,
> bool hollerith, const char *binpath)
> : c_card_unit(channel, unit, lp, dlp, punch)
> {
> int flags = punch?O_RDWR|O_APPEND:O_RDONLY;
> int diag;
> uint8 header[CARD_SIZE_COLUMNS];
>
> f_file = NULL;
> f_inputhopper = 0ul;
> f_binfd = -1;
> snprintf(f_binary_path, sizeof(f_binary_path), "%s", binpath);
>
> diag = stat(name, &cu_stat);
> if (diag == -1) {
> if ((errno == ENOENT) && punch) {
> flags |= O_CREAT|O_EXCL;
> }
> }
>
> cu_fd = open(name, flags, 0600);
> if (cu_fd == -1) {
> fprintf(stdout, "%4.4lu/%2.2lu Unable to open '%s': %s\n",
> cu_channel, cu_unit, name, strerror(errno));
> return;
> }
>
> diag = fcntl(cu_fd, F_SETFD, FD_CLOEXEC);
> if (diag == -1) {
> lp->log("%4.4lu/%2.2lu Unable to set FD_CLOEXEC on '%s': %s\n",
> cu_channel, cu_unit, name, strerror(errno));
> diag = close(cu_fd);
> cu_fd = -1;
> return;
> }
>
> ...
> }
I would like just share my comment of the code (just skim the code).
Assume c_file_card_unit(..) is a normal function:
1. It should be obvious throwing is no good than returning error.
2. Error is issued in severl places, post condition is a concern.
3. Error handling itself (code and propagation) has to (or better be) error free.
4. Cancellation point/Async-signal safe issues.
> bool
> c_file_card_unit::is_ready(void)
> {
> return (cu_fd != -1) && ((f_file != NULL) && !feof(f_file));
> }
>
> So, if is_ready() returns false after the constructor runs,
> the creator of the object knows the creation failed.
If the code in C++ constructor, returning error encountered is no good, 'contract' is broken.
A ctor like this should be considered too complicated but fine in non-serious code.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@DastardlyHQ.org |
|---|---|
| Date | 2025-06-09 10:21 +0000 |
| Message-ID | <1026cjm$g02c$1@dont-email.me> |
| In reply to | #393757 |
On Sun, 08 Jun 2025 16:55:50 GMT scott@slp53.sl.home (Scott Lurndal) wibbled: >In general, I tend to concur with wij - I prefer to handle run-of-the-mill >errors when they're detected. Same here. I think with exceptions the clue is in the name. They should really only be used for exceptional circumstances, not as a general minor error handling mechanism.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-06-09 13:01 +0200 |
| Message-ID | <1026eu1$gfc6$2@raubtier-asyl.eternal-september.org> |
| In reply to | #393768 |
Am 09.06.2025 um 12:21 schrieb Muttley@DastardlyHQ.org: > Same here. I think with exceptions the clue is in the name. They should really > only be used for exceptional circumstances, not as a general minor error > handling mechanism. In Java they're also used for things that are more likely. But although Java is significantly slower than C++, exceptions are a magnitude faster than in C++. That's while with current table-driven exception handling does need to find the handler for the callers return address. As shared libraries might be loaded and unloaded asynchronously you've to ask the kernel for the image of every return address, and that's slow.
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2025-06-08 22:52 +0800 |
| Message-ID | <29b9613069183212a224d4e31d6e8e3ff8344113.camel@gmail.com> |
| In reply to | #393748 |
On Sun, 2025-06-08 at 10:06 +0200, Bonita Montero wrote: > Am 07.06.2025 um 21:56 schrieb wij: > > > I see std::filesystem as evidence that C++ finally admits the deficiency of > > its advance error handling system (std::exception). But the result is worse > > than C. > > That's just a mere assertion without any facts. I know a bit of the development of std::filesystem. The view of mere 'standard' disregards fact and uses more the 'assertion' criticized. > In fact, exception > handling makes error handling possible with a fraction of the code > length, because most parts of the code don't need to handle errors, "dont' need" is illusion, errors are always there, mostly ignored and encouraged to ignore by simplification. > whereas in C they do. In C every call level has to deal with erorrs, > whereas in C++ only one level at the upper edge has to catch the > errors. C has not hard coded what 'exception' should be. E.g. C can also set an error object and let interested code to handle it in many ways, what's left is impl. issues. But, I think the 'throw' mechanism (not std::exception) is good, like many others. 'throw' is more like a soft assert failure, which is no error handling.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-06-08 17:06 +0200 |
| Message-ID | <10248tl$3tavs$2@raubtier-asyl.eternal-september.org> |
| In reply to | #393750 |
Am 08.06.2025 um 16:52 schrieb wij: > I know a bit of the development of std::filesystem. The view of mere 'standard' > disregards fact and uses more the 'assertion' criticized. Another statement without arguments. > "dont' need" is illusion, errors are always there, mostly ignored and encouraged > to ignore by simplification. If the code is written to be exception-safe, i.e. it uses RAII throughout, then this is easily possible. > C has not hard coded what 'exception' should be. E.g. C can also set an error > object and let interested code to handle it in many ways, what's left is impl. > issues. Are you serious? The fact that the exception type is transported along with the exception itself makes things really convenient. This way, the stack can be unrolled until the correct exception handler is found. > But, I think the 'throw' mechanism (not std::exception) is good, like many > others. 'throw' is more like a soft assert failure, which is no error handling. Totally different - asserts are handled at debug-time. Based on this statement, you didn't understand exceptions correctly.
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2025-06-09 00:28 +0800 |
| Message-ID | <e9cb37d7efedcb52f00397bf831787344c45b912.camel@gmail.com> |
| In reply to | #393752 |
On Sun, 2025-06-08 at 17:06 +0200, Bonita Montero wrote: > Am 08.06.2025 um 16:52 schrieb wij: > > > I know a bit of the development of std::filesystem. The view of mere 'standard' > > disregards fact and uses more the 'assertion' criticized. > > Another statement without arguments. My primary interest of programming is on the theory. From your presented wording, I don't think you can conduct a logical discussion (it seems you continue to ask for logical proof). > > "dont' need" is illusion, errors are always there, mostly ignored and encouraged > > to ignore by simplification. > > If the code is written to be exception-safe, i.e. it uses > RAII throughout, then this is easily possible. > > > C has not hard coded what 'exception' should be. E.g. C can also set an error > > object and let interested code to handle it in many ways, what's left is impl. > > issues. > > Are you serious? The fact that the exception type is transported along > with the exception itself makes things really convenient. This way, the > stack can be unrolled until the correct exception handler is found. > > > But, I think the 'throw' mechanism (not std::exception) is good, like many > > others. 'throw' is more like a soft assert failure, which is no error handling. > > Totally different - asserts are handled at debug-time. > Based on this statement, you didn't understand exceptions correctly. It seems your whole idea (and 'fact') is based on C++'s propaganda. Most of the related discussion have happened in the past I am lazy to repeat. Just look at the fact, C++ is half-dying and accelerating (IMO, not because of bad but of trillions ways doing it wrong). You are repeating past errors and think your understanding and coding is orthodox enough to be factually correct.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-06-08 22:05 +0200 |
| Message-ID | <1024qeo$1iim$1@raubtier-asyl.eternal-september.org> |
| In reply to | #393756 |
Am 08.06.2025 um 18:28 schrieb wij: > My primary interest of programming is on the theory. ... Then don't talk about practical issues.
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2025-06-09 06:51 +0800 |
| Message-ID | <81b8ba67c43abff8c734382367bfd6303e9f0b52.camel@gmail.com> |
| In reply to | #393761 |
On Sun, 2025-06-08 at 22:05 +0200, Bonita Montero wrote: > Am 08.06.2025 um 18:28 schrieb wij: > > > My primary interest of programming is on the theory. ... > > Then don't talk about practical issues. Where did I talk about theory? It is you who talked like you want a theoretic proof. (I have no problem with that except I don't think you will understand). And now, you cut the context off to indicate I only interested in theory (imagination). Your several posts indicate that your fact is actually propaganda and reject other facts (practice).
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-06-09 07:59 +0000 |
| Message-ID | <1026489$e1bd$1@dont-email.me> |
| In reply to | #393748 |
On Sun, 8 Jun 2025 10:06:58 +0200, Bonita Montero wrote: > In C every call level has to deal with erorrs, whereas in C++ only > one level at the upper edge has to catch the errors. Not necessarily that simple. It might be easier if C++ had try/finally (like Python does), but it doesn’t. Here’s a patch I submitted to the Blender project some years ago to fix up their directory-scan code to gracefully recover from errors without either memory leaks or double-frees. This code is in C. It’s all a matter of structured programming. <https://projects.blender.org/blender/blender/src/commit/edf4855a38e3ee24874431f7c6321f04cb6d1b2f>
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-06-09 13:04 +0200 |
| Message-ID | <1026f3t$gfc6$3@raubtier-asyl.eternal-september.org> |
| In reply to | #393766 |
Am 09.06.2025 um 09:59 schrieb Lawrence D'Oliveiro:
> Not necessarily that simple. It might be easier if C++ had
> try/finally (like Python does), but it doesn’t.
The initial thought with C++ exceptions is that all the unrolling
happens with RAII-classe so that you don't need finally. But some-
times you won't write a class for each resource you hold. For this
cases a helper-class like experimental::scope_exit is very comfor-
table. Unfortunately that's still not in the standard so that I
had to write it on my own:
#pragma once
#include <utility>
#include <concepts>
#include "nui.h"
template<std::invocable Fn>
struct defer final
{
defer( Fn &&fn ) :
m_enabled( true ),
m_fn( std::forward<Fn>( fn ) )
{
}
defer( defer const & ) = delete;
void operator =( defer const & ) = delete;
~defer()
{
if( m_enabled ) [[likely]]
m_fn();
}
void operator ()()
{
if( !m_enabled ) [[unlikely]]
return;
m_fn();
m_enabled = false;
}
void disable()
{
m_enabled = false;
}
private:
bool m_enabled;
NO_UNIQUE_ADDRESS Fn m_fn;
};
template<std::invocable ... Fns>
inline void disable( defer<Fns> &... defs )
{
(defs.disable(), ...);
}
template<std::invocable Fn, std::invocable FnNext = Fn>
struct xdefer final
{
xdefer( Fn &&fn, xdefer<FnNext> *next = nullptr ) :
m_enabled( true ),
m_next( next ),
m_fn( std::forward<Fn>( fn ) )
{
}
xdefer( xdefer const & ) = delete;
void operator =( xdefer const & ) = delete;
~xdefer()
{
bool enabled = m_enabled;
if( m_next ) [[likely]]
m_next->m_enabled = enabled;
if( enabled ) [[likely]]
m_fn();
}
void operator ()()
{
if( !m_enabled ) [[unlikely]]
return;
m_fn();
m_enabled = false;
if( !m_next ) [[unlikely]]
return;
m_next->m_enabled = true;
(*m_next)();
}
void disable()
{
m_enabled = false;
}
private:
template<std::invocable Fn1, std::invocable Fn2>
friend struct xdefer;
bool m_enabled;
xdefer<FnNext> *m_next;
NO_UNIQUE_ADDRESS Fn m_fn;
};
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-06-07 23:12 +0200 |
| Message-ID | <10229vo$3b858$1@dont-email.me> |
| In reply to | #393744 |
On 07.06.2025 21:22, Bonita Montero wrote: > Am 07.06.2025 um 20:43 schrieb wij: > >> The basic problem of throwing error is losing error context, [...] Nonsense. > The context doesn't matter. A bad_alloc doesn't need context, a > system_error also not. And that's most of the exceptions the C++ > runtime throws (some are derived from system_error). Context, in the general case, matters. It's been decades that I used C++, but back then in the 1990's we did pass error context with the thrown error object. That's an inherent part of C++'s exception handling. If you use standard error classes without context that's of course possible, but nothing prevents you to define yet another error class derived from some existing error class with additional information. You are actually free to do what suits you and your projects best; use rudimentary handling, or have a sophisticated error framework, or anything in between. Janis
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-06-08 17:11 +0200 |
| Message-ID | <102497b$3tavs$3@raubtier-asyl.eternal-september.org> |
| In reply to | #393746 |
Am 07.06.2025 um 23:12 schrieb Janis Papanagnou: > Context, in the general case, matters. ... If you need the context then you catch the exception near where it is thrown; but that's not usual, meaning in most cases you don't need that context. F.e. when a bad_alloc is thown it dosn't matter which allocation failed, it's just enough to know that a memory-collapse happened. > It's been decades that I used C++, but back then in the 1990's > we did pass error context with the thrown error object. You can easily define your own exception object with more context but for 95% of all exceptions bad_alloc or system_error fit. > That's an inherent part of C++'s exception handling. If you use > standard error classes without context that's of course possible, > but nothing prevents you to define yet another error class derived > from some existing error class with additional information. You > are actually free to do what suits you and your projects best; > use rudimentary handling, or have a sophisticated error framework, > or anything in between. Most exceptions you throw or catch are bad_allocs or system_errors. With that you don't need any context. For the system_error it might make sense to catch them nearer to the call level where the error occured. Usually that happens with I/O-errors. But that still doesn't need the context of the individual I/O-operation.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-06-08 16:58 +0000 |
| Message-ID | <Qij1Q.929648$mjgd.612014@fx09.iad> |
| In reply to | #393754 |
Bonita Montero <Bonita.Montero@gmail.com> writes: >Am 07.06.2025 um 23:12 schrieb Janis Papanagnou: > > > Context, in the general case, matters. ... > >If you need the context then you catch the exception near where >it is thrown; but that's not usual, meaning in most cases you >don't need that context. F.e. when a bad_alloc is thown it dosn't >matter which allocation failed, it's just enough to know that a >memory-collapse happened. Actually it very much matters where the allocation failed, if one wishes to recover from it. It seems your concept of error handling is simply reporting it (hopefully with sufficient context information for the user to understand what needs to be fixed) and calling exit().
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-06-08 11:48 -0700 |
| Message-ID | <1024lue$3nh$1@dont-email.me> |
| In reply to | #393758 |
On 6/8/2025 9:58 AM, Scott Lurndal wrote: > Bonita Montero <Bonita.Montero@gmail.com> writes: >> Am 07.06.2025 um 23:12 schrieb Janis Papanagnou: >> >>> Context, in the general case, matters. ... >> >> If you need the context then you catch the exception near where >> it is thrown; but that's not usual, meaning in most cases you >> don't need that context. F.e. when a bad_alloc is thown it dosn't >> matter which allocation failed, it's just enough to know that a >> memory-collapse happened. > > Actually it very much matters where the allocation failed, if > one wishes to recover from it. Exactly. If an allocation failed in some of my older server code, 20 years ago for sure. Well, it would make the server go into a sort of "panic mode" and dump cache, dump timed out connections, ect, then it would try the allocation again. If that failed, it would go into shit hit the fan mode... ;^) Another fun aspect is in panic mode, instead of dumping timedout connections that are deemed worthy, I send them a special packet. It says, disconnect from me and connect to my friend server, here is the address and port. > It seems your concept of error > handling is simply reporting it (hopefully with sufficient > context information for the user to understand what needs to > be fixed) and calling exit().
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-06-08 22:09 +0200 |
| Message-ID | <1024qkl$1iim$3@raubtier-asyl.eternal-september.org> |
| In reply to | #393758 |
Am 08.06.2025 um 18:58 schrieb Scott Lurndal: > Actually it very much matters where the allocation failed, if > one wishes to recover from it. This very rarely makes sense. It's almost always the case that if an operation fails, it doesn't matter what allocation was behind it.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-06-09 14:01 +0000 |
| Message-ID | <VOB1Q.374963$K3w3.304119@fx05.iad> |
| In reply to | #393763 |
Bonita Montero <Bonita.Montero@gmail.com> writes: >Am 08.06.2025 um 18:58 schrieb Scott Lurndal: > >> Actually it very much matters where the allocation failed, if >> one wishes to recover from it. > >This very rarely makes sense. It's almost always the case that if >an operation fails, it doesn't matter what allocation was behind >it. Have you ever written real-world production code? Like an operating system, where allocation failures should -never- result in an inability to recover.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-06-09 17:24 +0200 |
| Message-ID | <1026uas$k2dv$1@raubtier-asyl.eternal-september.org> |
| In reply to | #393775 |
Am 09.06.2025 um 16:01 schrieb Scott Lurndal: > Have you ever written real-world production code? Like an operating > system, where allocation failures should -never- result in an > inability to recover. If you need an allocation to proceed and it fails you can't recover.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-06-09 15:53 +0000 |
| Message-ID | <PrD1Q.104796$9QV5.36641@fx39.iad> |
| In reply to | #393776 |
Bonita Montero <Bonita.Montero@gmail.com> writes: >Am 09.06.2025 um 16:01 schrieb Scott Lurndal: > >> Have you ever written real-world production code? Like an operating >> system, where allocation failures should -never- result in an >> inability to recover. > >If you need an allocation to proceed and it fails you can't recover. That's your problem caused by poor design and implementation. Exacerbated by the propensity for you to use C++ features that require dynamic allocation where other forms of data structures are more suitable.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-06-09 19:45 +0200 |
| Message-ID | <10276jc$lt1o$1@raubtier-asyl.eternal-september.org> |
| In reply to | #393777 |
Am 09.06.2025 um 17:53 schrieb Scott Lurndal: > Bonita Montero <Bonita.Montero@gmail.com> writes: >> Am 09.06.2025 um 16:01 schrieb Scott Lurndal: >> >>> Have you ever written real-world production code? Like an operating >>> system, where allocation failures should -never- result in an >>> inability to recover. >> >> If you need an allocation to proceed and it fails you can't recover. > > That's your problem caused by poor design and implementation. That's how 100% of all programs that deal with bad_alloc are designed. > Exacerbated by the propensity for you to use C++ features that require > dynamic allocation where other forms of data structures are more suitable. When dynamic allocation is needed it is needed.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-06-09 18:33 +0000 |
| Message-ID | <6OF1Q.1173207$%pKb.770421@fx14.iad> |
| In reply to | #393778 |
Bonita Montero <Bonita.Montero@gmail.com> writes: >Am 09.06.2025 um 17:53 schrieb Scott Lurndal: >> Bonita Montero <Bonita.Montero@gmail.com> writes: >>> Am 09.06.2025 um 16:01 schrieb Scott Lurndal: >>> >>>> Have you ever written real-world production code? Like an operating >>>> system, where allocation failures should -never- result in an >>>> inability to recover. >>> >>> If you need an allocation to proceed and it fails you can't recover. >> >> That's your problem caused by poor design and implementation. > >That's how 100% of all programs that deal with bad_alloc are designed. > >> Exacerbated by the propensity for you to use C++ features that require >> dynamic allocation where other forms of data structures are more suitable. > >When dynamic allocation is needed it is needed. And there are many ways to handle it that don't include throwing bad_alloc when the system is unable to provide additional address space, memory or backing store. Allocating major data structures at application start (perhaps using a pool allocator) and crafting your algorithms such that they don't require infinite memory is a good start.
[toc] | [prev] | [next] | [standalone]
Page 4 of 18 — ← Prev page 1 2 3 [4] 5 6 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web