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 7 of 18 — ← Prev page 1 … 5 6 [7] 8 9 … 18 Next page →
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-05-27 18:10 +0300 |
| Message-ID | <20250527181041.00004902@yahoo.com> |
| In reply to | #393610 |
On Tue, 27 May 2025 16:23:22 +0200 David Brown <david.brown@hesbynett.no> wrote: > On 26/05/2025 07:19, Peter 'Shaggy' Haywood wrote: > > Groovy hepcat Tim Rentsch was jivin' in comp.lang.c on Fri, 23 May > > 2025 10:43 pm. It's a cool scene! Dig it. > > > >> C99 is just as stable as C90, and has been for well over a > >> decade. > > > > Methinks Tim is having trouble with his arithmetic. Either that > > or he doesn't know what year it is now. :) > > C99 was ratified in 1999, over two and a half decades ago. > > > >> C11 is just as stable as C90, and has been for just slightly > >> less than a decade. > > > > And C11 was ratified in 2011, no? That was almost a decade and a > > half ago. > > > > Tim was, I believe, taking into account the time it took for common > implementations of C compilers and libraries to have complete and > generally bug-free support for the standards, and for these > implementations to become common. C99 was published in 1999, but it > took quite a while before most people programming in C could happily > use C99 without worrying about the tool support being "experimental" > or not as mature as C90 support. > > I believe that your belief is wrong. It is much more likely that Tim took into account defect reports. Here is the list of C11 defect reports with the last dated 2016: https://open-std.org/jtc1/sc22/wg14/www/docs/summary.htm I did not find similar list for C99. However believing Tim I would guess that the last change in C99 document was made ~15 years ago.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-05-27 19:24 +0200 |
| Message-ID | <1014sgt$2nmr6$1@dont-email.me> |
| In reply to | #393611 |
On 27/05/2025 17:10, Michael S wrote: > On Tue, 27 May 2025 16:23:22 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> On 26/05/2025 07:19, Peter 'Shaggy' Haywood wrote: >>> Groovy hepcat Tim Rentsch was jivin' in comp.lang.c on Fri, 23 May >>> 2025 10:43 pm. It's a cool scene! Dig it. >>> >>>> C99 is just as stable as C90, and has been for well over a >>>> decade. >>> >>> Methinks Tim is having trouble with his arithmetic. Either that >>> or he doesn't know what year it is now. :) >>> C99 was ratified in 1999, over two and a half decades ago. >>> >>>> C11 is just as stable as C90, and has been for just slightly >>>> less than a decade. >>> >>> And C11 was ratified in 2011, no? That was almost a decade and a >>> half ago. >>> >> >> Tim was, I believe, taking into account the time it took for common >> implementations of C compilers and libraries to have complete and >> generally bug-free support for the standards, and for these >> implementations to become common. C99 was published in 1999, but it >> took quite a while before most people programming in C could happily >> use C99 without worrying about the tool support being "experimental" >> or not as mature as C90 support. >> >> > > I believe that your belief is wrong. > It is much more likely that Tim took into account defect reports. > Here is the list of C11 defect reports with the last dated 2016: > https://open-std.org/jtc1/sc22/wg14/www/docs/summary.htm > > I did not find similar list for C99. However believing Tim I would guess > that the last change in C99 document was made ~15 years ago. > That sounds like a more plausible explanation than mine. You could say that my suggestion is "stable in practice", while the defect reports are "stable in theory". I think "stable in practice" is of greater importance to most programmers, but I believe it would be more in character for Tim to emphasis "stable in theory". In either case, I think it is fair to say that C99 and C11 are both very stable versions of C, and by now are just as suitable choices as C90 for most (but not all) purposes.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-05-27 16:16 -0700 |
| Message-ID | <86jz61tzj1.fsf@linuxsc.com> |
| In reply to | #393611 |
Michael S <already5chosen@yahoo.com> writes: > On Tue, 27 May 2025 16:23:22 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> On 26/05/2025 07:19, Peter 'Shaggy' Haywood wrote: >> >>> Groovy hepcat Tim Rentsch was jivin' in comp.lang.c on Fri, 23 May >>> 2025 10:43 pm. It's a cool scene! Dig it. >>> >>>> C99 is just as stable as C90, and has been for well over a >>>> decade. >>> >>> Methinks Tim is having trouble with his arithmetic. Either that >>> or he doesn't know what year it is now. :) >>> C99 was ratified in 1999, over two and a half decades ago. >>> >>>> C11 is just as stable as C90, and has been for just slightly >>>> less than a decade. >>> >>> And C11 was ratified in 2011, no? That was almost a decade and a >>> half ago. >> >> Tim was, I believe, taking into account the time it took for common >> implementations of C compilers and libraries to have complete and >> generally bug-free support for the standards, and for these >> implementations to become common. C99 was published in 1999, but it >> took quite a while before most people programming in C could happily >> use C99 without worrying about the tool support being "experimental" >> or not as mature as C90 support. > > I believe that your belief is wrong. > It is much more likely that Tim took into account defect reports. > Here is the list of C11 defect reports with the last dated 2016: > https://open-std.org/jtc1/sc22/wg14/www/docs/summary.htm > > I did not find similar list for C99. However believing Tim I would guess > that the last change in C99 document was made ~15 years ago. You are partly right. Besides defect reports, there are TCs. And there is always the possibility of future TCs, future defect reports, or future changes for any ISO C standard while it is still current. To be as stable as C90, a C standard would need to be immune to the possibility of such future changes. I take C99 to have reached this level of stability in 2011, when it was superseded by C11. I take C11 to have reached this level of stability in 2017, when it was superseded by C17.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-05-28 16:04 +0300 |
| Message-ID | <20250528160415.00004552@yahoo.com> |
| In reply to | #393614 |
On Tue, 27 May 2025 16:16:50 -0700 Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > Michael S <already5chosen@yahoo.com> writes: > > > On Tue, 27 May 2025 16:23:22 +0200 > > David Brown <david.brown@hesbynett.no> wrote: > > > >> On 26/05/2025 07:19, Peter 'Shaggy' Haywood wrote: > >> > >>> Groovy hepcat Tim Rentsch was jivin' in comp.lang.c on Fri, 23 May > >>> 2025 10:43 pm. It's a cool scene! Dig it. > >>> > >>>> C99 is just as stable as C90, and has been for well over a > >>>> decade. > >>> > >>> Methinks Tim is having trouble with his arithmetic. Either > >>> that or he doesn't know what year it is now. :) > >>> C99 was ratified in 1999, over two and a half decades ago. > >>> > >>>> C11 is just as stable as C90, and has been for just slightly > >>>> less than a decade. > >>> > >>> And C11 was ratified in 2011, no? That was almost a decade > >>> and a half ago. > >> > >> Tim was, I believe, taking into account the time it took for common > >> implementations of C compilers and libraries to have complete and > >> generally bug-free support for the standards, and for these > >> implementations to become common. C99 was published in 1999, but > >> it took quite a while before most people programming in C could > >> happily use C99 without worrying about the tool support being > >> "experimental" or not as mature as C90 support. > > > > I believe that your belief is wrong. > > It is much more likely that Tim took into account defect reports. > > Here is the list of C11 defect reports with the last dated 2016: > > https://open-std.org/jtc1/sc22/wg14/www/docs/summary.htm > > > > I did not find similar list for C99. However believing Tim I would > > guess that the last change in C99 document was made ~15 years ago. > > You are partly right. Besides defect reports, there are TCs. And > there is always the possibility of future TCs, future defect > reports, or future changes for any ISO C standard while it is > still current. > > To be as stable as C90, a C standard would need to be immune to > the possibility of such future changes. > > I take C99 to have reached this level of stability in 2011, when > it was superseded by C11. I take C11 to have reached this level > of stability in 2017, when it was superseded by C17. Got it. Stability occurs when the standards is fenced from changes by presence of the next edition. Stability by obsolescence.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-05-28 22:54 +0000 |
| Message-ID | <20250528155209.207@kylheku.com> |
| In reply to | #393617 |
On 2025-05-28, Michael S <already5chosen@yahoo.com> wrote: > Got it. Stability occurs when the standards is fenced from changes by > presence of the next edition. Each technical corrigendum effectively yields a new edition. The previous standard without that corrigendum is forever stable, as any immutable object. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-05-29 10:21 +0200 |
| Message-ID | <10195f2$3pa47$1@dont-email.me> |
| In reply to | #393619 |
On 29/05/2025 00:54, Kaz Kylheku wrote: > On 2025-05-28, Michael S <already5chosen@yahoo.com> wrote: >> Got it. Stability occurs when the standards is fenced from changes by >> presence of the next edition. > > Each technical corrigendum effectively yields a new edition. > > The previous standard without that corrigendum is forever stable, > as any immutable object. > They also tend to have a very small impact on the practical implementations of the standards. AFAIK the TC's have all been small changes to the wording of the standard to improve clarity, rather than changing the language as implemented by toolchains.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-06-06 17:16 -0700 |
| Message-ID | <86bjr0s8xi.fsf@linuxsc.com> |
| In reply to | #393619 |
Kaz Kylheku <643-408-1753@kylheku.com> writes: > On 2025-05-28, Michael S <already5chosen@yahoo.com> wrote: > >> Got it. Stability occurs when the standards is fenced from >> changes by presence of the next edition. > > Each technical corrigendum effectively yields a new edition. > > The previous standard without that corrigendum is forever stable, > as any immutable object. There are two reasons why these comments are off base. The first is the word "edition" is wrong. All of the ISO documents related to C99, whether the original one or a later one associated with a TC, all say "this second edition...". And similarly for other versions of the language. The second is that the discussion is not about what is covered by ISO labels but about C90, C99, C11, etc. Each of these names is about one edition of the language, no matter how many separate ISO documents are involved, and that's what the conversation is concerned with. The documents might be immutable, but the documents are not what is under discussion, which is different versions (in other words editions, in the official terminology of the ISO C standards) of the C language.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-06-06 17:26 -0700 |
| Message-ID | <867c1os8gi.fsf@linuxsc.com> |
| In reply to | #393617 |
Michael S <already5chosen@yahoo.com> writes: > On Tue, 27 May 2025 16:16:50 -0700 > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> Michael S <already5chosen@yahoo.com> writes: >> >>> On Tue, 27 May 2025 16:23:22 +0200 >>> David Brown <david.brown@hesbynett.no> wrote: >>> >>>> On 26/05/2025 07:19, Peter 'Shaggy' Haywood wrote: >>>> >>>>> Groovy hepcat Tim Rentsch was jivin' in comp.lang.c on Fri, 23 May >>>>> 2025 10:43 pm. It's a cool scene! Dig it. >>>>> >>>>>> C99 is just as stable as C90, and has been for well over a >>>>>> decade. >>>>> >>>>> Methinks Tim is having trouble with his arithmetic. Either >>>>> that or he doesn't know what year it is now. :) >>>>> C99 was ratified in 1999, over two and a half decades ago. >>>>> >>>>>> C11 is just as stable as C90, and has been for just slightly >>>>>> less than a decade. >>>>> >>>>> And C11 was ratified in 2011, no? That was almost a decade >>>>> and a half ago. >>>> >>>> Tim was, I believe, taking into account the time it took for common >>>> implementations of C compilers and libraries to have complete and >>>> generally bug-free support for the standards, and for these >>>> implementations to become common. C99 was published in 1999, but >>>> it took quite a while before most people programming in C could >>>> happily use C99 without worrying about the tool support being >>>> "experimental" or not as mature as C90 support. >>> >>> I believe that your belief is wrong. >>> It is much more likely that Tim took into account defect reports. >>> Here is the list of C11 defect reports with the last dated 2016: >>> https://open-std.org/jtc1/sc22/wg14/www/docs/summary.htm >>> >>> I did not find similar list for C99. However believing Tim I would >>> guess that the last change in C99 document was made ~15 years ago. >> >> You are partly right. Besides defect reports, there are TCs. And >> there is always the possibility of future TCs, future defect >> reports, or future changes for any ISO C standard while it is >> still current. >> >> To be as stable as C90, a C standard would need to be immune to >> the possibility of such future changes. >> >> I take C99 to have reached this level of stability in 2011, when >> it was superseded by C11. I take C11 to have reached this level >> of stability in 2017, when it was superseded by C17. > > Got it. Stability occurs when the standards is fenced from > changes by presence of the next edition. > Stability by obsolescence. Right except the word obsolescence is not appropriate. The release of C99 doesn't make C90 either obsolete or obsolescent. It is possible that a given earlier edition of C will become either obsolete or obsolescent, but it isn't the release of a subsequent edition that does that. Stability happens when a subsequent edition is ratified, regardless of when or whether an earlier edition ever becomes either obsolete or obsolescent. No edition of C is now obsolete, nor do I expect any of them will be during our lifetimes.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-05-27 16:18 -0700 |
| Message-ID | <86frgptzga.fsf@linuxsc.com> |
| In reply to | #393609 |
Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> writes: > Groovy hepcat Tim Rentsch was jivin' in comp.lang.c on Fri, 23 May 2025 > 10:43 pm. It's a cool scene! Dig it. > >> C99 is just as stable as C90, and has been for well over a >> decade. > > Methinks Tim is having trouble with his arithmetic. Either that or he > doesn't know what year it is now. :) > C99 was ratified in 1999, over two and a half decades ago. > >> C11 is just as stable as C90, and has been for just slightly >> less than a decade. > > And C11 was ratified in 2011, no? That was almost a decade and a half > ago. Amusing that you have such a low opinion of my mental faculties. :)
[toc] | [prev] | [next] | [standalone]
| From | "Paul Edwards" <mutazilah@gmail.com> |
|---|---|
| Date | 2025-05-20 19:36 +1000 |
| Message-ID | <100hieb$261k5$1@dont-email.me> |
| In reply to | #393428 |
"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message news:87ecwj1vy9.fsf@nosuchdomain.example.com... > "Paul Edwards" <mutazilah@gmail.com> writes: > > > Someone (Jean-Marc) wrote some "folder" routines which I like a lot. > > You can see them here: > > > > https://sourceforge.net/p/pdos/gitcode/ci/master/tree/hwzip/folder.c > > > > And in essence, when you read from a directory, the only > > thing you get is the filename. If it is actually a subdirectory, > > then that is indicated with a "/" at the end of the filename. > > > > Other things like size and creation date are not available, > > and C90 does not guarantee that such concepts even > > exist. C90 does guarantee that files exist though. > > C90, like all later standards, supports file operations only in hosted > implementations, not in freestanding implementations. Even on a > conforming hosted implementation, every call to fopen() could fail. Sure. I'm talking about hosted implementations where you can make fopen do something other than permanently fail. > > And C90 (etc) could potentially be extended to include a folder.h > > C90 will never be extended. It was made obsolete by C99, which was made > obsolete by C11, which was made obsolete by C23. You're free to invent > your own language based on C90 if you like, but C went in a different > direction decades ago. That depends on your definition of "C". Ritchie is no longer here to adjudicate whether something close to C90 - in the spirit of the original C, is the true successor to his language, and which one is a complete and utter joke of no relation to anything he designed. A semantic debate that doesn't answer my question either way anyway. BFN. Paul.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-05-20 14:23 +0200 |
| Message-ID | <100hs85$27qbn$1@dont-email.me> |
| In reply to | #393431 |
On 20/05/2025 11:36, Paul Edwards wrote: > "Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message > news:87ecwj1vy9.fsf@nosuchdomain.example.com... >> "Paul Edwards" <mutazilah@gmail.com> writes: >> >>> And C90 (etc) could potentially be extended to include a folder.h >> >> C90 will never be extended. It was made obsolete by C99, which was made >> obsolete by C11, which was made obsolete by C23. You're free to invent >> your own language based on C90 if you like, but C went in a different >> direction decades ago. > > That depends on your definition of "C". Ritchie is no longer here to > adjudicate whether something close to C90 - in the spirit of the > original C, is the true successor to his language, and which one is > a complete and utter joke of no relation to anything he designed. > Once C was standardised - first by ANSI, then immediately afterwards by ISO - the "definition of C" became clear. The language is covered by an international standard, so "C" is the language defined by that standard. Thus "C" means "C23" at the moment - each newly published C standard "cancels and replaces" the previous version. Ritchie's opinion hasn't had any connection to the "definition of C" since 1989. I don't know if he ever expressed a public opinion on C99, or the plans for C11. I would, however, be astounded if he had considered it "a complete and utter joke of no relation to anything he designed". (And while I don't think that an "appeal to authority" argument has much merit, he did say that he found Linux "quite delightful" as a continuation of UNIX, and I would not expect him to have viewed your OS ideas as productive.) > A semantic debate that doesn't answer my question either way anyway. > You did ask us not to give the obvious answer to your original post. But Keith is absolutely correct here. C90 is C90, and will remain that way (baring the very unlikely possibility of minor technical corrections). You can make your own libraries, and OS's, and extensions, and languages - whatever makes you happy. (And if you enjoy what you are doing, and it's not harming anyone, then that's all the reason you need. You don't need approval from anyone else. Don't let me or anyone else hinder you enjoying yourself.) However, nothing that you ever do will be an extension to C90.
[toc] | [prev] | [next] | [standalone]
| From | "Paul Edwards" <mutazilah@gmail.com> |
|---|---|
| Date | 2025-05-20 23:47 +1000 |
| Message-ID | <100i14o$28o7d$1@dont-email.me> |
| In reply to | #393434 |
"David Brown" <david.brown@hesbynett.no> wrote in message news:100hs85$27qbn$1@dont-email.me... > On 20/05/2025 11:36, Paul Edwards wrote: > > "Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message > > news:87ecwj1vy9.fsf@nosuchdomain.example.com... > >> "Paul Edwards" <mutazilah@gmail.com> writes: > >> > > >>> And C90 (etc) could potentially be extended to include a folder.h > >> > >> C90 will never be extended. It was made obsolete by C99, which was made > >> obsolete by C11, which was made obsolete by C23. You're free to invent > >> your own language based on C90 if you like, but C went in a different > >> direction decades ago. > > > > That depends on your definition of "C". Ritchie is no longer here to > > adjudicate whether something close to C90 - in the spirit of the > > original C, is the true successor to his language, and which one is > > a complete and utter joke of no relation to anything he designed. > > > > Once C was standardised - first by ANSI, then immediately afterwards by > ISO - the "definition of C" became clear. Yes, I agree with that. > The language is covered by an > international standard, so "C" is the language defined by that standard. > Thus "C" means "C23" at the moment - each newly published C standard > "cancels and replaces" the previous version. I don't agree with this. I'm sure the ISO committee is keen to "cancel" the previous work. But I have a different opinion. I doubt that I am alone. I'm probably in a minority, but so what? > Ritchie's opinion hasn't > had any connection to the "definition of C" since 1989. I don't know if > he ever expressed a public opinion on C99, or the plans for C11. I > would, however, be astounded if he had considered it "a complete and > utter joke of no relation to anything he designed". Well, in the 1990s I had some work colleagues who were incensed that I had converted some K&R C code to C90, and called it "nancy C". I pointed out that Ritchie himself had endorsed the standard, and they still didn't budge, saying that he had become deranged or something like that. From another corner I still deal with people who insist that everything should be written in assembler. And in another corner, there are people who claim that I am at fault for not making "my" compiler (a slight variation of gcc 3.2.3) run in under 16 MiB of memory. I understand where these people are coming from. And I can see the alternative described by that Jeff article I referenced. But my starting position is that I (sort of) can't personally fault the C90 standard, and the assembler code produced by a typical C compiler is exemplary, and that this is the basis for the lingua franca of programming. > (And while I don't think that an "appeal to authority" argument has much > merit, he did say that he found Linux "quite delightful" as a > continuation of UNIX, and I would not expect him to have viewed your OS > ideas as productive.) I'm not asking him to approve my OS ideas. I'm asking him to explain what is wrong with the C90 that he approved of, and whether my mentioned extensions are reasonable. > But Keith is absolutely correct here. C90 is C90, and will remain that > way (baring the very unlikely possibility of minor technical corrections). > > You can make your own libraries, and OS's, and extensions, and languages > - whatever makes you happy. (And if you enjoy what you are doing, and > it's not harming anyone, then that's all the reason you need. You don't > need approval from anyone else. Don't let me or anyone else hinder you > enjoying yourself.) However, nothing that you ever do will be an > extension to C90. You seem to have a different definition of "extension to C90" to me, then. Which is also fine. Regardless, I intend to compete with the ISO committee, and not so much start from scratch, as start from C90. My branch may not appeal to a majority, but I'm not particularly trying to appeal to a majority. I'm interested in appealing to the people who I work with (e.g. author of pdld). And I'm also interested in technical guidance from the majority who likely have more technical skills than me, regardless of whether they agree with my approach/goals or not (spoiler: they don't). BFN. Paul.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2025-05-20 15:37 +0100 |
| Message-ID | <100i43s$29dr0$1@dont-email.me> |
| In reply to | #393435 |
[This should be fun.] On 20/05/2025 14:47, Paul Edwards wrote: > "David Brown" <david.brown@hesbynett.no> wrote in message > news:100hs85$27qbn$1@dont-email.me... >> On 20/05/2025 11:36, Paul Edwards wrote: >>> "Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message >>> news:87ecwj1vy9.fsf@nosuchdomain.example.com... >>>> "Paul Edwards" <mutazilah@gmail.com> writes: >> >>>>> And C90 (etc) could potentially be extended to include a folder.h directory.h, damn you! Folders are for schoolteachers, not programmers. We could fall out over this. >>>> >>>> C90 will never be extended. It was made obsolete by >>>> C99, which was made obsolete by C11, which was made >>>> obsolete by C23. You're free to invent your own language >>>> based on C90 if you like, but C went in a different >>>> direction decades ago. >>> >>> That depends on your definition of "C". Ritchie is no longer here to >>> adjudicate whether something close to C90 - in the spirit of the >>> original C, is the true successor to his language, and which one is >>> a complete and utter joke of no relation to anything he designed. >>> >> >> Once C was standardised - first by ANSI, then immediately afterwards by >> ISO - the "definition of C" became clear. > > Yes, I agree with that. So do I. So far, so good. >> The language is covered by an >> international standard, so "C" is the language defined by that standard. >> Thus "C" means "C23" at the moment - each newly published C standard >> "cancels and replaces" the previous version. > > I don't agree with this. I'm sure the ISO committee is keen > to "cancel" the previous work. Whether you agree with David or not, he's correct. He has accurately described the way the world sees C. You might argue that the world sees it wrong, and who am I to dissuade you? But ISO has far more clout than you or me, alas. > But I have a different opinion. > > I doubt that I am alone. It would seem not. Pull up a chair. > I'm probably in a minority, but so what? You're in /my/ minority, but that's okay; there's plenty of room. >> Ritchie's opinion hasn't >> had any connection to the "definition of C" since 1989. I don't know if >> he ever expressed a public opinion on C99, or the plans for C11. I >> would, however, be astounded if he had considered it "a complete and >> utter joke of no relation to anything he designed". > > Well, in the 1990s I had some work colleagues who were > incensed that I had converted some K&R C code to C90, > and called it "nancy C". I pointed out that Ritchie himself > had endorsed the standard, and they still didn't budge, > saying that he had become deranged or something like that. Ritchie single-handedly fought off noalias. Deranged my foot! All his marbles present and correct, and every marble a winner. > From another corner I still deal with people who insist > that everything should be written in assembler. Computer scientists hunt elephants by exercising Algorithm A: 1. Go to Africa 2. Start at the Cape of Good Hope 3. Work northwards in an orderly manner, traversing the continent alternately east and west. 4. During each traverse pass, (a) Catch each animal seen (b) Compare each animal caught to a known elephant (c) Stop when a match is detected Experienced programmers modify Algorithm A by placing a known elephant in Cairo to ensure that the algorithm will terminate. Assembly language programmers prefer to execute Algorithm A on their hands and knees. > And in another corner, there are people who claim that I > am at fault for not making "my" compiler (a slight variation > of gcc 3.2.3) run in under 16 MiB of memory. Mibs are marbles. You can't run a C compiler under 16 marbles, not even if you bring in Dennis Ritchie. > I understand where these people are coming from. So do I, but I expect it was a typo for 16 GB. > And I can see the alternative described by that Jeff article > I referenced. > > But my starting position is that I (sort of) can't personally > fault the C90 standard, and the assembler code produced > by a typical C compiler is exemplary, and that this is the > basis for the lingua franca of programming. Right. >> (And while I don't think that an "appeal to authority" argument has much >> merit, he did say that he found Linux "quite delightful" as a >> continuation of UNIX, and I would not expect him to have viewed your OS >> ideas as productive.) > > I'm not asking him to approve my OS ideas. I'm asking him > to explain what is wrong with the C90 that he approved of, > and whether my mentioned extensions are reasonable. I'm afraid we're about 13½ years too late to expect an answer from the man himself, but I could guess at his answers: (a) nothing; (b) they make a reasonable library, but there's no reason to change C90. If people find the library useful, they will use it and the word will spread. >> But Keith is absolutely correct here. C90 is C90, and will remain that >> way (baring the very unlikely possibility of minor technical corrections). >> >> You can make your own libraries, and OS's, and extensions, and languages >> - whatever makes you happy. (And if you enjoy what you are doing, and >> it's not harming anyone, then that's all the reason you need. You don't >> need approval from anyone else. Don't let me or anyone else hinder you >> enjoying yourself.) However, nothing that you ever do will be an >> extension to C90. > > You seem to have a different definition of "extension to C90" to me, then. Then what do you mean by it? I suspect David thinks you mean an update to the ISO C90 document requiring all conforming C compilers to adopt your new library. And, like me, Keith and David know full well that that ain't gonna happen. > > Which is also fine. > > Regardless, I intend to compete with the ISO committee, and > not so much start from scratch, as start from C90. > > My branch may not appeal to a majority, but I'm not particularly > trying to appeal to a majority. I'm interested in appealing to the > people who I work with (e.g. author of pdld). And I'm also > interested in technical guidance from the majority who likely > have more technical skills than me, regardless of whether they > agree with my approach/goals or not (spoiler: they don't). If you want to publish a library, nobody is going to argue against you doing so. You can't have too many libraries. (Well, I expect you can, but it's hard.) -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | "Paul Edwards" <mutazilah@gmail.com> |
|---|---|
| Date | 2025-05-21 01:11 +1000 |
| Message-ID | <100i632$29uce$1@dont-email.me> |
| In reply to | #393442 |
"Richard Heathfield" <rjh@cpax.org.uk> wrote in message news:100i43s$29dr0$1@dont-email.me... > [This should be fun.] > > On 20/05/2025 14:47, Paul Edwards wrote: > > "David Brown" <david.brown@hesbynett.no> wrote in message > > news:100hs85$27qbn$1@dont-email.me... > >> On 20/05/2025 11:36, Paul Edwards wrote: > >>> "Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message > >>> news:87ecwj1vy9.fsf@nosuchdomain.example.com... > >>>> "Paul Edwards" <mutazilah@gmail.com> writes: > >> > >>>>> And C90 (etc) could potentially be extended to include a folder.h > > directory.h, damn you! Folders are for schoolteachers, not > programmers. We could fall out over this. What we'll fall out over is you exceeding the limits of MSDOS 8.3 filenames. :-) ISO C90 didn't do that. And yes, I counted it on my fingers. I suspect Jean-Marc chose "folder" because every man and his dog has a directory-processing "standard" and he could see that none of them were doing what I wanted and I was struggling to express myself. > >> The language is covered by an > >> international standard, so "C" is the language defined by that standard. > >> Thus "C" means "C23" at the moment - each newly published C standard > >> "cancels and replaces" the previous version. > > > > I don't agree with this. I'm sure the ISO committee is keen > > to "cancel" the previous work. > > Whether you agree with David or not, he's correct. He has > accurately described the way the world sees C. > > You might argue that the world sees it wrong, and who am I to > dissuade you? But ISO has far more clout than you or me, alas. Oh - I guess in that light, he is indeed correct. English is *defined* by common usage, so yes, the definition of C is thus the latest and greatest standard, regardless of whether there are any compilers at all that support that language. The world is a joke. I've already given someone else's take on that. I just agree with him. > > And in another corner, there are people who claim that I > > am at fault for not making "my" compiler (a slight variation > > of gcc 3.2.3) run in under 16 MiB of memory. > > Mibs are marbles. You can't run a C compiler under 16 marbles, > not even if you bring in Dennis Ritchie. Pardon? I also use Microsoft C 6.0 which was the last version to run on a PC XT in 640 KiB. gcc 3.2.3 will run in under 16 MiB if I switch off optimization. > > I understand where these people are coming from. > > So do I, but I expect it was a typo for 16 GB. Nope. > > And I can see the alternative described by that Jeff article > > I referenced. > > > > But my starting position is that I (sort of) can't personally > > fault the C90 standard, and the assembler code produced > > by a typical C compiler is exemplary, and that this is the > > basis for the lingua franca of programming. > > Right. Certainly great to have company! > >> (And while I don't think that an "appeal to authority" argument has much > >> merit, he did say that he found Linux "quite delightful" as a > >> continuation of UNIX, and I would not expect him to have viewed your OS > >> ideas as productive.) > > > > I'm not asking him to approve my OS ideas. I'm asking him > > to explain what is wrong with the C90 that he approved of, > > and whether my mentioned extensions are reasonable. > > I'm afraid we're about 13½ years too late to expect an answer > from the man himself, but I could guess at his answers: > > (a) nothing; EXACTLY. > (b) they make a reasonable library, but there's no reason to > change C90. If people find the library useful, they will use it > and the word will spread. > > >> But Keith is absolutely correct here. C90 is C90, and will remain that > >> way (baring the very unlikely possibility of minor technical corrections). > >> > >> You can make your own libraries, and OS's, and extensions, and languages > >> - whatever makes you happy. (And if you enjoy what you are doing, and > >> it's not harming anyone, then that's all the reason you need. You don't > >> need approval from anyone else. Don't let me or anyone else hinder you > >> enjoying yourself.) However, nothing that you ever do will be an > >> extension to C90. > > > > You seem to have a different definition of "extension to C90" to me, then. > > Then what do you mean by it? I suspect David thinks you mean an > update to the ISO C90 document requiring all conforming C > compilers to adopt your new library. And, like me, Keith and > David know full well that that ain't gonna happen. Oh my goodness. No, no. I'm not expecting that. You can call it C25 if you want. And C25 is a slight change from C90. Or C90+ Or possibly C90+- if say gets() is removed. And other things - like things that SubC is struggling to provide - could potentially be removed to have multiple "levels" of "minus". The SQL standard I read in the 1990s had 3 levels. > > Which is also fine. > > > > Regardless, I intend to compete with the ISO committee, and > > not so much start from scratch, as start from C90. > > > > My branch may not appeal to a majority, but I'm not particularly > > trying to appeal to a majority. I'm interested in appealing to the > > people who I work with (e.g. author of pdld). And I'm also > > interested in technical guidance from the majority who likely > > have more technical skills than me, regardless of whether they > > agree with my approach/goals or not (spoiler: they don't). > > If you want to publish a library, nobody is going to argue > against you doing so. You can't have too many libraries. (Well, I > expect you can, but it's hard.) I can publish lots of libraries for lots of applications. This wouldn't be one of those. This would be something fundamental for a portable lingua franca. I've mentioned before about adding a define for: #define ESC_STR "\x1b" #define ESC_CHAR 0x1b ready for recompiling on an EBCDIC machine to support an EBCDIC ANSI X3.64 terminal. So this is another one of those. A portable way of dealing with a hierarchical file system. Even on a system like MVS/TSO that doesn't have such a thing, so needs some cautionary wording. C90 is full of cautionary wording and a joy to read. Or to put it another way - if you didn't have time pressure, and the world was willing to stop writing code circa 1986 until C had been standardized, and with the benefit of hindsight - what should or shouldn't be in a C90 or C2090 - however long it takes to "get it right"? BFN. Paul.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2025-05-20 16:43 +0100 |
| Message-ID | <100i7ub$2aaj2$1@dont-email.me> |
| In reply to | #393445 |
On 20/05/2025 16:11, Paul Edwards wrote:
> "Richard Heathfield" <rjh@cpax.org.uk> wrote in message
> news:100i43s$29dr0$1@dont-email.me...
>> [This should be fun.]
>>
>> On 20/05/2025 14:47, Paul Edwards wrote:
>>> "David Brown" <david.brown@hesbynett.no> wrote in message
>>> news:100hs85$27qbn$1@dont-email.me...
>>>> On 20/05/2025 11:36, Paul Edwards wrote:
>>>>> "Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message
>>>>> news:87ecwj1vy9.fsf@nosuchdomain.example.com...
>>>>>> "Paul Edwards" <mutazilah@gmail.com> writes:
>>>>
>>>>>>> And C90 (etc) could potentially be extended to include a folder.h
>>
>> directory.h, damn you! Folders are for schoolteachers, not
>> programmers. We could fall out over this.
>
> What we'll fall out over is you exceeding the limits of
> MSDOS 8.3 filenames. :-)
I did actually think about that (only for about a microsecond,
but yes, I used to think it was a big deal).
<snip>
>>> And in another corner, there are people who claim that I
>>> am at fault for not making "my" compiler (a slight variation
>>> of gcc 3.2.3) run in under 16 MiB of memory.
>>
>> Mibs are marbles. You can't run a C compiler under 16 marbles,
>> not even if you bring in Dennis Ritchie.
>
> Pardon?
https://en.wiktionary.org/wiki/mib
Noun
mib (plural mibs)
(games) A marble (glass ball used in games), especially one
used as a target.
(Don't miss the quotations - priceless!)
> I also use Microsoft C 6.0 which was the
> last version to run on a PC XT in 640 KiB.
Well, kib turns out to be Sumerian for "leash". Naturally, I
prefer "unleashed".
>
> gcc 3.2.3 will run in under 16 MiB if I switch off optimization.
>
>>> I understand where these people are coming from.
>>
>> So do I, but I expect it was a typo for 16 GB.
>
> Nope.
Clearly humour has failed me on this occasion.
If you're allowed to get all uppity about 9-letter filenames
(which uppityness I absolutely understand and respect), I reserve
the right to insist on KB, MB, and GB instead of these
nonsensical new inventions. The world knows full well that bit
and byte prefixes are measured in powers of 2, and we don't need
an intrusive iota irresponsibly interceding itself into initialisms.
>>> But my starting position is that I (sort of) can't personally
>>> fault the C90 standard, and the assembler code produced
>>> by a typical C compiler is exemplary, and that this is the
>>> basis for the lingua franca of programming.
>>
>> Right.
>
> Certainly great to have company!
Today comp.lang.c, tomorrow ISO/IEC JTC 1/SC 22/WG 14 !
<snip 1 - no comment>
<snip 2 - Ce n'est pas ma tasse de thé.>
> Or to put it another way - if you didn't have time pressure,
> and the world was willing to stop writing code circa 1986
> until C had been standardized, and with the benefit of
> hindsight - what should or shouldn't be in a C90 or C2090 -
> however long it takes to "get it right"?
fclose would take a FILE ** instead of FILE *, and its dying act
would be *fp = NULL;
qsort and bsearch would take context pointers to pass to cmp.
non-blocking sockets would be in the standard, using an interface
based on fopen/fread/fwrite/fclose.
If I'm only allowed three, those would be the three I'd take.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | "Paul Edwards" <mutazilah@gmail.com> |
|---|---|
| Date | 2025-05-21 07:15 +1000 |
| Message-ID | <100is6f$2e651$1@dont-email.me> |
| In reply to | #393447 |
"Richard Heathfield" <rjh@cpax.org.uk> wrote in message news:100i7ub$2aaj2$1@dont-email.me... > If you're allowed to get all uppity about 9-letter filenames > (which uppityness I absolutely understand and respect), I reserve > the right to insist on KB, MB, and GB instead of these > nonsensical new inventions. The world knows full well that bit > and byte prefixes are measured in powers of 2, and we don't need > an intrusive iota irresponsibly interceding itself into initialisms. There are places in computing where powers of 2 are not used, and sometimes it is important. In this case it wasn't really necessary, but I wanted to be precise anyway. The main reason I use it is because I copied off someone else (Gerhard, who wrote most of mvssupa.asm), when he started using it. Similarly, "BFN" was popular when I started using BBSes, and I copied the others. It seems that as soon as I started using it, everyone else stopped using it to the point where many people have never seen it before I turn up. > >>> But my starting position is that I (sort of) can't personally > >>> fault the C90 standard, and the assembler code produced > >>> by a typical C compiler is exemplary, and that this is the > >>> basis for the lingua franca of programming. > >> > >> Right. > > > > Certainly great to have company! > > Today comp.lang.c, tomorrow ISO/IEC JTC 1/SC 22/WG 14 ! Yeah - exactly. That's sort of my goal. But I am already preempting the fact that the ISO committee is very unlikely to cooperate with me, so I will fork the standard. > > Or to put it another way - if you didn't have time pressure, > > and the world was willing to stop writing code circa 1986 > > until C had been standardized, and with the benefit of > > hindsight - what should or shouldn't be in a C90 or C2090 - > > however long it takes to "get it right"? > > fclose would take a FILE ** instead of FILE *, and its dying act > would be *fp = NULL; That's changing the language. I'm not talking about changing the language. There are precedence operators that should ideally be changed too. Maybe a new language with all these things sorted out could be done one day. English could be revamped (or replaced with Esperanto) too. But that's not what I'm trying to do right now. And is not my question. > qsort and bsearch would take context pointers to pass to cmp. I'm guessing what this is, and this sounds like you want some new functions. You can have some new functions like a variant of strncpy that puts the terminating NUL for you too. And snprintf too. I'm not trying to do that. I'm after minimal changes to C90. > non-blocking sockets would be in the standard, using an interface > based on fopen/fread/fwrite/fclose. This is something that sounds good, but I'm not sure C90 is the right place for it. C90 covers simple applications that block on every operation. If you want to extend C90 to including fancy non-blocking, that's fine, but a different extension to what I'm currently after. Note that I did previously suggest the addition of an "fpeek", to give a very minimal way of doing minimal non-blocking. BFN. Paul.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-05-20 22:50 +0000 |
| Message-ID | <20250520154811.583@kylheku.com> |
| In reply to | #393460 |
On 2025-05-20, Paul Edwards <mutazilah@gmail.com> wrote: > "Richard Heathfield" <rjh@cpax.org.uk> wrote in message > news:100i7ub$2aaj2$1@dont-email.me... > >> If you're allowed to get all uppity about 9-letter filenames >> (which uppityness I absolutely understand and respect), I reserve >> the right to insist on KB, MB, and GB instead of these >> nonsensical new inventions. The world knows full well that bit >> and byte prefixes are measured in powers of 2, and we don't need >> an intrusive iota irresponsibly interceding itself into initialisms. > > There are places in computing where powers of 2 are not > used, and sometimes it is important. "640 is not a power of 2 unless you're a DOS user." -- Murray Goldberg (in a lecture, decades ago) https://en.wikipedia.org/wiki/Murray_Goldberg -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-05-21 01:11 +0000 |
| Message-ID | <100j987$2g75r$6@dont-email.me> |
| In reply to | #393447 |
On Tue, 20 May 2025 16:43:05 +0100, Richard Heathfield wrote: > ... I reserve the right to insist on KB, MB, and GB instead of these > nonsensical new inventions. Looking at some old stuff on Bitsavers, it’s amusing to see descriptions that can’t decide if they have “64K” of RAM or “65K” ... > non-blocking sockets would be in the standard, using an interface based > on fopen/fread/fwrite/fclose. Does seem to reinforce the impression that a lot of the proposals for filling in functional gaps in C involve including features already available in POSIX ...
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-05-20 22:40 -0400 |
| Message-ID | <100jeeo$2kpbs$1@dont-email.me> |
| In reply to | #393447 |
On 5/20/25 11:43, Richard Heathfield wrote: ... > nonsensical new inventions. The world knows full well that bit > and byte prefixes are measured in powers of 2, ... I must emphatically disagree - long before MiB was invented, I had arguments with people who were certain they were measured in powers of 10, and could point at authorities supporting those views.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2025-05-21 05:50 +0100 |
| Message-ID | <100jm32$2m0ln$2@dont-email.me> |
| In reply to | #393485 |
On 21/05/2025 03:40, James Kuyper wrote: > On 5/20/25 11:43, Richard Heathfield wrote: > ... >> nonsensical new inventions. The world knows full well that bit >> and byte prefixes are measured in powers of 2, ... > I must emphatically disagree - long before MiB was invented, I had > arguments with people who were certain they were measured in powers of > 10, and could point at authorities supporting those views. I must emphatically double down and insist that you were right and they were wrong wrong wrongawrong wrong. We are not alone, you and I. Maybe we could do a badge or something? Have your people talk to my people and we'll do lunch. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
Page 7 of 18 — ← Prev page 1 … 5 6 [7] 8 9 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web